Назад | Перейти на главную страницу

Высокая загрузка ЦП, приводящая к сбою сервера

заканчиваются идеи для изучения. Во-первых - позвольте предупредить - я программист, а не системщик :)

Вот такая ситуация.

Выделенный сервер (LAMP), на котором работает большое количество сайтов. Сервер mySQL находится в отдельном ящике.

Последние пару недель производительность неуклонно снижается до такой степени, что я больше не могу даже дистанцироваться от коробки.

Если посмотреть на mod_status, то можно увидеть, что довольно много процессов занимают ресурсы процессора. Однако все URL-адреса разные ... нет единого шаблона, поэтому я не могу сузить что-либо до конкретного сценария, который может застрять.

PHP запускается как cgi.

Большинство сайтов, запуск которых требует времени, используют фреймворк cakephp.

Перезагрузите сервер, через несколько минут мы снова отключимся ...

Пересекла ошибку, в которой говорилось, что / var / tmp / заполнен и не может записывать сеансы. Однако еще оставалось место? Возможно, отсутствие inodes? Сейчас кто-то подойдет к ящику и очистит tmp.

Может ли отсутствие возможности писать сеансы заставлять процессы php зависать навсегда и в конечном итоге все засорять?

Есть ли другие идеи, которые я мог бы захотеть изучить? Я наблюдал за сервером sql, чтобы узнать, возвращает ли он огромные наборы данных в любом из запросов, и там нет ничего примечательного ...

Сейчас только 11:21, а мне уже нужно выпить :)

Я полагаю, это проблема с памятью.

  1. Apache жрет много оперативной памяти.

  2. У PHP также много утечек памяти. Вы должны настроить его на перезапуск рабочих потоков после обработки небольшого количества запросов (100 - хорошее число). Поищите в /etc/init.d/php-cgi (или аналогичном) строку «PHP_FCGI_MAX_REQUESTS = 20» ... это ограничение. Также установите разумный предел для количества детей, например «PHP_FCGI_CHILDREN = 15». Я также предлагаю вам использовать php-fpm, если это возможно, он намного более стабилен и имеет меньше утечек памяти.

ДЕЛАТЬ:

  1. Попробуйте поискать убитые процессы в вашем системном журнале (/ var / log / syslog или / var / log / messages в зависимости от распределения). Может быть такой намек.
  2. Чтобы отследить проблему, попробуйте использовать «atop» (монитор процессов, например, top, но с некоторыми дополнительными функциями) и нажмите «p», чтобы собрать всю статистику по именам процессов. Посмотрите, что съедает RSIZE.

Вам действительно нужно смотреть изнутри коробки, а не снаружи, поэтому посмотрите, какой ресурс потребляется.

Я предполагаю, что пул процессов apache исчерпан (поэтому никто не может подключиться) или физическая память исчерпана (поэтому производительность падает с обрыва).