Сервер, не справляющийся, средние числа загрузки ЦП пронзают к 33,0

Число «средней загрузки» на самом деле не является загрузкой - это количество потоков в «запущенном» или «работающем» состоянии. Вышеупомянутые потоки могут ожидать чего-либо, например, операций подкачки или ввода-вывода (что было бы плохо с точки зрения производительности, ввод-вывод обычно является общим ресурсом, и если несколько потоков ожидают этого, велики шансы, что еще больше присоединится к очереди ожидания).

В настройке с работающим сервером MySQL я видел аналогичные цифры из-за конфликта блокировок в популярной таблице во время длительных операций обновления . Вы можете проверить это, введя команду SHOW PROCESSLIST вашему серверу MySQL (PHPMyAdmin даже предоставляет это как функцию). Самым быстрым решением для этого было включение обновлений с низким приоритетом в конфигурации MySQL.

Вам нужно получить более подробные показатели, чтобы определить проблему.

Я обычно просматриваю

• disk io
• ram usage
• swap usage
• network usage
• ] соединений / сек в apache
• запросов / сек в базе данных
• брандмауэра проблемы
• сетевого стека (например, время ожидания, открытые соединения)

Отсюда я перехожу к журналам для Apache, MySQL и система.

Наконец, обращайтесь к любым проблемам, связанным с приложением.

Некоторые инструменты:

• Munin или Cacti (или другой инструмент для получения подробной статистики)
• Sysstat и связанные инструменты (iostat, vmstat и т. Д.)
• Расширенный статус в Apache
• Журнал медленных запросов в MySQL
• Отчет о кешировании для любых кешей кодов операций, кэша памяти и т. Д.
• http://www.webpagetest.org/ для проверки внешнего интерфейса
• Для проблем с приложениями, некоторые из моих клиентов добились успеха с New Relic

. С хорошим набором инструментов и систематическим подходом обычно можно начать разгадывать проблему.

Некоторые полезные тесты:

• Доступ к статическому содержимому (img или css)
• Доступ к странице phpinfo или hello world
• Доступ к странице php с простым подключением к базе данных и закрытие
• Доступ к странице php с соединение с БД, выберите, закройте
• Доступ к странице php с соединением с БД, запись и закрытие
• Доступ к вашему веб-приложению

По времени каждого из этих тестов вы можете начать выяснять, где может происходить задержка. Я видел, как сильно загруженные серверы очень быстро возвращают статический контент. Время до первого байта было очень низким. Это указывает на проблему на прикладном уровне. Продолжая работать со стеком приложений, пока не найдете замедление.

Хотя это утомительно,

Это происходит регулярно? То есть, каждый день вы знаете, когда это произойдет?

Задания Cron выполняются в это время?

Какие процессы (top или htop должны отображать это) запущены?

Какая дисковая подсистема у вас запущена? Тип RAID? Тип контроллера? (по разным каналам ...?)

Загрузка сервера - это не только загрузка процессора. Это может быть перегрузка сети или перегрузка дисковой системы.

Вы проверяете свои диски на наличие проблем с дисками? Один из возможных сбоев?

Вам нужно сузить круг вопросов, что именно происходит, если это проблема с базой данных, вы получаете реальное количество посещений веб-сайта, как выглядит ваш трафик, есть ли сообщения в журналах, сервер выполняет какое-то пакетное задание, которое сильно нагружает дисковый ввод-вывод ...? Любая из этих вещей может вызвать скачок "нагрузки" сервера. Вам нужно будет сузить круг вопросов, где и что в данный момент идет не так. Если это происходит каждый раз почти в одно и то же время дня, проверьте расписания cron и все, что может выполнять служебные функции на сервере, включая резервные копии или дампы дисков.

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

Мне нужно сузить круг вопросов, где и что в данный момент идет не так. Если это происходит каждый раз почти в одно и то же время дня, проверьте расписания cron и все, что может выполнять служебные функции на сервере, включая резервные копии или дампы дисков.

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

Мне нужно сузить круг вопросов, где и что в данный момент идет не так. Если это происходит каждый раз почти в одно и то же время дня, проверьте расписания cron и все, что может выполнять служебные функции на сервере, включая резервные копии или дампы дисков.

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

Масштабирование для нетерпеливых или просто ленивых:

• Кэшировать результаты БД (memcached) и статические данные (varnish, nginx);
• Отдельное обслуживание ресурсов от обслуживания приложений (изображения, js , css, обслуживать это с другого хоста);
• Отделять БД от приложения;
• Балансировать нагрузку при доступе к приложению на нескольких серверах;

Конечно, вы должны сделать это, прежде чем проверять свой сервер, как сказал Барт и уверен, что сервер делает все возможное. Я имею в виду, что если есть место для улучшения вашего текущего дизайна, сделайте это в первую очередь, но даже в этой ситуации кеширование очень поможет.