Уважаемые Гуру, Знатоки и просто любители, подскажите убогому! Какое нагрузочное тестирование провести на сервере для того что бы спрогнозировать примерно сколько пользователей сможет поднять сервак???
Попробовал тест от Гилева, посмотрел ммммм - красота, но он однопоточный - не годится! Взял тест "Многопоточное тестирование производительности сервера 1С - СУБД" на http://catalog.mista.ru/public/173394/ ну вроде многопоточен - это плюс, но результаты в человеко-попугаях, можно ли ему верить??! Взял КИП от 1С, запустил "Стандартный нагрузочный тест" получил результаты отличные от предыдущего теста (показывает что все хорошо, тогда как предыдущий показывал результаты ниже среднего). Есть еще Тест-Центр и Центр управления производительностью, пока разбираюсь с ними, но это время!!! Что посоветуете???

100 китайцев создатут реальную нагрузку. дешево. самовывоз

(0)[Что посоветуете???]
Тест-Центр + сценарий УПП

(2) то есть установить УПП объединить с Тест-Центр и тестить? А отчет там в каких показателях? (Сорри пока не разобрался ещё)

Подскажите из своего опыта, как вы определяли потянет сервер или нет???

(3) нет
надо развернуть УПП и натравить на него стандартный сценарий тестирования для УПП же,
желательно в партионном режиме

(0) Теоретический расчет (как вариант). Спрогнозировать объем информации который должен обработать процессор. Далее по теореме Котельникова рассчитать минимальную частоту необходимую для обработки данной информации в нужную единицу времени. Умножить полученную частоту на 100-200. Получить необходимую частоту одного ядра процессора.

(6) + Но это так... в рамках развлечения :)

(6) применение теоремы Котельникова для оценки работы глубоко конвейрезировонных CPU это не развлечение, это уже хобби =)

Стоимость такого проекта 300 000 рублей, результаты прогнозирования - неточные. Думаете это от недостатка умений? Или, что можно как-то иначе по проще, на коленочке прикинуть нагрузку и уделать экспертов?

(9) Да мне нужно примерно понимать ситуацию...
(5) А чем не подходит "Стандартный нагрузочный тест" из КИПа: Стандартный нагрузочный тест представляет собой информационную базу «1С:Предприятия 8.2» с конфигурацией, основанной на «Управлении производственным предприятием». Конфигурация объединена с «Тест-центром 2.0», в состав которого включен один сценарий тестирования.
Сценарий тестирования включает в себя эмуляцию бизнес-процесса «продажи в УПП», а именно: создание нескольких различных документов, формирование отчетов и другие прикладные действия. Тест работает в режиме полной параллельности, то есть каждый пользователь работает с собственными уникальными данными, и ожиданий на блокировках не возникает. Пользователь выполняет один полный цикл продажи в минуту.

Времени на долгие расчеты как всегда нет

тестцентр со сценариями на реальной базе даст наиболее верные результаты, но делать эти сценарии - весьма трудоемкий процесс
"Многопоточное тестирование производительности сервера 1С - СУБД" создано для того, чтобы сравнить два сервера или разные конфиги одного сервера или разные СУБД на одном железе.
Ну и помогает спрогнозировать, как будет замедляться работа в условиях увеличения количества очень-очень активных пользователей (при условии отсутствия блокировок).
+ неплохой тест стабильности получился - часто выявляет проблемы в сети :)

к сожалению, у "многопоточного тестирования" почти никто не заполняет описание серверов, а той информации, которая достается стандартными функциями 1с - катастрофически не хватает.

(10) [Сценарий тестирования включает в себя эмуляцию бизнес-процесса «продажи в УПП»]
речь именно об этом сценарии, разве это не очевидно ?

(14) То есть я все делаю правильно? Успокоиться или продолжать елозить?

(15) Мы высочайше позволяем Вам елозить во славу Родины

(13) Fragster вам спасибо за тест!!! (Снимаю шляпу)

(16)  КМ155 Спасибо за комменты, спасибо Вам )))

(0) Так вы хотите протестировать действующий сервер на предмет возможного увеличения нагрузки( кол-во пользователей, интенсивность их деятельности, размер баз), чтобы прикинуть какой надо покупать новый? Или уже купили новый и желаете выяснить потянет ли он?
(13) Я заполнял...

(19) спасибо тебе. а если потыкать на сайте в результаты - таких как ты мало очень :(

(0) Давай характеристики своего сервака.

(21) VladZ, извиняюсь за задержку:
Проц: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Number of cores        4 (max 4)
Number of threads    4 (max 4)

-- 2 штуки

Chipset  
Northbridge Intel i440BX/ZX rev. 01
Southbridge Intel 82371 (PIIX4) rev. 08
Memory Type EDO
Memory Size 24 GBytes
Memory Frequency 66.0 MHz (1:1)
CAS# latency (CL) 3.0
RAS# to CAS# delay (tRCD) 3
RAS# Precharge (tRP) 3


SSD Диски-480 Gb в зеркале

Но это виртуалка, работать хочется на УТ 11.1 толпой в 70-80 человек. На серваке Win 2008 Std, SQL 2014, Apache 2.2

Сорри УТ 11.2 привычка блин

(22) Гугл говорит что проц 6 ядерный

+(25) Сорри. Это ж виртуалка. Остальные 2 ядра для чего оставили? И вообще почему виртуалка?

(22) Подобная штука может держать 50 пользователей в СНТ не роняя апдекс ниже 1.
Предел у неё 70 - дальше поползет вниз ибо памяти не хватит. Думаю для УТ11 70-80 очень близко к потолку, или даже сразу фейл.

(27) Я извиняюсь, а что такое СНТ ???

(28) Садовое некоммерческое товарищество,
а может стандартный нагрузочный тест.
Как у ВДВ: возможно двести вариантов

(27+) Ядер мало: примерно по 128 соединений на рабочий процесс, это примерно 70 пользователей + соединения с менеджером кластера + всякий служебный обвес. 1С не понимает Numa поэтому подсаживается на ядро процессом целиком, после запуска 3-его производительного процесса наступит аут: ОС дай ядро, SQL дай пару ядер, 1С дай 3 ядра = 6 ядер в потолок, а у тебя 4 виртуальных на стремной частоте. Ожидается затык вот прямо здесь в первую очередь.
О! SSD шников то два - да только в зеркале, второй затык пойдет на очереди к SSD, не смотря на всю их крутизну: на SSD 1) ОС и программы, 2) файл подкачки, 3) временные файлы из профиля пользователя под которым кластер запущен, 4) SQL Лог транзакций и запись чтение базы 5) SQL tempdb.
По памяти пролезть получится: 24 Гига на 70 пользователей - порядок, но тоже зависит от качества кода конфиги. Может случиться большое потребление с утечками и тогда рабочих процессов будет запущено больше, чем 4, а это опять ляжет на ядра.
Прогноз короче печален.

(30) А в чем порядок по памяти? 2 гига на ОС + 1 гиг в запасе, в остатке 21. 7 на SQL, 7 на сервер предприятия и 7 на клиенты по 500 метров на брата. Помоему тесновато.
Правда непонятно зачем тут еще апачи, которому тоже нужна память

Всё не читал, предлагаю "Стандартный нагрузочный тест" из состава КИП. Он на базе упп1.3. Нагрузку создает конечно большую, обычные вялые пользователи не сравнятся.

(31) Поднят веб сервер для работы с Мобильным приложением и Веб мордой

(32) "Стандартный нагрузочный тест" из состава КИП, не знаю, нет доверия. Запускал его показал мне:

Пользователей    APDEX
60    1
70    1
80    1
90    1

Показатель    Значение
ОбщееВремяРаботы2    1,076
1    1,096
2    1,026
3    1,080
4    0,999
5    1,114
6    0,978
7    1,214
8    1,132
9    1,085
10    0,977
11    1,045
12    0,973
13    1,023
14    1,002
15    1,072
16    1,071
17    1,038
18    1,621
19    1,123
20    1,205
21    1,153
22    1,012
23    1,009
24    1,161
25    0,987
26    1,023
27    1,012
28    1,014
29    1,194
30    1,085
31    0,982
32    1,062
33    1,360
34    0,970
35    0,983
36    1,083
37    1,013
38    1,178
39    0,999
40    0,950
41    1,147
42    1,101
43    1,031
44    1,132
45    1,018
46    1,021
47    1,107
48    1,056
49    1,187
50    0,992
51    1,039
52    1,089
53    1,082
54    1,125
55    1,060
56    1,067
57    0,941
58    1,169
59    1,032
60    1,029
61    1,062
62    1,170
63    1,012
64    0,996
65    1,097
66    1,006
67    1,129
68    1,019
69    1,057
70    1,057
71    1,122
72    1,023
73    1,188
74    1,042
75    1,019
76    1,179
77    0,928
78    1,114
79    1,100
80    1,080
81    1,236
82    1,038
83    1,043
84    1,182
85    0,973
86    1,064
87    1,104
88    1,239
89    0,952
90    1,041
ОбщееВремяРаботы3    1,085

ОбщееВремяРаботы4    1,059

ОбщееВремяРаботы5    1,066

Типа все зашибись!!!

1С и СУБД на одном хосте будут?
Частота проца маловата будет, думаю. И памяти 24 Гб - ниочем

(30) 1С не понимает Numa поэтому подсаживается на ядро процессом целиком

Да что это за мода на мисте пошла подобную чушь нести?
Указанный процессор подразумевает 1 (один) узел NUMA. Плюс это виртуалка, а значит распределением потоков по узлам NUMA будет заведовать гипервизор.
Rphost загрузит все ядра.

Рассчитывать потребность в ядрах подобным образом нелепо.
Общий вывод при этом верный - 4 серверных потока на 70 пользователей ни о чем.

"4 серверных потока на 70 пользователей ни о чем" // 1С рекомендует в 64-битных ОС использовать один рабочий процесс

(38) То, что у данного проца нет Numa, не отменяет того, что функционал рабочего процесса построен без Numa и того аспекта, что без Numa нет распределения и балансировки - вот об этом и написано, а не о том, что был бы Numa - полетело.
"Rphost загрузит все ядра" - а вот это как раз пример чуши.

(34) Значит 90 типовых упп-пользователей тянет. А 100 уже нет.

(40) ""Rphost загрузит все ядра" - а вот это как раз пример чуши." // Ошибаешься - загрузит (но управлять этим будет ОС)

Читать:
https://its.1c.ru/db/metod8dev#content:4136:hdoc
https://its.1c.ru/db/metod8dev#content:5903:hdoc

(39) 1С не дает прямых рычагов управления на количество рабочих процессов, После того, как запуск экземпляров 1С переваливает за 120 (в течение 70 секунд) 1С запускает более 10 рабочих процессов, после того, как пользователей становится 700 и более запусков нет 1С гасит лишние процессы оставляя примерно 5-6.

(42) Запусти тест на больше 100 и смотри как неравномерно загружены ядра - все станет понятно без отсылок на ИТС.

(44+) В консоли кластера кстати показано, что менеджер кластера думает о рабочих процессах. Там есть такие параметры как оценка производительности процесса и количество соединений. Балансировка работы кластера осуществляется через количество запущенных процессов, а вот балансировки работы процессов - нет. А SQL сервер имеет 1 запущенный процесс, который как раз и использует все ядра (если, конечно лицензия позволяет) с балансировкой.

(43)
https://its.1c.ru/db/metod8dev#content:5903:hdoc
Вот это - правильный мед.
А предыдущая ссылка - бред какой-то, я кстати пытался управлять количеством запущенных процессов через количество соединений, так на клиентах пропали панели навигации в командных интерфейсах. После этого пришлось везде вычистить кеш и вернуть настройки взад.

(44) С этим не спорю. Но у нас случай более-менее рядовой - база на 70 пользователей. Я бы оставил как есть (128 соединений на ИБ), т.е. 1 РП.
(45) А, ты про неравномерность. Да, про это в статье и пишется - тут недоделка. Я почему-то подумал, что ты говорил что 1 РП не загрузит больше 1 ядра. Не так понял тебя, короче.
(47) Я вроде две ссылки привел, а ты повторил одну из них.

(48) Да повторил, там точнее написано, чем я тут расписывал. Я имею опыт о том, что рабочий процесс грузит преимущественно одно ядро и именно из-за этого возникает неравномерность. Они в статье пишут, что ядрами заведует ОС и чего даст процессу то он есть и будет. По мне - так она ему дает также, как приложению 1cv7.exe Отсюда и растут ноги у балансировки через количество запущенных активных процессов.

(49) нет.

(49) Я в 8.3 не видел еще, чтобы один РП грузил всегда пеимущественно одно ядро (в графике загрузки ЦП всегда более-менее поровну общая загрузка ЦП распределена между ядрами)...
А ты тоже про 8.3 преимущественно говоришь?

запусти с одним рабочим процессом http://fragster.ru/perfomanceTest/ увидишь, если нет нумы - грузятся все ядра. если есть - то ядра той ноды, на которой висит rphost

8.3.7.2027 - но настаивать про 1 ядро я не буду, у меня было 8 + 7 = 15 рабочих процессов и неравномерная загрузка 40 ядер, я сделал быстрый вывод не раскапывая глубже.

(52) Вот я скорее такую картину и увидел, но до деталей не докопал.

(40)
Дружище, ну зачем кидаться терминами, про которые не знаешь?

Если мы имеем только 1 узел NUMA, то все ядра обращаются к одной, общей памяти, к которой у них прямой доступ.
Это значит, что ОС нет необходимости выкабениваться и распределять потоки на узлы таким образом, чтобы они использовали быструю ближнюю память.

rphost в такой ситуации будет грузить все ядра. Равномерность этого процесса зависит только от количества дискретных тредов. Если будут 4 треда, грузящих проц по максимуму, то будут загружены все ядра.

Задачей оптимизации NUMA не является равномерное распределение загрузки по процессорам. Задачей оптимизации является локализация выделенной памяти процессов и узлов, которые эту память используют.

Приводить пример отсутствия NUMA-оптимизации в 1С на примере сервака с 1 процессором - ну просто глупость.

(55) Ну да. Все так.
Мои кусочные знания в разных областях зачастую похожи на шаманский хаос. Вот я читал, про отсутствие NUMA оптимизации, но не читал про то, что такое NUMA вообще такое.

(58) У каждого есть! Только не каждого удается поймать :))