<br><div class="gmail_quote">23 августа 2012 г., 13:05 пользователь ShivaS <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> написал:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Илья, огромное спасибо за то, что так подробно ответили и проявили интерес!<br>
Запуск намечаем на сегодня ;-)<br>
Ну а теперь подробнее, и в самом конце приведу свой полный конфиг<br>
<br>
Илья Шипицин Wrote:<br>
-------------------------------------------------------<br>
<div><div class="h5">> 22 августа 2012 г., 2:04 пользователь ShivaS <<a href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>><br>
> написал:<br>
><br>
> > Добрый вечер,<br>
> ><br>
> > Возникла интересная возможность применения nginx в очень нагруженном<br>
> > проекте.<br>
> ><br>
> > Мы активно пользуемся Амазонон (ЕС2) и соответственно лоад<br>
> балансером ELB,<br>
> > который на данном этапе делает оффлоад на SSL и общается с пуш<br>
> серверами.<br>
> > Сервис достаточно большой, и на определенном этапе мы поняли, что<br>
> ELB<br>
> > перестал справляться с нагрузкой, да и его вечное отсоединение<br>
> соединений с<br>
> > пуш серверами уже надоело.<br>
> ><br>
> > Провели тестирование с nginx на одном из серверов в амазоне, которое<br>
> > показало неплохие результаты, но все уперлось в память.<br>
> > Значит надо много серверов с большим кол-вом памяти. На удивление,<br>
> несмотря<br>
> > на SSL, процессоры вообще не напрягались и LA постоянно оставался <<br>
> 1, что<br>
> > дает возможность брать сервера с большим кол-вом памяти, малым<br>
> кол-во<br>
> > процессоров и экономить.<br>
> ><br>
><br>
> LA = Load Average, это показатель, который соответствует количеству<br>
> процессов, ожидающих ввода-вывода. При высокой дисковой нагрузке,<br>
> соотвественно упирается в потолок. В случае терминации SSL он и не<br>
> должен расти больше единицы.<br>
><br>
<br>
</div></div>Ну насколько я понимаю LA не обозначает именно дисковые проблемы, а любую<br>
проблему (и не обязательно проблему) с ожиданием процессоров. При 8 воркерах<br>
я и ожидал около 8 в какой-то момент, так как боялся тормозов установки SSL<br>
сессии и, что SSL поест процессоры без разбору. Но видимо все обошлось и,<br>
как Вы написали, логично получил <1. Видимо я не до конца осознал всю<br>
глубину глубин ;-)<br>
<div class="im"><br>
<br>
<br>
> ><br>
> > Система: CentOS 6; nginx 1.2.3<br>
> ><br>
> > конфиг подправлял в паре мест.<br>
> > Вот тут:<br>
> ><br>
> > listen       *:443 default backlog=4096 so_keepalive=30m::10;<br>
> ><br>
> > И еще немного тут:<br>
> ><br>
> > worker_processes  8;<br>
> > worker_rlimit_nofile 204800;<br>
> ><br>
> ><br>
> > events  {<br>
> >         worker_connections  20000;<br>
> >         use epoll;<br>
> >         multi_accept on;<br>
> >   accept_mutex on;<br>
> >         }<br>
> ><br>
><br>
><br>
> серьезный момент - сколько запросов делает один клиент ? если<br>
> несколько (в<br>
> нашей ситуации в среднем 5), то очень серьезный выигрыш получается за<br>
> счет<br>
> keepalive до клиента (у вас он не включен).<br>
><br>
> в SSL очень дорогой хендшейк, он идет на несимметричной криптографии,<br>
> keepalive позволяет уменьшить количество дорогих хендшейков. реально,<br>
> CPU<br>
> падает в разы (если один клиент делает несколько последовательных<br>
> запросов<br>
> и они попадают в одну keepalive-сессию)<br>
><br>
><br>
<br>
</div>Запросов может быть очень много. Есть клиенты которые подсоединяются и в<br>
силу своих крутых интернетов остаются висеть "на связи", а есть такие,<br>
которые постоянно отваливаются и передподсоединяются. С ними вот и много<br>
траблов в основном. Речь о мобильниках, точнее смартфонах. Соединение идет<br>
одно. Это не бразуеры с декстопов, которые любят пооткрывать много чего с<br>
самого начала.<br>
Т.е. получается клиент либо подсоединился и висит, ожидая пуша, либо<br>
отвалился и пробует переподсоединиться, и тогда возможно упадет снова на тот<br>
же сервер, где ему ssl_session_cache и поможет осуществить задуманное в<br>
краткие сроки ;-)<br><br>
> ><br>
> > Стоит ли ставить много воркеров и малое кол-во коннекшенов на каждый<br>
> или<br>
> > достаточно один и сразу выставить максимальное кол-во подсоединений?<br>
> Диски<br>
> > не задействованы совсем.<br>
> ><br>
><br>
> один воркер может задействовать одно ядро. если воркеров меньше, чем<br>
> ядер,<br>
> то сервер будет недонагружен.<br>
><br>
> с другой стороны, если у вас интенсивно используются механизмы,<br>
> требующие<br>
> согласования воркеров между собой  (например limit_req), то может быть<br>
> оверхед на согласование.<br>
><br>
> трассируйте, смотрите :-)<br>
><br>
><br>
<br>
</blockquote><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Нет, ничего такого не используется. Просто SSL оффлоадер с пуш серверами в<br>

бекенде.<br>
Я 8 так и оставил, просто думал что может памяти чуть отгрузить, раз<br>
процессоры недогружены, а каждый воркер берет по сотке МБ.<br>
Но наверно не стоит.<br>
<div class="im"><br>
><br>
> > Приведенные выше настройки использовались на сервере с 7ГБ памяти.<br>
> > каждый воркер берет память, а при 60кб на клиент, даже несколько<br>
> сотен<br>
> ><br>
><br>
> версия nginx какая ? недавно пробегал патч (включенный в последние<br>
> версии),<br>
> отключающий компрессию на уровне SSL, заметно снижающий потребление<br>
> памяти.<br>
><br>
><br>
<br>
</div>Я изначально написал, что 1.2.3, но хитро спрятал в конце предложения ;-)<br>
Т.е. взял самую последнюю стабильную. Да, я читал про отмену сжатия и<br>
очистку памяти от старых подсоединений. Или что-то около того ...<br>
<div class="im"><br>
> > мегабайт при большом кол-ве серверов может дать некоторый выигрыш.<br>
> ><br>
> > Использую ssl ciphers AES256-SHA, для относительной надежности и<br>
> скорости.<br>
> ><br>
><br>
> современные процессоры умеют AES-NI инструкции, в openssl они есть<br>
> начиная<br>
> с 1.0.1 (или чуть раньше ?). мы такое тестили - отвал башки, в<br>
> продакшен<br>
> скоро будем запускать. на амазоне - не знаю, там же Xen ? посмотрите<br>
> на<br>
> /proc/cpuinfo, светится там AES ?<br>
><br>
><br>
<br>
</div>Вроде как не светится:<br>
flags           : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2<br>
ss ht syscall nx lm rep_good aperfmperf unfair_spinlock pni ssse3 cx16<br>
sse4_1 sse4_2 popcnt hypervisor lahf_lm dts<br>
<br>
На самом деле я взял AES256-SHA еще и потому, что он используется на самом<br>
балансере амазона (ELB), т.е. хотел сделать идентичное с нгинкс для более<br>
четкого сравнения.<br>
<div class="im"><br>
> ><br>
> > стоит ли ставить OpenSSL 1.0.1? ECDHE не пользуем, да и тормознутый<br>
> он<br>
> > (судя<br>
> > по бенчмаркам, которые мы гоняли) и в скорости обработки<br>
> подсоединений и в<br>
> > объеме потребляемой памяти. Кроме этого, никаких преимуществ особо<br>
> не нашел<br>
> > в 1.0.1<br>
> ><br>
><br>
> в 1.0.1 есть аппаратное ускорение AES.<br>
><br>
> ECDHE - не более тормознутый, он быстрее за счет того, что<br>
> эллиптическая<br>
> криптография обеспечивает сопоставимую сложность при меньших ключах.<br>
> вы<br>
> случайно не такого же размера ключи выбирали ?<br>
<br>
</div>Что-то вот тут я не понял. Сертификат 2048 bit, это Вы имели в виду?<br>
Остальное я ничего не выбирал...ну или не совсем понимаю вопроса.<br></blockquote><div> </div><div>навскидку, на эллиптических кривых длину ключа можно делить на три и будет такая же криптографическая сложность, как для традиционной криптографии. если и там и там делать по 2048, то, конечно, ECDHE втупит на тестах :-)</div>
<div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div class="im"><br>
><br>
> у ECDHE минус в том, что он пока не очень поддерживается на стороне<br>
> клиента. но не в производительности.<br>
><br>
><br>
<br>
</div>Я еще читал про патч от Гугла который это дело разгоняет нехило, ЕСС, но<br>
вроде там какие-то траблы с лицензией, только в определенных страннах<br>
использовать и т.д..<br>
Я в принципе пока и не рискую этим пользоваться, потестировал, посмотрел,<br>
память съелась ну и решил сделать идентично с ELB<br>
Основная проблема в этих вечно отваливающихся клиентах и ELB таймаутах.<br>
Таймауты то решиться должны вроде, а вот с отваливанием клиентов посмотрим,<br>
когда будет продакшен. iDevices и Андроиды работают без этого сервиса,<br>
напрямую TCP. А вот для всех остальных терминация сервиса идет по https,<br>
возможно не везде я что-то правильно выбрал и не все девайсы индо-китая<br>
могут поддержать то, что я им навязываю. Ну и BB и Win7 phone тоже сюда,<br>
хотя они четко работают и не отваливаются.<br>
<div class="im"><br>
><br>
> > Может, там что-то и подкручено, но меня интересует в основном<br>
> потребление<br>
> > памяти, а разницы с 1.0 в тестах не заметил<br>
> ><br>
> > Кеш выставил, но шансы что клиент переподсоединиться на тот же<br>
> сервер -<br>
> > минимальны, но сотню мегов не жалко ;-)<br>
> ><br>
><br>
> ssl_session_cache  ?<br>
> в приведенном конфиге ее нет.<br>
> покажите полный конфиг ?<br>
><br>
<br>
</div>Да, укажу его в самом конце.<br>
<div class="im"><br>
> ><br>
> > ну и sysctl соответственно тоже.<br>
> ><br>
> > Сейчас вот подумываем очень серьезно о полном переходе на nginx в<br>
> качестве<br>
> > основного оффлоадера.<br>
> ><br>
><br>
> какая у вас нагрузка ?<br>
> мы держим 100-200к одновременных ssl-запросов на обычных серверах (и<br>
> ни в<br>
> какой потолок не упираемся).<br>
><br>
<br>
</div>Надо около 600к-1000к постоянных коннекшенов держать и с клиентом и с пуш<br>
серверами<br></blockquote><div> </div><div>миллион ? неплохо.</div><div> </div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">

И это будет только расти. Ну и непонятное кол-во отваливающихся мобилок, с<br>
которыми потом уже будем разбираться.<br>
Возможно, что применим Гео ДНС для облегчения инициализации их SSL сессии и<br>
лейтенси.<br>
Зараз даже тяжело сказать сколько будет подсоединений. Их очень много и<br>
видимо придется немного жертвовать мобилками и тьюнить беклоги и т.д.<br>
изначально. Но если Вы думаете, что большой беклог изначально - безопасно,<br>
то сразу и выставлю.<br>
<div class="im"><br>
><br>
> > Хотим на днях запустить полноценный продакшен тест (а может и<br>
> финальный<br>
> > переход на nginx)<br>
> ><br>
> > Что еще можно подкрутить для уменьшения потребления памяти (если<br>
> возможно<br>
> > вообще)?<br>
> ><br>
><br>
> GeoIP память тратит :-)<br>
<br>
</div>геоайпи нема, только оффлоад и пуш на бекенде.<br>
<br>
> покажите nginx -V<br>
<br>
nginx version: nginx/1.2.3<br>
TLS SNI support enabled<br>
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx<br>
--with-http_ssl_module --with-http_realip_module --without-http_gzip_module<br></blockquote><div> </div><div>эмм, а почему отключен gzip ?</div><div> </div><div>для мобильноых абонентов, наверное, актуальна компрессия, там же каналы могут быть очень плохого качества. мы в тестах видели 25 мегабайт в секунду на одном ядре для дефолтного 6-го уровня сжатия. сервер с 24 ядрами может на лету жать 5 гигабит в секунду.</div>
<div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
--without-http_fastcgi_module --without-http_empty_gif_module<br>
--http-log-path=/var/log/nginx --with-http_stub_status_module<br>
--without-http_ssi_module --without-http_geo_module<br>
--without-http_split_clients_module --without-http_uwsgi_module<br>
--without-http_scgi_module --without-http_memcached_module<br>
--without-http_charset_module --without-http_auth_basic_module<br>
--without-http_autoindex_module --without-http_referer_module<br>
--without-http_limit_conn_module --without-http_limit_req_module<br>
--without-http-cache --without-mail_pop3_module --without-mail_imap_module<br>
--without-mail_smtp_module --without-pcre --without-http_rewrite_module<br>
<div class="im"><br>
><br>
><br>
> > Может быть еще на что-то надо обратить внимание, без чего хорошего<br>
> > перформанс не достигнуть?<br>
> ><br>
> > Понимаю, что чудес наверно ждать не стоит, но вдруг кто сталкивался<br>
> с<br>
> > чем-то<br>
> > похожим и не спал ночами ;-)<br>
> ><br>
> > И еще вопрос многоуважаемым разработчикам:<br>
> > Когда планируется (и планируется ли вообще) поддержка CyaSSL?<br>
> > Промелькнуло пару постов, что вроде уже тесты идут, и по слухам<br>
> потребление<br>
> > памяти должно сильно упасть.<br>
> > Я в траке искал, но может не там...ничего не нашел<br>
> ><br>
> > Спасибо!<br>
> ><br>
> > Posted at Nginx Forum:<br>
> > <a href="http://forum.nginx.org/read.php?21,229967,229967#msg-229967" target="_blank">http://forum.nginx.org/read.php?21,229967,229967#msg-229967</a><br>
> ><br>
> > _______________________________________________<br>
> > nginx-ru mailing list<br>
> > <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> > <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>
<br>
</div>Привожу конфиг под сервер с 64ГБ памяти.<br>
с keepalive возможно перемудрил. Клиент висит и раз в 6 минут получает<br></blockquote><div> </div><div>keepalive я имел в виду на уровне http, не на tcp. у вас он включен, в предыдущем конфиге это было непонятно.</div><div>
 </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
нолик, чтобы не отвалился, либо в любой момент получает пуш с данными от<br>
байтов до сот килобайт<br>
<br>
nginx.conf:<br>
<br>
worker_processes  8;<br>
worker_rlimit_nofile 409600;<br>
worker_priority -5;<br>
<div class="im"><br>
events  {<br>
        worker_connections  50000;<br>
        use epoll;<br>
        multi_accept on;<br>
  accept_mutex on;<br>
        }<br>
<br>
</div>#GLOBAL SETTINGS<br>
http {<br>
<br>
<br>
log_format main      '$remote_addr - $host - $hostname - $http_name -<br>
$document_uri - $request_uri - $server_protocol - $server_name - $uri -<br>
$remote_user [$time_local] '<br>
                         '"$request" $status $bytes_sent '<br>
                         '"$http_referer" "$http_user_agent" ' ;<br>
<br>
<br>
    server_tokens       off;<br>
<br>
    error_log /usr/local/nginx/logs/error_log debug;<br>
    access_log off;<br>
    #access_log /var/log/nginx/access_log main;<br>
<br>
    default_type  application/octet-stream;<br>
<br>
    client_header_timeout  10m;<br>
    client_body_timeout    10m;<br>
    send_timeout           10m;<br>
<br>
    client_header_buffer_size    1k;<br>
    large_client_header_buffers  4 4k;<br>
<br>
    output_buffers   1 32k;<br>
    postpone_output  1460;<br>
<br>
    sendfile         on;<br>
    tcp_nopush       on;<br>
    tcp_nodelay      on;<br>
<br>
keepalive_timeout     600;<br>
<br>
keepalive_requests 1000000;<br>
<br>
<br>
upstream push {<br>
ip_hash;<br>
<br>
keepalive 60000;<br>
<br>
server 1.1.1.1;<br>
<<ну тут список из многих бекенд пуш серверов>><br>
<br>
<br>
}<br>
<br>
include       mime.types;<br>
include       site.conf;<br>
}<br>
<br>
В теперь конфиг сайта самого<br>
<br>
<br>
################<br>
# HTTPS server #<br>
################<br>
<br>
    server {<br>
<div class="im">        listen       *:443 default backlog=4096 so_keepalive=30m::10;<br>
</div>        server_name  имя;<br>
<br>
        access_log   off;<br>
        #access_log /var/log/nginx/access_ssl_log main;<br>
        error_log    /var/log/nginx/error_ssl_log debug;<br>
<br>
        ssl                  on;<br>
        ssl_certificate<br>
/usr/local/nginx/conf/ssl/conf/ssl/cert.com.pem;<br>
        ssl_certificate_key<br>
/usr/local/nginx/conf/ssl/conf/ssl/cert.com.key;<br>
<br>
        ssl_session_cache    shared:SSL:100m;<br>
<br>
        ssl_session_timeout  10m;<br>
<br>
       ssl_protocols TLSv1;<br>
       ssl_prefer_server_ciphers   on;<br>
       ssl_ciphers AES256-SHA:HIGH:!aNULL:!MD5;<br>
<br>
<br>
<br>
        client_max_body_size 0M;<br>
        client_body_buffer_size    128k;<br>
        client_body_temp_path      /var/tmp;<br>
<br>
        proxy_connect_timeout      75;<br>
        proxy_send_timeout         600;<br>
        send_timeout               600;<br>
        proxy_read_timeout         600;<br>
<br>
        proxy_buffer_size          4k;<br>
        proxy_buffers              4 32k;<br>
        proxy_busy_buffers_size    64k;<br>
        proxy_temp_file_write_size 64k;<br>
<br>
        proxy_temp_path            /tmp;<br>
<br>
  location / {<br>
      proxy_pass <a href="http://push" target="_blank">http://push</a>;<br>
      proxy_http_version 1.1;<br>
      proxy_set_header Connection "";<br>
      proxy_buffering off;<br>
    }<br>
<br>
   }<br>
<br>
<br>
И добавки в sysctl.conf<br>
<br>
net.core.somaxconn = 3240000<br>
net.core.wmem_max = 16777216<br>
net.core.rmem_max = 16777216<br>
net.core.rmem_default = 8388608<br>
net.core.netdev_max_backlog = 5000<br>
net.ipv4.tcp_max_orphans = 300000<br>
net.ipv4.tcp_max_tw_buckets = 1440000<br>
net.ipv4.tcp_keepalive_intvl = 600<br>
net.ipv4.tcp_syncookies = 0<br>
net.ipv4.tcp_max_syn_backlog = 3240000<br>
net.ipv4.ip_local_port_range = 2000   65000<br>
net.ipv4.tcp_wmem = 4096      65536   16777216<br>
net.ipv4.tcp_rmem = 4096      87380   16777216<br>
<br>
<br>
вот что-то около того<br>
<br>
Спасибо!<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?21,229967,230015#msg-230015" target="_blank">http://forum.nginx.org/read.php?21,229967,230015#msg-230015</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br>