В нашей компании есть три выделенных сервера: один работает под управлением Nginx и выступает в качестве веб-сервера (php), другой обрабатывает MySQL и Memcached, а третий используется для обслуживания статических файлов: css, js и изображений.
Все серверы в New Relic работают отлично, особенно сервер статических файлов:
- Загрузка ЦП постоянно ниже 10%
- Скорость ввода-вывода в сети очень низкая, скорость передачи данных составляет около 10 Мбит/с, но сервер MySQL имеет те же характеристики и обычно достигает пиковой скорости в 20 Мбит/с, поэтому сомневаюсь, что это проблема.
- Средняя нагрузка менее 0,5
Проблема в том, что в часы пик у некоторых пользователей загрузка изображений (размер которых может достигать 100–200 КБ) занимает много времени (много секунд, иногда до минуты, хотя обычно это занимает всего несколько секунд, в худшем случае).
Есть идеи, что можно сделать? В идеале, если ни процессор, ни ОЗУ, ни пропускная способность не достигли какого-либо предела, этого не должно происходить.
Есть ли какие-нибудь ключевые параметры конфигурации Nginx, на которые нам следует обратить внимание (и, возможно, изменить)?
решение1
Мне приходят в голову две возможности.
- Ваш диск достиг предела ввода-вывода.
- Вы достигли предела рабочих потоков в nginx. Посмотрите наработник_*параметры конфигурации из модуля Core ирабочие_соединенияиз модуля Events, чтобы выяснить, как это увеличить. По умолчанию используется один рабочий процесс, который является однопоточным, поэтому, если вы работаете на платформе с несколькими процессорами, вам определенно следует увеличить это. Даже если вы работаете на однопроцессорной системе, вы выиграете от увеличения этого числа на машине, обслуживающей статические ресурсы, поскольку вы будете связаны с дисковым вводом-выводом задолго до всего остального, а другие потоки могут получать и обрабатывать больше запросов, пока первый ждет, когда ему передадут данные с диска.
решение2
Мы могли бы сидеть здесь и гадать, где у вас узкое место, целый день, но несколько общих советов помогут вам найти его самостоятельно гораздо быстрее.
jeffatrackaid написалэтот ответ вчерачто является более краткой версиейто, что я написал довольно давно. Я бы рекомендовал сначала прочитать их, чтобы понять, как выполняется отладка производительности.
В вашем случае я бы сначала использовал Firebug, чтобы определить, какая часть запроса в часы пик становится медленной. Это должно исключить пропускную способность, если пропускная способность не является истинной проблемой. Посмотрите в разделе "Net" Firebug и посмотрите, какая часть запроса меняется между быстрыми и медленными временами.
После этого я бы запустил strace с опциями -tи -Tна одном из рабочих процессов nginx во время одного из таких медленных периодов. Анализ вывода должен показать вам, где именно nginx становится медленнее. Полезно записать вывод strace в файл, а затем использовать lessили grepв файле для определения системных вызовов, которые заняли много времени.
Возможно, вам пригодится -cопция strace.
После того, как вы определили медленные системные вызовы, все еще может потребоваться некоторая работа, чтобы выяснить, какой параметр nginx нужно изменить, но вы должны быть на верном пути. Пожалуйста, возвращайтесь и задавайте более конкретные вопросы, если вам нужна помощь с этой частью.
Если это окажется системный вызов на основе файла, обязательно просмотрите трассировку назад, пока не найдете файл, который он ждал. Это будет большой подсказкой.