Re[2]: nginx тормозит выдачу контента. помогите выпрямить мне руки.
vvs at onecd.ru
vvs at onecd.ru
Wed Dec 5 22:52:30 MSK 2007
>> >> >> Был Apache - контент отдавался со скоростью более 300Мбит.
>> >> >> Перешел на nginx+Apache. Скорость доходит до 120 МБит и после этого
>> >> >> падает до 99. На этой скорости и работает... Бэкенд не тормозит.
>> >> >> Ограничения на скачивания по кол-ву запросов с одного IP
>> >> >> были такими же - не более 3 одновременных (отключал - не влияет).
>> >> >> Сервер выдает файлы от 500Кб до 150Мб. Упора в дисковую
>> >> >> нет. Память и CPU не загружены. Пиковая нагрузка ~ 1500 соединений.
>> >> >> nginx принимает запросы, отправляет на бэкенд (Apache) получает
>> >> >> X-Accel-Redirect на /internal/.
>> >> >> Проблема, скорее всего, в моих кривых руках...
>> >>
>> >> >> limit_zone server_ip_limit $binary_remote_addr 10m;
>> >>
>> >> >> limit_conn server_ip_limit 3;
>> >>
>> >> > А когда использовлся только Апач, подобное ограничение было ?
>> >>
>> >> Приветствую, Игорь.
>> >>
>> >> Было. Я выше писал об этом. Отключение limit_zone и limit_conn никак
>> >> не влияет на скорость - те же 99 мбит.
>> >> Может я собрал неправильно?
>>
>> > Нет, сборка на такое не влияет. Апач сам отдаёт какие-нибудь файлы или
>> > только всегда перенаправляет в /internal/ ?
>>
>> Мало, но отдает. Основная задача - перенаправление в /internal/.
>> Может быть проблема в sendfile? Когда работает апач, ответ
>> генерируется с помощью php и sendfile не используется...
>> Насколько я понимаю, nginx получив ответ говорит sendfile и забывает
>> до окончания запроса. Посему проблема не в nginx, а в системе.
>>
>> Исследовав все, нашел единственное странное:
>> # vmstat -z
>> ITEM SIZE LIMIT USED FREE REQUESTS FAILURES
>> 16 Bucket: 152, 0, 42, 58, 80, 0
>> 32 Bucket: 280, 0, 27, 57, 75, 0
>> 64 Bucket: 536, 0, 14, 28, 45, 36
>> 128 Bucket: 1048, 0, 3036, 2817, 7312, 5492731
>>
>> Что сие означает?
> Насколько фатальны эти FAILURES, сказать не могу.
>> При работе nginx
>> # top
>> last pid: 81899; load averages: 0.22, 3.05, 3.07
>> up 0+14:15:03 19:11:18
>> 95 processes: 1 running, 94 sleeping
>> CPU states: 1.3% user, 0.0% nice, 2.1% system, 7.2% interrupt, 89.4% idle
>> Mem: 182M Active, 2959M Inact, 491M Wired, 195M Cache, 209M Buf, 5604K Free
>> Swap: 2048M Total, 216K Used, 2048M Free
>>
>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>> 720 mysql 10 4 0 105M 82712K sbwait 1 36:22 0.00% mysqld
>> 726 root 1 77 0 19860K 2512K select 0 0:02 0.00% sshd
>> 81461 www 1 -8 0 23440K 8672K biord 1 0:01 0.00% nginx
>> 81462 www 1 -8 0 24056K 9292K biord 0 0:01 0.00% nginx
>> 81463 www 1 -8 0 23260K 8488K biord 0 0:01 0.00% nginx
>> 81460 www 1 -8 0 23920K 9156K biord 1 0:01 0.00% nginx
>> 528 bind 1 76 0 7604K 3624K select 1 0:01 0.00% named
>> 466 root 1 76 0 3688K 1064K select 0 0:00 0.00% syslogd
>> 81344 root 1 76 0 60232K 7228K select 0 0:00 0.00% httpd
>> 743 root 1 8 0 3724K 1112K nanslp 1 0:00 0.00% cron
> nginx сидит в biord, а Вы говорите - нет дисковой активности.
> Нужно увеличивать число worker'ов.
Дисковая активность есть, конечно. Просто не упирается проблема в
дисковую подсистему. Используется примерно 30-70%
Worker'ов стоит 5000, сколько поставить?
>> Без nginx
>> # top
>> last pid: 93306; load averages: 2.17, 2.26, 2.29
>> 1290 processes:5 running, 1281 sleeping, 4 lock
>> CPU states: 5.7% user, 0.0% nice, 29.5% system, 15.2% interrupt, 49.5% idle
>> Mem: 1567M Active, 1344M Inact, 627M Wired, 167M Cache, 214M Buf, 5604K Free
>> Swap: 2048M Total, 212K Used, 2048M Free
>>
>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>> 720 mysql 11 4 0 113M 90260K sbwait 1 40:01 0.00% mysqld
>> 83302 root 1 79 0 60412K 6656K select 0 0:10 0.00% httpd
>> 726 root 1 76 0 19860K 2512K select 1 0:03 0.00% sshd
>> 528 bind 1 76 0 7604K 3624K select 0 0:01 0.00% named
>> 91750 www 1 4 0 60884K 7552K sbwait 0 0:01 0.00% httpd
>> 466 root 1 76 0 3688K 1064K select 0 0:00 0.00% syslogd
>> 88682 www 1 4 0 60876K 7692K sbwait 0 0:00 0.00% httpd
>> 91436 www 1 4 0 61180K 7880K sbwait 1 0:00 0.00% httpd
>> 92307 www 1 4 0 61192K 7896K sbwait 0 0:00 0.00% httpd
>> 92566 www 1 4 0 61204K 7912K sbwait 1 0:00 0.00% httpd
>> 83509 www 1 4 0 61024K 6924K sbwait 1 0:00 0.00% httpd
>> 92547 www 1 76 0 60948K 7792K select 1 0:00 0.00% httpd
>> 89759 www 1 4 0 61144K 7852K sbwait 0 0:00 0.00% httpd
>>
>> Исходя из всех данных, повторюсь, тормозит не nginx, а система.
>> Если есть мысли - подскажите куда копать...
> А что показывает
> netstat -m?
# netstat -m
62886/1854/64740 mbufs in use (current/cache/total)
62840/244/63084/262144 mbuf clusters in use (current/cache/total/max)
62840/94 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
141401K/951K/142353K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
135700 requests for I/O initiated by sendfile
16372 calls to protocol drain routines
Вот как выглядит график с nginx и apache.
http://shocka.com/internet-day.png
до 15:30 nginx
до 24:00 apache
до 24:15 nginx
до 18:05 apache
до 18:20 nginx
Меня смущает то, что трафик опускается примерно в 100мбит, как-будто
его что-то шейпит...
С уважением.
More information about the nginx-ru
mailing list