Знаю, что первым в голову приходит разработчик, но нет 😅
Так как я больше специализируюсь на BAS, то в первую очередь речь пойдёт о нём.
У высоконагруженных, скоростных приложений вообще все проблемы растут из одной части — моего любимого слова: 🏎 Состояние гонки (race condition)
———
💾 1) Забивание диска
Думаю, многие с этим сталкиваются и костыли даже придумали.
BAS не удаляет профиль после работы, он остаётся и захламляет память.
Происходит так:
• Поток выполнил свою работу или кубиком послали сигнал закрыть браузер
• Браузер закрылся
• BAS послал команду на удаление
• Но некоторые процессы браузера ещё не завершились и не освободили файлы
• Команда повторяет попытку удаления файлов ограниченное количество раз, но процессы всё ещё не завершились и не освободили ресурсы
• В итоге удаление происходит раньше, чем освобождение ресурсов
✅ Данная проблема решаемая.
———
⏱️ 2) Таймаут во время выполнения LoadPage data:text/plain
Вообще дичь 2025 года 🤯
Проблемы у этой ноги растут из кучи мест:
• Недоступность сервера отпечатков
• Невозможность проверить лицензию отпечатка
↳ Тут чаще всего или сервер упал, или оператор блокирует пакеты
• Недостаток ресурсов (даже если их дофига)
• И остальные неизвестные причины
Много проблем доставляет эта ошибка авторам и пользователям, и на неё прям 100% решения нету 😔
📌 Рекомендации:
• Если из РФ подключение — софт обернуть в прокси, или проверить через браузер, что все домены BAS доступны
• Не использовать слишком мощное железо, при наличии такого — разбивать на виртуалки
• Следить за тем, чтобы не было узкого горлышка на сервере: RAM / скорость сети / CPU / скорость диска
• Хотя бы раз в сутки перезапускать софт, в идеале — весь сервер
———
🖥 3) Не видит свободные ресурсы
Если на сервере больше 32 ядер (64 логических процессора), то BAS видит только group 0.
Сколько я ни пытал сервер и ни пытался заставить это всё подружить, даже используя всякие CPU Affinity — ни к чему хорошему это не привело 🤷♂️ Он как будто не запускает/отказывается их видеть.
А если даже заставить работать, убрав ограничения и запуская кучу копий — появляется LoadPage data:text/plain.
В общем, если кто-то смог подружить BAS и мощные сервера без деления на виртуалки — буду рад решению 🙏
———
🗄 4) Гонка состояний при работе с базой
А эта ошибка — прям ядро всего 💥
Вообще успел я столкнуться с множеством проблем в этой части. Попробую как-то всё это структурировать.
Очень сильно раздувают базы — более 300-500к строк. Подобные объёмы приводят к сильному замедлению базы, особенно с SQL-запросами, что я видел от BAS.
🔄 Взятие 1 профиля в работу 2-5-10 раз подряд:
• Освобождается 2 потока, делают запрос «дай профиль»
• База даёт 1 потоку профиль
• 2 поток делает запрос «дай профиль»
• База отдаёт 2 потоку профиль
• Поток 1 обновляет у профиля статус, что он использовался
• Поток 2 обновляет у профиля статус, что он использовался
⚡️ Всё это происходит за 10-30 ms.
То есть задержка между взятием профиля и обновлением его статуса — при малых нагрузках и малом количестве строк 1-10 ms, и шанс очень мал, что такое будет, но не равен 0%.
Если потоков больше — этот отрезок увеличивается.
А если много потоков и ±500к строк, то между взятием профиля и сменой его статуса может пройти 1-2 минуты. Да, я видел, как проходило и 10 минут 😱 Думаю, тут даже страшно представить, сколько раз 1 профиль возьмётся в работу или в нагул.
💡 Решение... Тут только совет дам. Следите за здоровьем базы и количеством строк в ней.
Если RAM или CPU больше 70% нагрузки показывает — значит лучше уже задуматься над разделением баз или увеличением мощности.
Но лучше — разные базы 👍
[Задай вопрос] [