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

[Denys Fedoryschenko <denys@xxxxxxxxxxx>]

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

Приведу примеры из своей жизни:
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-режим