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

Выделенный сервер Nginx, используемый для css / js / images, совершенно крут, но изображения загружаются медленно. Зачем?

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

Все серверы отлично работают на New Relic, особенно сервер статических файлов:

Проблема в том, что в часы пик, очевидно, изображения (которые могут быть размером от 100 до 200 КБ) загружаются у некоторых пользователей долго (много-много секунд, иногда даже до минуты, тогда как обычно это занимает всего несколько секунды в худшем случае).

Есть идеи, что мы могли сделать? В идеале, если ни ЦП, ни ОЗУ, ни пропускная способность не достигли какого-либо предела, этого не должно происходить.

Какие ключевые параметры конфигурации Nginx мы должны рассмотреть (и, возможно, изменить)?

Я могу думать о двух возможностях.

  1. Ваш диск достиг предела ввода-вывода.
  2. Вы достигли предела рабочего потока в nginx. Посмотрите на worker_ * параметры конфигурации из основного модуля и worker_connections из модуля «События», чтобы узнать, как это увеличить. По умолчанию это один рабочий процесс, который является однопоточным, поэтому, если вы работаете на платформе с несколькими процессорами, вам обязательно нужно его увеличить. Даже если вы используете блок с одним процессором, вы выиграете от увеличения этого числа на машине, обслуживающей статические ресурсы, так как дисковый ввод-вывод будет привязан задолго до чего-либо еще, а другие потоки могут получать и обрабатывать больше запросов, пока первый сидит в ожидании загрузки данных с диска.

Мы могли бы сидеть здесь и гадать, где у вас узкое место в течение всего дня, но несколько более общих советов помогут вам найти его самостоятельно гораздо раньше.

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

В вашем случае я бы сначала использовал Firebug, чтобы определить, какой бит запроса в часы пик работает медленно. Это должно исключить пропускную способность, если пропускная способность не является настоящей проблемой. Посмотрите в разделе «Сеть» Firebug и посмотрите, какая часть запроса изменяется между быстрым и медленным временем.

После этого я бы запустил strace с обоими -t и -T варианты на одном из рабочих nginx во время одного из этих медленных периодов. Анализ результатов должен показать вам, где именно nginx работает медленно. Полезно записать вывод strace в файл, а затем использовать less или grep в файле, чтобы определить системные вызовы, которые потребовали много времени.

Вы можете получить пользу от -c вариант на страже.

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

Если выясняется, что это системный вызов на основе файлов, обязательно просмотрите трассировку назад, пока не найдете файл, который он ожидал. Это будет большой намёк.