Система мониторинга

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (1)

просмотр истории страницы
...
Для решения проблемы потребовалось перенести базу на отдельный SSD диск с высокими показателями IOPS.

h2. check_free_memory.sh

{code}- check_free_memory.sh: ERROR(2) [FAILED]

ALARM Мало свободной памяти

Подробная информация записана в файл /app/base/var/log/check_free_memory.log
10
{code}

Тест пишет об ошибке когда на сервере осталось менее 20% свободной ОЗУ. SWAP при этом не учитывается.
Последняя строка в выводе ("10" в примере выше) - это процент свободной ОЗУ.

Диагностику можно посмотреть в логе:
{code}/app/base/var/log/check_free_memory.log{code}

Там Вы наёдете вывод двух команд, выполненных при наличии ошибки:
* *ps axSk-rss -F* - список запущенных процессов, отсортированных по объёму занимаемой памяти
* *pstree -upal* - список процессов в виде дерева

h3. Как именно работает тест

Разберём на примере вывода команды free:
{code:title=Команда}free -m | grep -E 'total|^Mem'{code}
{code:title=Вывод}
total used free shared buffers cached
Mem: 5707 5324 382 25 681 1412
{code}

Что делает тест:
# Получает количество памяти: в примере это total = 5707
# Вычисляет свободную папять: складывает free, buffers и cached, то есть 384+681+1412, получается 2477
# Получает свободную память в процентах: в примере выше - 2477*100/5707, получится 43%
# Если свободной памяти меньше 20%, то:
#* Пишет диагностику в лог check_free_memory.log
#* В логе системы монторинга сохраняется информация что тест завершился с ошибкой
# Если проблема повторится 5 раз за час, то создаётся автоматическая заявка.

h3. Как понять на какие процессы ушла память?

Причины могут быть разными и зависить от конкретного процесса.

Методика определения причины:

# Убедитесь, что Ваш сервер соответствует [системным требованиям|CarbonBilling:Системные требования]:
#* Количество ОЗУ достаточно
#* Скорость работы ОЗУ сотвтетствует требованиям
#* Процессор поддерживает работу с памятью на требуемой частоте
# Если с требованиями всё в порядке, обратитесь к логу *check_free_memory.log*, типичная ситуация когда 1-2 процесса требуют больше всего памяти
#* Посмотрите что это за процессы и попробуйте найти в Google информацию о проблемах с назвапнием процесса и высоким потреблением памяти, например "[mysqld high ram|https://www.google.com/search?q=mysqld+high+ram&oq=mysqld+high+ram]"

Что ещё может оказаться полезным:
* Убедитесь что занято не более 500Мб SWAP:
{code:title=Команда}free -m | grep -E 'total|Swap'{code}
{code:title=Вывод}
total used free shared buffers cached
Swap: 5839 15 5824
{code} \\
** Если занято 300-500Мб, то это нормальная ситуация - некоторые системные программы и ядро могут использовать SWAP даже если есть свободная ОЗУ.
** Если занять более 500Мб - скорей всего ОЗУ системе уже недостаточно и нжуно анализировать на что она ушла, так как вместо части ОЗУ используется болеемедленный диск \\ \\
* Посмотрите потребление памяти конкретного процесса по его PID. Используя пример с тем же mysql:
** Узнаем PID
{code:title=Команда}ps aux | grep -E 'PID|/usr/libexec/mysqld.*port=3307' | grep -v grep{code}
{code:title=Вывод}USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
27 5064 0.0 0.5 377340 31624 ? Sl Jun05 2:43 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql ... --socket=/var/lib/mysql/mysql.sock --port=3307
{code}
** Посмотрим, занимает ли процесс место только в памяти, или ещё в SWAP
{code:title=Команда}cat /proc/5064/status | grep -E 'VmSize|VmSwap'{code}
{code:title=Вывод}VmSize: 377340 kB
VmSwap: 0 kB{code}

Пример выше делали на виртуальной машине где нет какой-либо проблемы, поэтому SWAP не занят. В действитеильности, документацию писали по кейсу где MySQL локального сайта заняла 44% ОЗУ и ещё 2Гб в SWAP, что явно говорило о проблема где-то в этой части системы.


h1. Тесты asr_billing

...