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

Где искать узкое место при замедлении загрузки?

Скачивание изображений с нашего сайта каждый вечер замедляется. По сравнению с дневным временем мы получаем на 50% больше трафика за вечер. По точным данным, в дневные часы почасовое количество просмотров страниц составляет около 20 тысяч, в вечерние часы почасовое количество просмотров страниц составляет около 30 тысяч.

Мы на Apache, Centos 5, PHP 5, MySQL.

На графике ниже показано время загрузки определенного изображения размером 3 МБ с определенного удаленного сайта каждые 10 минут. По мере увеличения посещаемости сайта скорость загрузки падает вдвое.

У нас невысокая загрузка процессора. У нас есть два четырехъядерных процессора.
Память 32 ГБ.
Mysql использует около 10 ГБ этой памяти.
Состояние сервера Apache показывает около 40-50 одновременных процессов в часы пик. Каждый процесс занимает около 30-40 МБ резидентной памяти. Таким образом, Apache получает примерно 2 ГБ памяти.

Остальная часть памяти, около 20 ГБ, остается для использования Linux. vmstat, free -m не показывают подкачки. Вот вывод vmstat:

# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0    220 409700 491656 25727136    0    0     9    42    1    1  1  0 98  0  0
 2  0    220 408076 491656 25727140    0    0     0  2032 1916 1992  2  1 98  0  0
 0  0    220 405848 491656 25727180    0    0     0     0 1631 1325  1  0 99  0  0
 0  0    220 404992 491656 25727180    0    0     0     0 1508 1203  1  0 99  0  0
 3  0    220 405228 491656 25727216    0    0     0     0 1548 1600  2  1 98  0  0
 0  0    220 404236 491656 25727224    0    0     0     0 1860 1645  2  1 97  0  0
 1  0    220 403916 491656 25727284    0    0     0  2512 1817 1035  2  1 97  0  0
 0  0    220 403900 491656 25727284    0    0     0  2164 1826 1678  1  1 98  0  0
 0  0    220 408908 491656 25727312    0    0     0   828 1636  952  1  0 99  0  0
 0  0    220 408544 491656 25727312    0    0     0     0 1844 1991  1  1 98  0  0
 1  0    220 407856 491664 25727328    0    0   180     0 1567 1194  4  0 96  0  0
 0  0    220 406772 491664 25727460    0    0     0     0 1290 1049  4  1 95  0  0
 0  0    220 406964 491664 25727548    0    0    28   208 1589  904  1  0 99  0  0
 0  0    220 406840 491664 25727560    0    0     0  1796 1885 1396  1  0 99  0  0
 1  0    220 405136 491664 25727612    0    0     0     0 1727 1280  1  0 98  0  0
 0  0    220 404400 491664 25727628    0    0    24     0 1807 1494  1  0 98  0  0
 1  2    220 403996 491668 25727812    0    0   232     0 2221 1633  1  1 97  1  0
 0  0    220 404228 491668 25727844    0    0    20  1776 1673 1332  1  0 97  1  0
 0  0    220 403688 491672 25727988    0    0    68   348 1508  977  1  0 99  0  0
 0  0    220 403444 491672 25728004    0    0     0     0 1436  900  1  0 99  0  0
 0  0    220 403948 491672 25728104    0    0     0     0 1413 1131  1  0 99  0  0
 1  0    220 392984 491672 25728104    0    0     0  1520 1455 1946  5  2 93  0  0
 1  0    220 307264 491672 25728124    0    0     0    12 1829 1520  8  2 91  0  0
 4  0    220 306276 491672 25728132    0    0     0     0 1364 1497  7  0 92  0  0
 1  0    220 305320 491672 25728160    0    0     0     0 1510 1773  9  1 90  0  0
 1  0    220 305444 491672 25728164    0    0     0     0 1620 1666  7  0 93  0  0
 1  0    220 304456 491672 25728208    0    0     0  3396 1813 1836  7  0 93  0  0

Поскольку этот конкретный тестовый образ вызывается каждые 10 минут, он должен оставаться в кэше ОС и доставляться из кэша ОС, верно? Процессор вообще не занят. Значит, изображение должно быть доставлено довольно быстро?

В чем заключается проблема, с которой я сталкиваюсь?
-Может ли установка второго жесткого диска только для размещения образов?
-Как насчет использования PHP APC для снижения нагрузки на процессор?

Какие-либо советы по диагностике проблемы?

Спасибо, халук

ОБНОВИТЬ:
По совету Книтти, я установил тот же образ в каталог, смонтированный в памяти.
Ниже представлены результаты за вчерашний день:
объем памяти смонтированный образ размером 3 МБ:

Жесткий диск Изображение 3 МБ:

В среднем они очень близки. На них обоих влияет вечернее движение. Изображение из памяти иногда может быть доставлено медленнее, чем с жесткого диска. Думаю, это говорит мне, что они оба в памяти, какими должны быть.

Так что я думаю, что это не проблема узкого места жесткого диска.

-Может быть, это связано с Apache?
-Или связаны с сетью?

Вот sar -n ALL вывод для вечерних часов. В соответствии с этим мы не отправляем более 400 Кбит / с в среднем за 10 минут. Наша пропускная способность составляет 10 Мбит / с, поэтому мы еще не используем ее даже и половину.

                IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
08:10:01 PM        lo      0.63      0.63     66.48     66.48      0.00      0.00      0.00
08:10:01 PM      eth0    342.69    431.72  59755.43 368330.14      0.00      0.00      0.00
08:10:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:10:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:20:01 PM        lo      0.43      0.43     45.08     45.08      0.00      0.00      0.00
08:20:01 PM      eth0    310.96    389.32  62960.35 327811.74      0.00      0.00      0.00
08:20:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:20:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:30:01 PM        lo      0.68      0.68     71.97     71.97      0.00      0.00      0.00
08:30:01 PM      eth0    341.29    421.12  69692.70 354844.36      0.00      0.00      0.00
08:30:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:30:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:40:01 PM        lo      0.79      0.79     87.60     87.60      0.00      0.00      0.00
08:40:01 PM      eth0    365.76    451.49  66813.87 385379.38      0.00      0.00      0.00
08:40:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:40:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00

08:40:01 PM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
08:50:01 PM        lo      0.47      0.47     49.49     49.49      0.00      0.00      0.00
08:50:01 PM      eth0    336.77    413.37  57303.78 357556.44      0.00      0.00      0.00
08:50:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:50:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00


08:00:01 PM    totsck    tcpsck    udpsck    rawsck   ip-frag
08:00:01 PM       218        21         9         0         0
08:10:01 PM       200        21         9         0         0
08:20:01 PM       211        22         9         0         0
08:30:01 PM       205        22         9         0         0
08:40:01 PM       191        21         9         0         0
08:50:01 PM       201        21         9         0         0

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

Вам необходимо установить приоритеты для пакетов TCP ACK. Видеть http://phix.me/dm/

Вы можете проверить, поможет ли другой диск, если вы обслуживаете некоторые файлы с RAM-диска / памяти fs. Ничто не сравнится со скоростью памяти.
Вычислите скорость загрузки, умноженную на количество одновременных загрузок. Возможно, у вашего восходящего соединения недостаточно пропускной способности.
Проверьте из третьего (четвертого, пятого) места, чтобы убедиться, что вы не попали в ограничение на место загрузки.