Re: соотношение баланс ировщиков/веб-серверов (оффтоп, но...)

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Fri, Oct 23, 2009 at 03:53:36AM +0300, Denys Fedoryschenko wrote:

> >
> > Оптимизация даёт пару процентов, не больше.
> Абсолютно не согласен.

Под оптимизацией я имел ввиду -O2 и выше и сборку под конкретный процессор.

> Приведу примеры из своей жизни:
> 1)Настройка шедулера. CFQ который частенько используют, по умолчанию работает 
> с NCQ/TCQ просто отвратительно. Впрочем anticipatory тоже, и неудивительно, у 
> TCQ своя точка зрения на оптимизацию дисковой системы, с более глубоким 
> знанием физики диска, на котором стоит контроллер. По iostat это видно 
> увеличением трансфера на 2-3 Mbyte/s (было около 3Mbyte/s, стало 5 Mbyte/s). 
> Трансфер небольшой - т.к. масса запросов на очень мелкие файлы. С помощью 
> latencytop,профайлера,httping можно подогнать значения к приемлимому 
> компромиссу.
> 
> iostat -d -x 1
> Linux 2.6.31.4-build-0048y (PROXY)         10/23/09        _i686_  (4 CPU)
> ...
> Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz 
> avgqu-sz   await  svctm  %util
> sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00    
>  
> 0.00    0.00   0.00   0.00
> sdb               0.00    52.00   99.00   11.00   856.00   504.00    12.36    
>  
> 0.94    8.53   1.05  11.60
> sdc               0.00    15.00    0.00    1.00     0.00   128.00   128.00    
>  
> 0.01    6.00   6.00   0.60
> sdd               0.00    23.00   66.00    1.00   544.00   192.00    10.99    
>  
> 0.76   11.34   0.85   5.70
> sde               0.00     0.00    3.00    0.00    24.00     0.00     8.00    
>  
> 0.01    4.67   4.67   1.40
> dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00    
>  
> 0.00    0.00   0.00   0.00
> 
> 
> 
> 
> 2)Настройки файловой системы. noatime, nodiratime, отключаем барьеры (но 
> рискуем data integrity), journal_async_commit, journal в writeback. 
> Естественно сама файловая система тоже имеет значение.
> 3)SMP affinity. Cache coherency имеет огромное значение. В старых версиях 
> дистрибутивов любили разбрасывать сетевые прерывания ровным слоем по ядрам, 
> что приводило к колоссальным cache miss. В моем случае программного 
> маршрутизатора это привело почти к двукратному росту производительности 
> (правильно установленный affinity).
> 4)somaxconn, про это вообще молчу. На squid+linux на дефолтовом значении 
> начинало затыкаться уже на 7-10k req/sec.
> 5)Если по умолчанию запущен conntrack, это убийца производительности сетевого 
> стека. Собственно лучше избавиться от iptables вообще, и резать через iproute 
> filter
> 6)Само собой размеры сетевых буферов в sysctl
> 7)Шедулер
> 
> И самое главное - профайлинг, профайлинг и еще раз профайлинг.
> Вот например на этом тазике очень медленный таймер (AMD черт его подери)
>              samples    pcnt         RIP          kernel function
>   ______     _______   _____   ________________   _______________
> 
>             13996.00 - 41.5% - 00000000c028c494 : acpi_pm_read
>               834.00 -  2.5% - 00000000c029e738 : __napi_schedule
>               825.00 -  2.4% - 00000000c01475c8 : getnstimeofday
>               781.00 -  2.3% - 00000000c0211e34 : copy_to_user
> 
> Ну и конечно можно посмотреть узкие места в самом ПО. У меня почти все 
> сервера 
> собраны без debug symbols, потому примеры показать не могу.
> 
> Хотя вот, нашел, результат злоупотребления мной high resolution таймерами в 
> userspace.
> SUPERPROXY ~ # perf report|more
> # Samples: 53605
> #
> # Overhead         Command              Shared Object  Symbol
> # ........  ..............  .........................  ......
> #
>     14.02%            init  [kernel]                   [k] acpi_pm_read
>      7.76%          globax  [kernel]                   [k] acpi_pm_read
>                 |
>                 |--99.73%-- getnstimeofday
>                 |          ktime_get_ts
>                 |          |
>                 |          |--63.98%-- ktime_get
>                 |          |          |
>                 |          |          |--64.20%-- sys_timer_settime
>                 |          |          |          syscall_call
>                 |          |          |          timer_settime
>                 |          |          |          mytimer_set
> 
> Причем это проявляется только на AMD, и некоторых интелях, где наблюдаются 
> проблемы с таймерами.
> Поэтому смотреть надо, в чем проблема на том сервере и искать где узкое место.
> 
> >
> > > On Thursday 22 October 2009 19:20:25 big bond wrote:
> > > > CARP только в BSD, а эти замечательные системы у нас в компании не
> > > > принято использовать. Скорее всего балансер(ы) будут железные, но пока
> > > > тестируем.
> > > >
> > > > Кстати, сегодня пробовали нагрузить конкурентными SSL-сессиями один из
> > > > тестирумых балансировщиков, использовали программу flood_connect. Я
> > > > скомпилировал её на линуксовой машине (2хXEON E5420, 2.50GHz, 4GB RAM,
> > > > SUSE ENT 10.2), выжать смог максимум 16000 соединений, все 4 ядра были
> > > > загружены на 100%.
> > > > Коллега скомпилировал на старенькой железке (P3 700MHz, 512MB RAM,
> > > > FreeBSD 7.2), выжал 7500 соединений и процессор был загружен не более
> > > > 80%!!!! Сам балансировщик при этом тоже неплохо был загружен.
> > > > Как такое возможно? Старая железка отстала всего в два раза от
> > > > современного неслабого сервера!
> > > > Запускали так: *flood_connect -S -f 10 -p 443 адрес_балансировщика*
> > > > -f - количество форков
> > > > -S - SSL-режим
> 
> 

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