Попробуйте вообще сменить прокси, купите где нить в другом месте
Возможно такое что там где выпокупаете стоит ограничение на общий объем Вашего трафика и на 1 поток его хватает а когда начинаете запускать в много потоков то достигаете этого лимита.
Способы увеличения производительности в многопоточном режиме (200 потоков)
-
Всем привет!
Есть скрипт, который работает в 200 потоков: 180 потоков без браузера (http-клиент) и еще 20 потоков с браузером.
Все потоки постоянно активны: парсят, работают с БД, перезапускаются при необходимости и т.д.
Текущие параметры сервера: 24х4 ГГц, 24 Гб RAM, SSD-диск
Текущая нагрузка на сервере: ~35% по ЦП и ~50% по памяти (это средние данные по часу, которые дает хостер).Проблема
Скрипт периодически подвисает, что выражается в задержке выполнения действий внутри потоков на 0.5-3 сек (что критично для моего скрипта). Задержки встречаются чаще в моменты высокой нагрузки (очевидно): когда много потоков перезапускаются или когда много потоков массово одновременно что-то делают.Что уже сделано
- Давно выставлен плавный старт браузеров, не более 1 одновременно
- Отжата галка "Перезапускать процесс в начале работы потока"
- Я пробовал другой более мощный сервер (32 ядра, 120 ГБ памяти, NVMe диск) - ничего не меняется.
- Уменьшение числа потоков ниже примерно 130-140 штук сильно улучшает ситуацию и задержек почти нет, но это не вариант (хотелось бы еще больше, чем 200 потоков).
Вопрос: в какую сторону можно еще покопать, чтобы улучшить производительность и уменьшить задержки? Может ли помочь разделение скрипта на два по 100 потоков и запуск на одном сервере? Может для BAS на 200 потоков нужно какое-то особенное железо? В общем буду рад любым советам и наводкам.
-
@Int64 said in Способы увеличения производительности в многопоточном режиме (200 потоков):
Особо не понятно, потоки браузера тормозят или httpclient'a ?
Не перезапускай потоки с клиентом, пусть в цикле работают.Тормозят все потоки. Но 180 http-потоков выполняют основные задачи и задержки видны именно на них. Спасибо за совет, можно попробовать. Но задержки есть и в моменты, когда нет никаких перезапусков (просто в моменты перезапусков они сильнее), как с этим быть не ясно.
-
Чуть подробнее о том, в чем выражается задержка. Есть момент (допустим 18-00-00-000), в который 100 потоков должны отправить определенный http-запрос. Они "ждут" этот момент с помощью цикла while, который проверяет текущее время каждые 100 мс. Реальное время отправки этих 100 http-запросов составляет не 18-00-00-000 - 18-00-00-100, как можно было бы предположить, а 18-00-00-000 - 18-00-03-000, то есть разброс в 3 секунды вместо 100 мс.
-
@Q_Q это точно не поможет. При таких настройках, будет 180 папок, в которых будет копиться кеш, который через некоторое время будет "палить" и ломать логику (например будут видны запросы от предыдущих профилей). Мало того, кеш используется в каждом профиле по отдельности, так что никуда они не лезут "в одну папку".
-
-
@Ajshma said in Способы увеличения производительности в многопоточном режиме (200 потоков):
@doupiu как вариант, если вы используете внутри потоков код на nodejs, то это может быть узким местом для многопоточности, так как выполнение nodejs однопоточное.
Спасибо, помогла замена кубиков Node.js на чистый JS (Выполнить код). Хз почему, ведь JS же тоже однопоточный вроде 🤷