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

[ArjLover]

>Кстати, я правильно понимаю, что это 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 at rambler-co.ru>

> 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 at rambler-co.ru>
> >
> > >
> > > Вариант номер три - использовать sendfile. Но с ним беда, он больше 64К
> > > не читает. Для этого был написан патч.
>
>
> --
> Игорь Сысоев
> http://sysoev.ru
>
>


-- 
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090211/303762a3/attachment.html>