В основном у меня сервер выходит из строя под нагрузкой. Это редакционный новостной сайт, на котором наблюдаются нерегулярные всплески трафика. Я рву волосы, пытаясь стабилизировать конфигурацию ЛАМПЫ.
Current Time: Wednesday, 14-Dec-2011 15:13:06 SAST
Restart Time: Wednesday, 14-Dec-2011 14:08:44 SAST
Parent Server Generation: 0
Server uptime: 1 hour 4 minutes 21 seconds
Total accesses: 52825 - Total Traffic: 530.2 MB
CPU Usage: u281.32 s20.44 cu0 cs0 - 7.82% CPU load
13.7 requests/sec - 140.6 kB/second - 10.3 kB/request
19 requests currently being processed, 13 idle workers
Я сумасшедший или мой выделенный сервер должен легко справляться с этой нагрузкой?
Средняя загрузка обычно около 3, но дважды сегодня она поднималась до 30+; сбросила клиентов и вернулась к 2.
`` top '' не представляет особого интереса, поскольку mysql занимает 11% процессора.
По вашему мнению, это, возможно, проблема с оборудованием? Я вижу, что рейд может засориться из-за не отвечающего интерфейса ata в одном из таких случаев плохой нагрузки?
Сколько запросов в секунду, по вашему мнению, будет справедливым для коробки такого размера?
Вам нужно получить более подробные показатели, чтобы определить проблему.
Я обычно просматриваю
Отсюда я перехожу к журналам для Apache, MySQL и системы.
Наконец, обратитесь к любым вопросам, связанным с конкретным приложением.
Некоторые инструменты:
С хорошим набором инструментов и систематическим подходом вы обычно можете начать разгадывать проблему.
Несколько полезных тестов:
Выбрав время для каждого из этих тестов, вы сможете понять, где может происходить задержка. Я видел, как сильно загруженные серверы очень быстро возвращают статический контент. Время до первого байта было очень низким. Это указывает на проблему на прикладном уровне. Продолжайте работать со стеком приложений, пока не найдете замедление.
Этот утомительный процесс сослужил мне хорошую службу, и как только вы к нему привыкнете, вы сможете быстро его преодолеть.
Число «средней загрузки» на самом деле не является загрузкой - это количество потоков в «запущенном» или «работающем» состоянии. Вышеупомянутые темы жестяная банка ждать, чтобы что-то произошло - например, операции подкачки или ввод-вывод (что было бы плохо с точки зрения производительности, ввод-вывод обычно является общим ресурсом, и если несколько потоков ожидают его, велики шансы, что еще больше присоединится к очереди ожидания ).
В настройке с работающим сервером MySQL я видел похожие цифры из-за заблокировать конкуренцию в популярной таблице во время длительных операций обновления. Вы можете проверить это, введя команду SHOW PROCESSLIST вашему серверу MySQL (PHPMyAdmin даже предоставляет это как функцию). Самым быстрым решением для этого было включение обновлений с низким приоритетом в конфигурации MySQL.
Масштабирование, для нетерпеливых или просто ленивых:
Конечно, вы должны сделать это, прежде чем проверять свой сервер, как сказал Барт, и уверен, что сервер делает все, что может. Я имею в виду, что если есть место для улучшения вашего текущего дизайна, сделайте это в первую очередь, но даже в этой ситуации кеширование очень поможет.
Это происходит регулярно? То есть каждый день знаешь о том, когда это произойдет?
Задания Cron запущены в это время?
Какие процессы (top или htop должны показать это) запущены?
Какая дисковая подсистема у вас работает? Тип RAID? Тип контроллера? (на разных каналах ...?)
Загрузка сервера - это не просто загрузка процессора. Это может быть перегрузка сети или перегрузка системы привода.
Вы проверяете свои диски, чтобы увидеть, есть ли проблемы с дисками? Один, возможно, не работает?
Вам нужно сузить, что именно происходит, если это блокировка базы данных, вы получаете реальное количество посещений веб-сайта, как выглядит ваш трафик, есть ли сообщения в журналах, есть ли на сервере какое-то пакетное задание, которое сильно нагружает дисковый ввод-вывод ...? Любая из этих вещей может вызвать резкий скачок «нагрузки» на сервер. Вам нужно будет сузить круг вопросов, где и что в данный момент идет не так. Если это происходит каждый раз почти в одно и то же время дня, проверьте расписания cron и все, что может выполнять служебные функции на сервере, включая резервные копии или дампы дисков.
Если это связано с чем-то еще ... возможно, обновлением определенного типа новостей ... проверьте использование полосы пропускания. Проверьте свои журналы, чтобы убедиться, что вы не подвергаетесь сканированию или проверке со стороны злоумышленников.