соотношение балансировщиков/веб-серверов (оффтоп, но...)
Really Big Bug
bigbug at mafia.lv
Fri Oct 23 12:20:15 MSD 2009
nofile это она
big bond wrote:
> сам flood_connect ничего не показывает (если не ограничить его опцией
> -n число_соединений), я запускаю netstat в момент атаки:
> while true;do netstat -tn | grep EST | grep -c 443;sleep 5;done
> и смотрю, что набегает, на данный момент интересуют именно ESTABLISHED
> соединения, до rate-тестов еще не добрались.
>
> Я нашел-таки узкое место. Все-таки это был ulimit -n, он почему-то
> периодически возвращается к дефолту в 1024, хотя машина не
> перезагружалась уже несколько месяцев (видимо при логине
> сбрасывается). Может кто подскажет, как это в линуксе победить? ulimit
> на пользователя вроде как выставляется, для некоторых программ я
> помещал команду типа ulimit -n 4096 в стартовый init-скрипт, но как
> это сделать для рута? В /etc/security/limits.conf я не вижу подобной
> опции:
> #<item> can be one of the following:
> # - core - limits the core file size (KB)
> # - data - max data size (KB)
> # - fsize - maximum filesize (KB)
> # - memlock - max locked-in-memory address space (KB)
> # - nofile - max number of open files
> # - rss - max resident set size (KB)
> # - stack - max stack size (KB)
> # - cpu - max CPU time (MIN)
> # - nproc - max number of processes
> # - as - address space limit
> # - maxlogins - max number of logins for this user
> # - maxsyslogins - max number of logins on the system
> # - priority - the priority to run user process with
> # - locks - max number of file locks the user can hold
> # - sigpending - max number of pending signals
> # - msgqueue - max memory used by POSIX message queues (bytes)
> # - nice - max nice priority allowed to raise to
> # - rtprio - max realtime priority
>
> Какая из них отвечает за ulimit -n ? Наиболее похожа -locks, но не вполне.
>
> 23 октября 2009 г. 10:58 пользователь Igor Sysoev <is at rambler-co.ru> написал:
>> On Fri, Oct 23, 2009 at 10:13:32AM +0400, big bond wrote:
>>
>>> Так в том-то все и дело, что оба сервера (старый и новый) выступают
>>> ssl-клиентами! SSL-сервером выступает железка с хардварным
>>> криптопроцессором. На обоих ssl-клиентах запускается одна и та же
>>> команда и старенькая железка с BSD по относительной производительности
>>> быстрее на порядок! Cipher у обоих ssl-клиентов в момент теста
>>> одинаковый - AES256-SHA. На linux-ssl-клиенте есть прямая зависимость
>>> количества сгенерированных клиентских ssl-сессий от количества форков
>>> программы-флудера: один форк - ~1024 соединения, 10 форков - 10232
>>> соединения. Возникает ощущение какого-то ограничения.
>> А какие цифры на старой машине у одного форка и у 10 ?
>> И что вообще показывает flood_connect - число установленных соединений
>> в секунду или что ?
>>
>>> 23 октября 2009 г. 9:50 пользователь Igor Sysoev <is at rambler-co.ru> написал:
>>>> On Thu, Oct 22, 2009 at 11:37:24PM +0400, big bond wrote:
>>>>
>>>>> В описанном мной тесте nginx не участвовал. Было 2 разных
>>>>> *нагружающих*сервера - старое железо с FreeBSD и новый сервер с
>>>>> Linux. Нагружали
>>>>> балансировщик (мощная железка, полностью аппаратное решение на
>>>>> FPGA-вентилях). Удивило то, что очень старый сервер с BSD смог сгенерировать
>>>>> всего лишь вдвое меньше конкурентных SSL-сессий, чем весьма неслабый сервер
>>>>> под Linux (7500 у 1xP3 700 против 16000 у 2xXEON 2500).
>>>> SSL-handshake со стороны клиента быстрее раз в 10-20, чем на серверной
>>>> стороне:
>>>>
>>>> Pentium M 1.7GHz:
>>>> openssl speed rsa1024
>>>> ...
>>>> Doing 1024 bit private rsa's for 10s: 2401 1024 bit private RSA's in 9.97s
>>>> Doing 1024 bit public rsa's for 10s: 49828 1024 bit public RSA's in 9.92s
>>>>
>>>> AMD Athlon64 3500+ 2.2GHz:
>>>> openssl speed rsa1024
>>>> ...
>>>> Doing 1024 bit private rsa's for 10s: 11318 1024 bit private RSA's in 9.99s
>>>> Doing 1024 bit public rsa's for 10s: 237965 1024 bit public RSA's in 9.96s
>>>>
>>>> Сервер делает операцию private RSA, а клиент - public. Кстати, из этого
>>>> теста видно, что для SSL лучше использовать 64-битные платформы: RSA
>>>> быстрее в 4-5 раз.
>>>>
>>>>> 22 октября 2009 г. 23:12 пользователь Gena Makhomed <gmm at csdoc.com> написал:
>>>>>
>>>>>> big bond wrote:
>>>>>>
>>>>>> Кстати, сегодня пробовали нагрузить конкурентными 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-режим
>>>>>>>
>>>>>> 1. если включить ssl_session_cache -
>>>>>> SSL будет работать намного быстрее.
>>>>>> например:
>>>>>>
>>>>>> http {
>>>>>> ssl_session_cache shared:SSL:20M;
>>>>>> ssl_session_timeout 120m;
>>>>>> ...
>>>>>>
>>>>>> почему ssl_session_cache по умолчанию выключен -
>>>>>> не знаю, наверное чтобы зря не расходовать память,
>>>>>> если SSL не используется или используется очень мало.
>>>>>>
>>>>>> 2. если при сборке nginx указывать ключи
>>>>>> --with-md5-asm --with-zlib-asm=pentiumpro
>>>>>> думаю что он тогда будет работать быстрее,
>>>>>> чем если без них. по крайней мере, на i386.
>>>>>>
>>>>>> см. также другие ключи оптимизации в ./configure --help
>>>>>> все не используемые модули наверное лучше будет выключить.
>>>>>>
>>>>>> 3. если при работающем nginx изменялись SSL сертификаты
>>>>>> в конфиге - тогда надо делать service nginx force-reload
>>>>>> потому что после service nginx reload - nginx продолжает
>>>>>> использовать старые и молча игнорирует новые сертификаты.
>>>>>>
>>>>>> я не считаю, что это ошибка, - это больше особенность поведения
>>>>>> о которой следует помнить, если приходится их на лету обновлять.
>>>>>>
>>>>>> По хорошему надо CARP, но в принципе достаточно просто чтоб в одном
>>>>>>> vlan-е были, вручную IP слегшего сервера можно будет перекинуть.
>>>>>>>
>>>>>> в англоязычном списке рассылки на вопрос про балансировщики
>>>>>> советовали использовать http://www.backhand.org/wackamole/
>>>>>>
>>>>>> и читать книжку Scalable Internet Architectures
>>>>>>
>>>>>> http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
>>>>
>>>> --
>>>> Игорь Сысоев
>>>> http://sysoev.ru
>>>>
>>>>
>> --
>> Игорь Сысоев
>> http://sysoev.ru
>>
>>
More information about the nginx-ru
mailing list