Приносим извинения за нечеткое название темы, резюмируя следующее, оказалось, что это немного сложно, в конце концов, это, как названо, необъяснимо. В общем, хватит отговорок ...
Сегодня утром я обнаружил, что мой веб-сайт работает очень медленно, теперь этого обычно не происходит, поэтому я, очевидно, пытаюсь отследить причину проблемы. Зная, что я ничего не устанавливал и не менял в последнее время, первым делом я должен был проверить статистику использования ресурсов, она не показывает ничего необычного:
load average: 0.35, 0.34, 0.36
Проверка этого параметра в течение примерно получаса (в течение которого пользователи сообщали о сбоях) никогда не показывает ничего выше 1. Так что это не «традиционная нагрузка». Поэтому я ищу другие возможные причины.
Top также не показывает ничего необычного:
top - 08:34:34 up 1:33, 1 user, load average: 0.30, 0.36, 0.35
Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
Cpu0 : 6.6%us, 1.3%sy, 0.0%ni, 91.1%id, 0.7%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 99.3%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4016884k total, 1367624k used, 2649260k free, 5324k buffers
Swap: 3919840k total, 0k used, 3919840k free, 769024k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2593 apache 15 0 446m 66m 40m S 7.6 1.7 1:13.64 httpd
2450 mysql 15 0 257m 48m 5976 S 0.3 1.2 4:20.51 mysqld
9734 root 15 0 12740 1296 932 R 0.3 0.0 0:00.24 top
1 root 18 0 10348 752 628 S 0.0 0.0 0:04.91 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1
Итак, я начал смотреть на сеть, следующую команду (которую я взял из вопроса SF о DDOS-атаках):
netstat -n | grep: 80 | cut -c 45- | cut -f 1 -d ':' | sort | uniq -c | sort -nr | more
Дает:
534
5 1.1.1.1
4 2.2.2.2
4 3.3.3.3
3 4.4.4.4
2 5.5.5.5
2 6.6.6.6
2 7.7.7.7
1 8.8.8.8
1 9.9.9.9
1 10.10.10.10
1 11.11.11.11
IP-адрес удален
В этом нет ничего необычного, хотя я не уверен, что означает этот 534. Для хорошей меры я также перезагрузил сервер (в силу привычки после столь долгого использования Windows;)), но это не имело никакого значения.
Так что теперь я в растерянности, я не могу объяснить, что здесь происходит, и это, конечно, означает, что я не могу это исправить.
Сведения о сервере Это выделенный сервер со следующими характеристиками:
Страницы PHP этого сервера сайта (только vbulletin) через Apache с серверной частью MySQL, я также использую APC в качестве кешера кода операции.
РЕДАКТИРОВАТЬ - Подробнее Может быть, а может и нет ...
Используя Firebug в Firefox, я смотрел время загрузки страниц. Кажется, что происходит то, что один случайный ресурс (иногда изображение, файл JS или файл CSS) требует чрезмерного количества времени для завершения приема. Запрос выполняется за несколько миллисекунд, но получение иногда занимает до минуты. Однако это случайный ресурс, каждый запрос, который я делаю, имеет другой ресурс, на возврат которого требуется много времени. У меня нет кеширования и т.п. для этих ресурсов, они обычно обслуживаются через apache из файловой системы.
РЕДАКТИРОВАТЬ Вывод из iostat:
Linux 2.6.18-164.11.1.el5 12/10/2010
avg-cpu: %user %nice %system %iowait %steal %idle
4.66 0.00 2.08 0.84 0.00 92.42
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 12.48 78.48 144.52 1008089 1856500
sda1 0.43 2.52 6.95 32354 89224
sda2 0.01 0.11 0.00 1356 0
sda4 0.00 0.00 0.00 10 0
sda5 0.48 5.33 1.61 68413 20706
sda6 11.57 70.51 135.97 905732 1746570
sdb 12.43 78.57 144.52 1009340 1856500
sdb1 0.43 2.24 6.95 28768 89224
sdb2 0.00 0.08 0.00 1068 0
sdb4 0.00 0.00 0.00 10 0
sdb5 0.45 5.35 1.61 68729 20706
sdb6 11.53 70.88 135.97 910533 1746570
md1 0.91 4.72 5.96 60666 76520
md6 14.70 141.37 126.26 1815945 1621898
md5 0.57 10.65 1.05 136822 13474
РЕДАКТИРОВАТЬ
Было бы полезно, если бы я дал вам URL-адрес сайта:
Что ж, если проблема возникает со статическими файлами, это хорошо, потому что, по крайней мере, вы знаете, что нужно начать смотреть на Apache. Вы, вероятно, захотите использовать инструменты отладки и профилирования, чтобы увидеть, что именно не так. Предполагая, что вы говорите о системе Linux, strace вероятно, инструмент, который вам нужен. С -f и -c options, он будет следить за всеми дочерними процессами и суммировать время, затраченное на каждый системный вызов. Надеюсь, это поможет вам разобраться в проблеме.
Остановите Apache, затем перезапустите его через strace:
strace -cf /usr/sbin/httpd
(у strace есть -p возможность отслеживать pid существующего процесса, но даже с -f он не отслеживает дочерние процессы, которые были разветвлены до вызова strace.)
Дайте ему поработать некоторое время, постучите по сайту, пока он работает, пока вы не сможете запустить замедление несколько раз, а затем прервите его. Анализируйте результаты.
Если выясняется, что проблема заключается в коде приложения пользовательского режима, а не в том, что делает система, существует сопутствующая программа под названием ltrace которые можно использовать для суммирования времени, потраченного на различные вызовы общей библиотеки.
Это, вероятно, само собой разумеется, но также проверьте журналы сервера, системы и ядра, чтобы убедиться, что вы не видите никаких неожиданных сбоев или аппаратных событий.
Какие меры вы предприняли, чтобы исключить проблему на стороне клиента? Минимальная нагрузка на сервер и периодическая задержка случайных запросов ресурсов заставили бы меня исключить сканер файлов в реальном времени как виновника. Это может быть далеко, но исключение должно быть тривиальным.