Я тестирую свое веб-приложение на основе Java (Grails), которое развернуто на Tomcat. На сервере работают следующие службы:
Хотя я понимаю, что в идеальном мире эти службы будут работать на трех отдельных серверах, я просто хочу посмотреть, как мое приложение ведет себя при некоторой нагрузке. Я обнаружил, что работает 20
потоки с периодом нарастания более 40
секунд кажется, что сервер не отвечает. Однако я не могу точно определить, что именно заставляет сервер перестать отвечать.
В то время у меня был SSH-вход, но когда он перестал отвечать, я больше не могу даже SSH войти в машину. Вот данные из TOP, когда он перестает отвечать, и я даже не могу подключиться к нему по SSH. Похоже, это не объясняет, почему он перестал отвечать.
Вопрос
Первое, что я хотел бы сделать, - это уменьшить вероятность того, что любой из этих процессов может занять больше времени ввода-вывода процессора или диска, чем ОС. Я предполагаю, что ваша ОС - Linux.
Обязательно сделайте резервную копию всех файлов конфигурации перед их редактированием.
Вы можете получить некоторые подсказки о поведении ОС непосредственно перед сбоем, просмотрев данные sar.
sar -A | more
Обязательно ищите подъем памяти или загрузки процессора. Вы можете запускать sar чаще, отредактировав /etc/cron.d/sysstat, если он установлен и включен.
Для каждой учетной записи службы, под которой работают ваши процессы, вы можете добавить следующее в /etc/security/limits.conf в конце файла.
apache soft priority 19
apache hard priority 19
rabbitmq soft priority 18
rabbitmq hard priority 18
mysql soft priority 10
mysql hard priority 10
Затем в каждом из сценариев инициализации для ваших демонов уменьшите выделенное им время ЦП и ввода-вывода.
cp -p /etc/rc.d/init.d/some_init_script ~/`date '+%Y%m%d.%H%M'`.some_init_script
vi /etc/rc.d/init.d/some_init_script
Добавьте во вторую строку сценария следующее, чтобы сократить временные интервалы ЦП и ввода-вывода:
renice 19 -p $$ > /dev/null 2>&1
ionice -c3 -p $$ > /dev/null 2>&1
Перезапустите каждую из ваших служб.
Предположим, что sshd по-прежнему не отвечает. Если вы устанавливаете «экран», тогда на разных экранах могут работать vmstat, iotop и другие инструменты. Есть шпаргалки по использованию экрана, поэтому я не буду останавливаться на этом здесь.
На этом этапе, даже если ваши службы выходят из-под контроля, вы все равно должны иметь возможность отправлять на сервер ssh, предполагая, что он не вызывает панику.
Вы можете дополнительно ограничить ресурсы, выделяемые каждому демону, привязав их к определенному ядру или процессору. Это можно сделать с помощью команды «набор задач». man taskset для получения более подробной информации о его использовании.
[править] Я также должен добавить, что это не поможет при определенных условиях спин-блокировки. Если вышеуказанное не помогает, возможно, вам придется запустить свои приложения на виртуальной машине и использовать ядро отладки или другие инструменты отладки.