При небольшой нагузке сервер nginx, centos один раз в день стабильно ложится. В чём может быть причина?

Question

[1serfer]

При небольшой нагузке сервер nginx, centos, php-fpm один раз в день ложится.
Есть предположение, что у него перекур или обеденный перерыв... )

load average: 0.40-0.50

php.fpm и mysql также особо не напрягаются.

Посетителей в день не много.

Обновляю сервер и все пакеты до сегодняшнего дня и также не помогает.

Настройки в php-fpm.d:

pm = dynamic
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 100000

Кто сталкивался с такими проблемами?

Comments

[Валентин]

А что именно ложится? Nginx, php-fpm, mysql?

Answer 1

[Игорь]

Рекомендую поставить на сервер munin и atop.
В atop сделайте интервал снятия статистики 60 сек.

Через сутки уже по этим данным поймете какой ресурс исчерпывается и какой процесс при этом виноват.

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

Comments

[1serfer]

Спасибо за совет. Очень сильно.

[Игорь]

Посмотрите еще, нет ли у Вас какой задачи по cron на время падения сервиса.

[1serfer]

Следуя вашему совету поставил atop и добавил из этой статьи habrahabr.ru/post/114082 htop
И перед очередным зависанием сервера нагрузка на VIRT в mysql зашкаливала и показывала 10Gb
Скорее всего дело в настройке mysql и запросах к базе

[Игорь]

Запустите на сервере скрипт: https://raw.githubusercontent.com/major/MySQLTuner...

[Игорь]

он выдаст рекомендации по тюнингу mysql

[1serfer]

Спасибо, хороший скрипт!
Вроде как проблема решена.
Найдена ошибка в коде. Делался запрос в базу всех записей, включая текстовые поля. Вытягивалось всё и сравнивалось. Вроде как запрос оптимизирован. Это он забирал всю memory и глушил mysql
Буду мониторить.
Всем Спасибо за Полезные советы!

Answer 2

[Alexey Lesovsky]

1. каков cpu usage в момент лежания? интересует полностью строка %Cpu(s): из вывода top.
2. интересует состояние все процессов nginx в момент валяния, можно получить с 'ps aux |grep nginx'
3. смотрели в nginx/error_log и /var/log/messages на предмет криминала?

Comments

[1serfer]

cpu usage в момент лежания 0.20-0.18 иногда меньше до 0.8-0.3
лог nginx чист как слеза )
единственно я ниже написал, что php-fpm жалуется
WARNING: server reached pm.max_children settings (9) consider raising it
увеличил до 30-ти
Спасибо за совет! Сегодня буду мониторить и ждать время X чтобы заняться анализом

Answer 3

[Александр]

Была схожая проблема. Ложиться весь сервер целиком либо LAMP? У меня проблема с выделением памяти под Мускульные запросы. php-fpm создавал кучу инстансов и почему-то имеет больший приоритет у диспетчера памяти. Уменьшь
pm.start_servers = 2
pm.min_spare_servers = 3
pm.max_spare_servers = 3
pm.max_children = 5

посмотри что будет

В мускуле какой движок? Если Иннодб, то можно попробовать уменьшить размер буфера innodb_buffer_pool_size. Сейчас какой стоит?

Comments

[1serfer]

движок мускуля myisam.
Конфиг мускуля:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

init-connect="SET NAMES cp1251"
#slow_query_log_file=/var/log/mysqld_slow_query.log
#long_query_time=5
#log-queries-not-using-indexes=1
#slow_query_log=1

#+++++++

#query_cache_size=128M
#sort_buffer_size=128M
#read_rnd_buffer_size=1024K
#tmp_table_size=256M
#max_heap_table_size=256M
#thread_cache_size=8
#key_buffer_size=7000M
#query_cache_limit=128M

port=3306

# MyISAM #
key_buffer_size = 7G
myisam_recover = FORCE,BACKUP

# SAFETY #
max_allowed_packet = 16M
max_connect_errors = 1000000

# CACHES AND LIMITS #2
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_type = 1
query_cache_size = 8M
query_cache_limit = 8M
max_connections = 500
thread_cache_size = 50
open_files_limit = 65535
table_definition_cache = 4096
table_open_cache = 4096
sort_buffer_size = 8M
read_rnd_buffer_size = 1024K

# CACHES AND LIMITS #1
#tmp_table_size = 256M
#max_heap_table_size = 256M
#query_cache_type = 1
#query_cache_size = 128M
#query_cache_limit = 128M
#max_connections = 500
#thread_cache_size = 50
#open_files_limit = 65535
#table_definition_cache = 4096
#table_open_cache = 1000

#sort_buffer_size=128M
#read_rnd_buffer_size=1024K

# INNODB #
#innodb_flush_method = O_DIRECT
#innodb_log_files_in_group = 2
#innodb_log_file_size = 32M
#innodb_flush_log_at_trx_commit = 1
innodb_file_per_table = 1
#innodb_buffer_pool_size = 8M

#+++++++

# Semisynchronous Replication
# dev.mysql.com/doc/refman/5.5/en/replication-semisy...
# uncomment next line on MASTER
;plugin-load=rpl_semi_sync_master=semisync_master.so
# uncomment next line on SLAVE
;plugin-load=rpl_semi_sync_slave=semisync_slave.so

# Others options for Semisynchronous Replication
;rpl_semi_sync_master_enabled=1
;rpl_semi_sync_master_timeout=10
;rpl_semi_sync_slave_enabled=1

# dev.mysql.com/doc/refman/5.5/en/performance-schema.html
;performance_schema

[mysqld_safe]
log_error=/var/log/mysqld.log
pid_file=/var/run/mysqld/mysqld.pid

Answer 4

[Пума Тайланд]

параметры сервера в студию

Answer 5

[1serfer]

После прочтения логов, наткнулся на интересные сообщения:
WARNING: server reached pm.max_children settings (9) consider raising it

Увеличил с 9 до 30

Посмотрю что будет сегодня. Неужели в этом может быть причина перекуров и просто не хватало процессов?

Comments

[Alexey Lesovsky]

если выяснится что дело в нехватке "чилдренов", то следует копать глубже и искать причину почему их недостаточно. Из возможных причин:
- долгие коннекты (искать что тормозит, сам php или запросы в базе)
- может тупо большой трафик пришел к вам.

[1serfer]

Спасибо огромное!