Добрый день!
Есть 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? И каким образом можно диагностировать эту ситуацию?
Есть 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? И каким образом можно диагностировать эту ситуацию?