ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Проблема при >1500 одновреме нных коннектов.



>Кстати, я правильно понимаю, что это i386/4G ?
да.
>PAE используется или нет ?
Незнакомые слова. если это Physical Address Extensions - ничего на эту тему не делал. фрюха 6.3 как есть. Где можно почитать что делать?

>Почему помогает уменьшение sendfile_max_chunk - не знаю.
уф.. а что должно помочь? Игорь, можно тебе рута дать? Там ничего кроме nginx и горы файлов нету. :) Очень устал глухим телефоном работать.

top -S целиком, надеюсь не сильно поедет:

last pid:  5999;  load averages:  3.58,  3.15,  3.03   up 42+20:14:11  19:28:29
118 processes: 16 running, 83 sleeping, 1 stopped, 18 waiting
CPU states:  6.8% user,  0.0% nice, 22.0% system, 37.1% interrupt, 34.1% idle
Mem: 111M Active, 1439M Inact, 354M Wired, 95M Cache, 199M Buf, 2996K Free
Swap: 512M Total, 2388K Used, 510M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   32 root        1 -68 -187     0K     8K CPU0   0 852.0H 98.34% irq30: em0
   10 root        1 171   52     0K     8K RUN    3 558.6H 49.41% idle: cpu3
   12 root        1 171   52     0K     8K RUN    1 534.6H 45.80% idle: cpu1
   35 root        1 -64 -183     0K     8K CPU1   2 271.5H 38.67% irq16: uhci0
   11 root        1 171   52     0K     8K RUN    2 422.0H 27.93% idle: cpu2
   13 root        1 171   52     0K     8K RUN    0 307.6H 18.60% idle: cpu0
85284 www         1   4     0  8968K   6548K RUN    3  51:18  9.42% nginx
85279 www         1  99    0 43360K   7312K RUN    2  50:17  9.28% nginx
85283 www         1   4     0 43148K  7484K RUN    1  53:37  9.18% nginx
85280 www         1   4     0  9376K   6956K RUN    1  53:20  9.03% nginx
85285 www         1   4     0 36560K  15428K kqread 1  52:06  8.64% nginx
85281 www         1   4     0  9024K   6604K kqread 1  50:52  8.15% nginx
85278 www         1  -8     0 73132K  10296K biord  1  53:25  8.11% nginx
85276 www         1  98    0 42388K   8528K RUN    2  53:49  7.96% nginx
85282 www         1  -4     0 42144K   7108K getblk 3  46:03  7.13% nginx
85277 www         1   4     0 42840K 11704K RUN    1  52:10  6.93% nginx
    3 root        1  -8    0     0K     8K RUN    2  55.6H  4.93% g_up
   14 root        1 -32 -151     0K     8K CPU2   3  52.7H  1.42% swi4: clock s


Вижу в нем сразу три странности: ядра работают с разной в разы нагрузкой
98.34% irq30: em0 - очень не нравится эта строчка, кажется это что-то рядом с тем фактом что даже при свободном канале сервер не может отдать больше 440мегабит. Что это, драйвера?
38.67% irq16: uhci0 - эта хренька что вообще делает в топе? сервер старый  - там USB1.1. Выключить его в биосе?

А.

2009/2/11 Igor Sysoev <is@xxxxxxxxxxxxx>
On Wed, Feb 11, 2009 at 10:12:20AM +0100, ArjLover wrote:

> Что-то меня путают.
>
> 1. Вчера поставил в настройках nginx
> sendfile_max_chunk 64k;
> http://film.arjlover.net/problem2/02p.html
> Бинго! Смог прожить вечерний наплыв без падений, хотя легкая "хандра" nsbuff
> все равно была.
> поможет ди дальнейшее уменьшение, например, до 32к?
>
> 2. nsbuff, как видно, растет прямо пропорционально коннектам, но не скорости
> отдачи? Почему так?

Потому что на каждое соединение выделяется несколько sfbufs, примерно
net.inet.tcp.sendspace / 4096. От скорости они не зависят.

> 3. Если мы патчим ядро для увеличения sendfile больше 64, то почему в моем
> случае мне его приходится уменьшать? или это разные "sendfile"?

Патч увеличивает read ahead.
Почему помогает уменьшение sendfile_max_chunk - не знаю.

А что показывают верхние 20 строк "top -S" ?

Кстати, я правильно понимаю, что это i386/4G ? PAE используется или нет ?

> 4. Кстати. У меня тем же nginx отдаются куча мелких картинок и html с апача
> - это не вредит раздаче больших файлов?

Мешает.

> А.
>
> 2009/2/10 Igor Sysoev <is@xxxxxxxxxxxxx>
>
> >
> > Вариант номер три - использовать sendfile. Но с ним беда, он больше 64К
> > не читает. Для этого был написан патч.


--
Игорь Сысоев
http://sysoev.ru




--
Best regards,
Anton Kuznetsov.      


 




Copyright © Lexa Software, 1996-2009.