https cpu load

[Илья Шипицин]

вс, 7 апр. 2019 г. в 23:22, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote:
>
> > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает
> это.
> > >
> > > и при этом не сообщая ничего о своем (референсном в данном случае)
> > > профиле нагрузке? оригинально
> > >
> >
> > это некое предположение, что "среднее хорошо написанное веб-приложение
> для
> > браузера" работает примерно одинаково.
>
> я не заметил, там говорилось что нгинкс колокейтится с приложением?
> он не статику раздает, не проксей работает?
>
> >
> > >
> > > >
> > > > >
> > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер
> было
> > > как
> > > > > > раз про это.
> > > > >
> > > > > нет никакого смысла смотреть профайлер в данный момент.
> > > > >
> > > >
> > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть
> > > > профайлер. какие еще есть варианты ?
> > >
> > > очевидно он расходуется на https, это бесполезное знание.
> > >
> >
> >
> > неочевидно.
> > например, у нас 70% cpu это компрессия.
> >
> > опять же, https это как минимум два вида нагрузки - ассиметричные
> хендшейки
> > и симметричное шифрование. сколько каждого из них, весьма интересно.
>
> это бесполезное знание, пока мы не узнали что на это расходуется
> больше ожидаемого. если у нас большая частота новых соединений то
> будет пик в ассиметричных хендшейках и что дальше? так и должно быть.
>

информация о том, что пик в хендшейках - полезна.

допустим, у нас не используется   http2 - значит надо его включить
допустим, можно увеличить keepalive_requests
допустим, можно поревьювить кеш SSL сессий (хотя, по приведенному конфигу -
с ним все хорошо)
допустим, можно поменять порядок шифрстютов (у GCM хендшейки дешевле)
допустим, можно перейти на ECDSA (увеличение производительности от x4 на
Xeon до x16 на Celeron)



> и смотреть надо на это для начала, а не профайлинг запускать.
>

без профайлинга непонятно, действительно ли ssl в топе.


>
> да и вообще, поинтересоваться что за процессор и все такое.
>

> > из интересных моментов, каким-то странным образом при сборке портов
> > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной
> > оптимизацией.
>
> это надо было постараться, да.
> даже дважды (т.е. что бы для начала системный не устроил)
>


на freebsd до недавнего времени в base system поставлвлся openssl-1.0.1,
постарались мы ровно один раз, когда "убрали" галочку с ассемблерной
оптимизации


>
> > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику
> > (которая в случае включенной ассемблерной оптимизации умножилась на
> ноль).
> >
> > еще из интересных моментов, был странный опыт с подменой ответа (какой-то
> > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении
> > тимсити) привела к всплеску cpu. увидели это тоже по gperftools
>
> это проявлялось тоьлко на https?
>


это пример того, как при помощи профайлера найти узкое место. проявлялось
это, понятно, в единственной ситуации,
вышел новый релиз teamcity, и несколько десятков агентов пошли скачивать
инсталяторы. и это пошло сквозь регурярку


>
> > сколько раз использовал gperftools, еще не было повода пожалеть.
>
> ни разу не использовал и не жалею.
> предпочитаю pcstat, но тогда когда имеет смысл.
>

вариантов профилирования миллион.
неплохой обзор, например, тут
http://openresty.org/slides/nginx-conf-2018/#1



>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190408/3b518f00/attachment.html>