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

Как я могу точно определить, что заставляет мой веб-сервер работать медленнее?

Я подозреваю, что часто используется какой-то конкретный большой файл или URL, но я не могу понять, какой именно. Рекомендуются ли какие-либо стандартные инструменты или шаги для устранения неполадок? Спасибо!

Ну, моим первым инстинктом, если бы я считал, что замедление происходило из-за чрезмерного трафика по URL-адресу или файлу, было бы проверить журналы веб-сервера или любую имеющуюся аналитику. Это расскажет вам, какой трафик вы испытываете.

Если вы считаете, что проблема связана с пропускной способностью, вы можете проверить несколько вещей:

  • Упомянутый в другом ответе проверяет журналы доступа / ошибок, чтобы получить историю любых клиентов, создающих больше трафика, чем обычно. Если это небольшой сайт, вы можете вручную просмотреть журналы. В противном случае просмотрите анализ / визуализацию журнала для этого типа журнала.
  • Если у вашего провайдера есть график / дисплей использования сети для вашего сервера, вы можете использовать его в качестве приблизительного руководства, чтобы узнать, есть ли / когда есть какие-либо всплески использования.
  • Вы можете использовать ifconfig -a, чтобы посмотреть на необработанное использование сетевых интерфейсов вашего сервера.
  • Вы можете использовать netstat -an для вывода списка всех текущих подключений.
  • Используйте модуль состояния Apache / lighttpd (или аналогичный модуль для вашего серверного приложения), чтобы отобразить текущий список подключенных клиентов.
  • Не думайте, что проблема обязательно связана с пропускной способностью, особенно если в журналах / статистике нет ничего необычного.
  • Подумайте об установке какого-либо приложения для мониторинга, если вам трудно найти проблему, когда она возникает.

Следующие два сценария я использую, чтобы получить общее представление о статусе соединений на сервере с помощью netstat. Первый просто отображает количество подключений в зависимости от типа подключения:

  #!/bin/sh
  # Display number of connections on a server
  #
  echo -n $"Established: "
  netstat -an | grep ESTABLISHED | wc -l

  echo -n $"   Syn Recv: "
  netstat -an | grep SYN | wc -l

  echo -n $"       Wait: "
  netstat -an | grep WAIT | wc -l

  echo -n $"     Listen: "
  netstat -an | grep LISTEN | wc -l

  echo -n $"      Total: "
  netstat -an | wc -l

Обратите внимание, что наличие большого количества соединений в состоянии WAIT является нормальным (по крайней мере, из того, что я наблюдал). Большое количество SYN-соединений может использоваться для DOS-атаки SYN-флуда.

Следующий сценарий подсчитывает количество установленных подключений по IP-адресу и полезен, чтобы увидеть, есть ли один конкретный некорректный IP-адрес.

#!/bin/sh
# Counts the number of connections by IP address

netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Если ваш сервер находится под большой нагрузкой и у вас есть 1000 подключений, этот скрипт может занять немного времени (~ 1 минуту в худшем случае, который я видел).

Обратите внимание, что в зависимости от вашего приложения несколько записей на IP - это не обязательно плохо. Например, в моем случае 10-20 записей / IP - это нормально, но превышение этого количества подозрительно. Я видел «плохие» IP-адреса, которые либо запрашивали один и тот же документ / файл 100 раз, либо просматривали каждый файл на сайте и загружали его. Последний скрипт позволяет относительно легко определить эти IP-адреса, которые вы затем можете использовать для просмотра в своих журналах более подробной информации, если это необходимо.

Не существует общего способа отладки плохой производительности веб-сервера, но есть некоторые инструменты, которые могут быть вам полезны. Я предполагаю, что вы используете какой-то HTTP-стек под Linux.

  1. Регистрируйте количество времени, необходимое для обработки каждого запроса. (в apache вы можете установить LogFormat на: LogFormat %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" % T /% D combined Затем попробуйте определить самые длинные GET или POST из файла журнала.
  2. Анализ файла журнала практически в реальном времени можно выполнить с помощью команды apachetop (для файлов журнала в формате apache, не обязательно сгенерированных apache) apachetop -f /var/log/apache2/access.log даст вам хороший обзор ожидающих запросов
  3. На стороне клиента вы можете использовать некоторые инструменты веб-разработчика, чтобы определить, какие элементы наиболее загруженного сайта загружаются медленно. Я бы рекомендовал firebug http://getfirebug.com/ плагин для firefox.
  4. Проверить производительность диска на сервере. Использование поверх http://www.atoptool.nl/ вы можете быстро определить, какие диски заняты на 100%. Это может быть проблемой, особенно когда вы используете ядро ​​базы данных (mysql или pgsql) на тех же хостах и ​​испытываете высокий трафик.
  5. Apache не должен обслуживать большие статические файлы. Лучший способ заставить apache работать хорошо - это обслуживать все, что вы можете, другими легковесными серверами (например, nginx, lighthttpd ...). Попробуйте найти самый большой файл, обслуживаемый вашим веб-сервером, и обслуживать их через nginx.
  6. Также проверьте статистику использования полосы пропускания. Если вы достигнете пределов своей сети, страницы будут загружаться намного медленнее, а сервер будет загружаться выше.

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

Рассмотрите возможность мониторинга системы с помощью такого инструмента, как sar или Munin. Это даст вам информацию о том, какой компонент наиболее загружен. Мне нравится Munin за его графические отчеты, а также за возможность устанавливать оповещения. sar дает подробную информацию о диске и свопинге.

Включение времени обслуживания в журнал Apache полезно. Я обычно меняю поле удаленного логина (идент) (%l) со временем, затраченным на обслуживание запроса (%T) в расширенном формате журнала.