Стала медленно работать база. Ну как стала... Когда я пришел (4 месяца назад), уже так было. Началась постепенная борьба за улучшение доли простых пользователей. Сначала обновил платформу до 8.2.17, потом обновил PostgreSQL до 9.1 от 1С. Потом настроил постгрес. На данный момент имеем:
6 баз на сервере и одну файловую. из 6 серверных работают на 2х. Первая БП 2.0 (.dt весит 150 Мб), в которой 3 пользователя. Вторая УТ 10.3(.dt весит 400 Мб), порядка 50 пользователей, остальные базы - тестовые (тестил обмен с сайтом, обмен БП-УТ и прочее). Сейчас просто лежат. Файловая ЗУП - работают 2 человека иногда, поэтому на сервер пока не переношу. При этом у всех 1с работает достаточно медленно (проводит/открывает документы и прочее) только в клиент-сервере, в файле значительно лучше.
все юзеры на RDP
Теперь про сервер: Серверов всего 2. Один чисто под RDP, второй под постгрес, Сервер 1с и RDP. Система почти не загружена: из 16 ГБ оперативы в самый пик используется не больше 9,5. Проц загружен процентов на 30. Простой жесткого от 80% до 100%. Длина очереди даже 1 не бывает.
Если интересно - могу выложить настройки постгресса. Ему там выделено ресурсов столько, что он закэшировать может обе базы на несколько раз.
При этом тормоза как были, так и есть. Тест производительности от Гилева показывает между 5 и 7 попугаями(кто не в курсе, меньше 10 - это плохо. от 10 до 15 - уже удовлетворительно и т.д.) Кто-нибудь, подскажите, куда еще копать? У меня варианты кончились...

(494) Из Linux клиента (8.3.2.172) не хочет публиковать. И 16 и 32 потока тоже не хочет отрабатывать.

(501) публикует сервер, а не клиент... с какой ошибкой падает?

16 и 32 потока не хочет отрабатывать, пишет "не получилось синхронизировать потоки"? а на какой машине запускалось (в частности, сколько ядер)

вообще я только что переписал на PDO с обычных запросов сервис, мог что-то поломать :(
а мне даже и не проверить (вернее, я проверил на тестовом методе test() - вроде работает, а вот поскольку на серверах 1с инет закрыт - полноценную публикацию не могу проверить)

(502)+ кстати, в табличку, куда запросы пишутся, ничего про запрос веб сервиса не записалось, кроме того запроса, который я сам слал

(502)Тогда ясно, сервер без интернета был.

(505) Записалось.

про 16 и 32 потока я, кажется, понял... сервер под линупсом без ключа?

(508)Именно.

(509) получается, что одновременно больше 12 коннектов к серверу не может быть включая фоновые задания

(503) Да. 16 ядер.
(510) Понятно.

добавил вывод детальных результатов

Тест интересный. Но какой-то нестабильный. Уж больно большой разброс в двух-трех подряд запущенных тестах.

А мои дела плохи?
http://screencast.com/t/xzaLaZa8WHnf

(513) на сервере еще кто-то работает?

(514) практика показывает, что тест гилева у меня на сервере выдает 16, но при этом 100 юзеров на этом сервере работают. На моем же компе тест гилева выдает 45, но юзерам уже в количестве 10 не очень хорошо.

Два последних результата мои.
Правда так и не понял - как провести тест для 10-100 пользователей? Можно им сделать нагрузочное тестирование предела загрузки серверов для операционной работы? Или наоборот аналитической?

Больше конечно операционная работа интересует. Это когда выписываются счета и проводятся накладные. Если бы было возможно увидеть "потолок" количества одновременных пользователей, то было бы просто замечательно.

(517) потолок - это когда график выходит на плато.

поскольку каждый тест занимает около полутора минут, увеличение количества тестов замедлит общее время выполнения :(

ограничение в 32 потока чисто психологическое. если интересно - можно сделать после 32 еще несколько этапов по +16 потоков...

психологическое = эмпирическое

сейчас у себя проверяю, как оно будет выполняться в 1, 2, 4, 8, 16, 32, 48, 64, 80, 96, 112 потоков. если взлетит - выложу обновление :)

Fragster, какие новости? Где за ними следить? Как развивается тест? Напомню, у меня в своё время на 16 (или на 32?) потоков не отработало.

Добавил автозаполнение информации о сервере 1с

Изменил алгоритм синхронизации потоков - теперь используется ЗапуститьПриложение вместо бесконечного цикла для ожидания запуска других потоков, что не грузит процессор и дает время для запуска других потоков. Также увеличил время на синхронизацию до 30 секунд.

Теперь тесты выполняются в 1, 2, 4, 8, 16, 32, 48, 64, 80, 96, 112 потоков.

Обновил WS-ссылку, добавил версию платформы в результаты.

Добавил запрос на публикацию результатов теста при изменении (Внимание! Для успешной публикации должен быть разрешен интернет на сервере 1с!)

http://i066.radikal.ru/1303/28/d5fbcf02c66e.png

(522) брать на ИС?

(524) у меня на сайте и на ИС одинаковая версия лежит

(522) а зачем так много? 48-ми было бы за глаза.

(526) зато видно, как графики загибаются вниз на 112 :)

Гы! А при чем тут интернет на сервере 1с и публикация на сайт??? Вроде как интернет нужен на клиентской машине для публикации на сайт. Мы же вроде запуск клиентской части не на сервере делаем.

(527) ну не всегда загибается
http://s018.radikal.ru/i524/1303/ca/ef703282f76f.jpg
http://s018.radikal.ru/i508/1303/b0/f9b99232a6bb.jpg

разброс сильный почему-то

попробую на выходных. Может более стабильный результат будет.

(529) я скоро обновлю - время теста в 2 раза увеличу, как раз чтобы разброс был меньше

(528) в тонком клиенте нет wsпрокси

интересно откуда рост 96-112

что-тьо запись инфы о серверах глючит :(

что, в опере-мини верстка не разъезжается?

тест на ноуте
http://s020.radikal.ru/i711/1303/f0/9d264a077898.jpg

скачки непонятные ..

кажется понял, откуда скачки - часть потоков стартует на секунду-две раньше, попробую устранить

(6)Антивирус на SQL сервере??
Вот нафига он там? Или это еще и файлопомойка по совместительству?

блин, на больших количествах потоков с синхронизацией реальные проблемы :(

победил! сейчас обновлю конфу!

Обновил на сайте, на ИС отправил на модерацию

для 400 потоков разброс старта 2 секунды

Обновил версию на сайте - теперь там есть обработка проверки механизма синхронизации (1000 потоков у меня вылетают - не могут синхронизироваться, 500 потоков - нормально, но с небольшим разбросом).

на сервере с 2хядерном (без ht) процессором, на котором 1с и мсскуль стоит флуктуаций стало намного меньше:
(1с 8.2.16.368 / GenuineIntel x86 Family 6 Model 23 Stepping 6 1866 MHz / 4,00 ГБ / Windows x86 (Microsoft Windows 2003 version 5.2 Service Pack 2 (Build 3790)))

http://wstaw.org/m/2013/03/03/plasma-desktopk17204.png

Fragster, игрулька прикольная. Ты к ней тоже таблицу рекордов прикрути.

(543) Потестил. Но все же есть.
http://s003.radikal.ru/i201/1303/71/bcfb8c0a7a7f.jpg

(545) Это еще может из-за СУБД... буду еще пробовать ...

(546) согласись, что их намного меньше. Ну и на ноуте всякие внезапно просыпающиеся службы индексирования и прочего могут влиять. + на винде планировщик потоков на такое издевательство, наверное, не приспособлен.

ну, можно ценой увеличения времени в 2 раза убрать совсем: в коде в функции Тестирование.ВыполнитьМногопоточныйТест() поставь Кругов = 2 вместо 1.

на десктопной

(547) стало более правильно показывать. щас еще раз так и потом попробую кругами ...

(549) а проверка механизма синхронизации что кажет?

(550) думает пару секунд

(551) на выходе сколько строк? одна?

1 строка. сделал еще 2 теста
http://s019.radikal.ru/i635/1303/05/668b720f69b1.jpg
http://s018.radikal.ru/i519/1303/3c/f7b63214544e.jpg

попробую увеличить кол-во кругов..

(553) значит, все потоки получили сигнал в течении одной секунды :) если бы в 2 строки показывало - то это сигнализировало бы о том, что он не может синхронизировать заданное число потоков в одну секунду.

как на ИС на скрине для 500 потоков

http://infostart.ru/upload/iblock/387/4.png

4 круга флуктуацию не уменьшили.
А она может происходить из-за чрезмерной загруженности системы?

(557) может

особенно если что-то параллельно делать еще на компе

(559) он просто рядом стоит. монитор запустил и смотрел. у него когда много потоков загрузка не высокая на проц, диски, сетку. на взаимодействии процессов где-то тормоза походу идут.
наверное после максимума смотреть бессмыслено ...

(560) да, на 8 юзеров у тебя сервер :)

в смысле ноут

попробую в понедельник на нормальном сервере потестировать. сейчас на нем считают усиленно и перепроводят...

а может просто ось типа десктопная - не приспособлена. Вот тут: http://wstaw.org/m/2013/03/03/plasma-desktopk17204.png коре2дуо без гипертрединга, но на висервер 2003 - падения нету такого...

у тебя MS SQL ?

(565) ага, 2003

вернее 2005

может дело еще в СУБД. На каждый поток Postgre по процессу создает. На большом количестве потоков вырастает обращение к журналу диска, сами данные читает/записывает меньше. Да и винт у меня не скоростной.

(568) убери fsync из конфига

в смысле fsync = off

Пробовал запускать в веб клиенте, виснет на 16-и потоках, потом пришлось перезапускать и сервер приложений с чисткой кэша и апач.

(571) Вообще вся работа ведется на сервере, на клиенте только проверяет сообщения от заданий. А в тонком - работает?

Еще есть нюанс - на бесплатном линух-сервере не дает больше 12 соединений (т.е. клиент + 11 фоновых одновременно), соответственно, оно падает с ошибкой невозможности синхронизации потоков. а поскольку времени на синхронизацию - 30 секунд, то всего надо подождать примерно 30 * 4 (количество под тестов) * 7 (количество тестов с количеством потоков больше 12)

секунд

(557) ну, круги я вводил, чтобы сгладить флуктуации, которые на самом деле из-за неправильной синхронизации возникали. Соответственно, когда сделал синхронизацию через блокировку константы, проверил на 1 и на 2 кругах. вроде на 2-х было поплавнее, но и на 1 вполне приемлемо.

(570) бу-га-га. результаты стали хуже...

(575) jge,kbrjdfk&

опубликовал?

кстати, поправь в конфиге постгре максимум соединений, а то у тебя тесты в 112 потоков не выполняются :)

(575) ну, максимум стал больше

ну и до 8 потоков (т.е. до упирания) - все результаты больше

(578) я их закоментировал. он не пережевывает 112 потоков, может и конфиг надо поправить.

(581) ЕМНИП там по дефолту max connections  100

(580) а потом регрес

(583) может по памяти проседает (iops)?

ведь без fsync оно больше нагрузки на память и меньше на диск дает

или по кэшу процессора

после 16ти потоков диск больше 2Мб не грузит, Проц - 50-70%, память тоже не кушает. Просто операций много, и он не успевает их отрабатывать.

(587) дело не в количестве сожраной памяти, а в показателе "обмен страниц", или как там его...

(588) написал в почту

(572) В тонком не пробовал.
(582) Спасибо, напомнил, на сервере с ключом тоже 112 потоков не отрабатывало.

Что-то тест не то меряет. У человека на ноутбуке с винтом на 5400 показывает результат как у меня на двух отдельных серверах с СХД. Только у меня 150 пользователей работают. А на ноуте я не думаю что больше 3-4 сможет что-то делать по настоящему.

Я про последние 2 записи в опубликованных.

У меня как-то ровно графики пришли в насыщение около 16 потоков. И все шли вместе около 4500. У других смотрю регистры бухгалтерии убегают раза в два-три выше остальных.

(593) ну, во первых - в один поток у тебя на разных серверах, а на ноуте - все на одной машине, и у тебя все равно на 20% большк. а во вторых - в 32 потока больше уже на 80% :)

Ну а там, где РБ вылезают вперед - там MSSQL, вроде как.

(593) кстати, если не сложно, заполни информацию о сервере СУБД и нажми "опубликовать" еще раз, пожалуйста.

Отметился еще раз. Тесты больше 64-х потоков закомментировал, потому что тест на синхронизацию для 112-и потоков подвис, хотя max connections поставил 500(и перегрузил postgres), непонятно...

(596) а после правки конфига постгре рестартовал?

(597) Да.
Потом попробую еще на тонком клиенте.

(544) прикрутил

600