Re: Поиск узких мест

[Andrei Belov]

> On 9 Oct 2019, at 12:22, Илья Шипицин <chipitsine at gmail.com> wrote:
> 
> на 2018-м nginx.conf был доклад, как профилировать в районе Lua (и не только)
> 
> https://openresty.org/slides/nginx-conf-2018/ <https://openresty.org/slides/nginx-conf-2018/>
+ видео:
https://www.youtube.com/watch?v=NR8U1qYHGqk <https://www.youtube.com/watch?v=NR8U1qYHGqk>


> 
> ср, 9 окт. 2019 г. в 14:13, yanda.a <nginx-forum at forum.nginx.org <mailto:nginx-forum at forum.nginx.org>>:
> Добрый день!
> Есть nginx с модулем lua. Мы используем content_by, в котором происходит
> подключение к tarantool и выполнение одной функции в нем. Библиотека для
> работы с tarantool умеет nginx cosockets, также используется keepalive
> (соединения попадают в пул). Все это работает достаточно быстро, но
> периодически бывают всплески по времени работы кода. Например, подключение к
> tarantool порой достигает 200мс, при том, что соединение находится в пуле.
> Для более точного измерения времени используем posix.clock_gettime() вместо
> ngx.now(), так как он более точный и не кеширует время. Да, есть
> дополнительные два системных вызова, но маловероятно, что они способны
> блокировать nginx на такое длительное время. Само время замеряем до и после
> tarantool:connect().
> 
> Первым делом грешили на сам tarantool, но сняв дамп трафика с обоих стороны
> поняли, что по факту само соединение происходит быстро, попросту сам nginx
> пытается подключиться с "запозданием". Вероятно что-то блокирует его.
> 
> Так как основной причиной блокировок может быть файловый I/O, решили
> воспользоваться bcc-tools для подтверждения этого. В частности,
> воспользовались funcslower. На данный момент пытаемся искать медленное
> выполнение следующих функций:
> /usr/sbin/nginx:ngx_write_file
> /usr/sbin/nginx:ngx_read_file
> /usr/sbin/nginx:ngx_copy_file
> c:open
> c:write
> c:read
> 
> Но, к сожалению, в моменты всплеска времени подключения у нас нет медленной
> работы одной из этих функций.
> 
> Подскажите, какие еще функции могут блокировать event loop? И каким образом
> можно диагностировать эту ситуацию?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20191009/6cc2d4d7/attachment-0001.htm>