nginx_worker 死循环退出问题

xbsura

版本: 1.9.7.2

场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置

期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出

问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况

试图解决: repeat 已经做了如下处理:

repeat

pcall(cron.try_load)

until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息

有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

xbsura

@agentzh

在 2016年3月11日星期五 UTC+8上午10:19:14，肖贝贝写道：

版本: 1.9.7.2
场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置
期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出
问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况
试图解决: repeat 已经做了如下处理:

repeat
pcall(cron.try_load)
until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息
有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

yunthanatos

在 2016年3月11日星期五 UTC+8上午10:19:14，肖贝贝写道：

版本: 1.9.7.2
场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置
期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出
问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况
试图解决: repeat 已经做了如下处理:

repeat
pcall(cron.try_load)
until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息
有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

你好！

真是太巧了，最近我也在尝试这种玩法，但我并非让这些阻塞住的worker去做配置同步，而是做I/O进程。

先说下我的看法:

如果你只是做配置同步，拉出来若干worker来只干这件事情，是否几分杀鸡用牛刀之意呢？worker级别的定时器timer不是很好么？(要实现周期循环单例，加上timestamp即可)

若是必须采取这种方式，就要满足设计容错性的要求，就必须加上worker被杀然后重生时的抢锁逻辑:

现在的DICT不大适合做这件事(它的超时释放到这儿就不大适合了)，建议使用内核为进程间同步所提供的锁(最方便的如文件锁)，进程被杀后，内核便会为它做锁释放，这样便可完美解决新worker重生时的身份判定问题。

yunthanatos

至于这种完全阻塞住某一部分workers的玩法，在nginx整体上逻辑是否严格正确，让我们等待春哥的帮助 :)

在 2016年3月11日星期五 UTC+8上午10:19:14，肖贝贝写道：

版本: 1.9.7.2
场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置
期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出
问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况
试图解决: repeat 已经做了如下处理:

repeat
pcall(cron.try_load)
until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息
有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

xbsura

在 2016年3月13日星期日 UTC+8上午9:40:13，Yun Thanatos写道：

在 2016年3月11日星期五 UTC+8上午10:19:14，肖贝贝写道：
版本: 1.9.7.2
场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置
期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出
问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况
试图解决: repeat 已经做了如下处理:

repeat
pcall(cron.try_load)
until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息
有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

你好！

真是太巧了，最近我也在尝试这种玩法，但我并非让这些阻塞住的worker去做配置同步，而是做I/O进程。

先说下我的看法:

还好, 因为 worker 在 sleep 期间和同步期间是不占用 cpu 的, 单起一个 worker 跑也没什么问题

定时器有坑, 设置定时器之后, 在同步期间, 会有部分请求耗时过长, ab 压测下, 2核心, 加了定时器 qps 降低1000, 最长延时由16ms 到了2000ms+, 可能定时器的部分逻辑到了请求中执行

如果你只是做配置同步，拉出来若干worker来只干这件事情，是否几分杀鸡用牛刀之意呢？worker级别的定时器timer不是很好么？(要实现周期循环单例，加上timestamp即可)

worker 被杀死不是问题, 被杀死以后, nginx 会重启 worker, 由于有锁的逻辑, 会重新进入配置同步, 问题在于, worker 没有被杀死, 二是退出了死循环逻辑

若是必须采取这种方式，就要满足设计容错性的要求，就必须加上worker被杀然后重生时的抢锁逻辑:

同上, worker 重生不是问题

现在的DICT不大适合做这件事(它的超时释放到这儿就不大适合了)，建议使用内核为进程间同步所提供的锁(最方便的如文件锁)，进程被杀后，内核便会为它做锁释放，这样便可完美解决新worker重生时的身份判定问题。

yuansheng

> 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出

这里的死循环，应该要判断 ngx.worker.exiting 状态，是否可以解决问题呢？

wiki 地址：

https://github.com/iresty/nginx-lua-module-zh-wiki#ngxworkerexiting

2016-03-14 10:22 GMT+08:00 肖贝贝 <xb...@gmail.com>:

在 2016年3月13日星期日 UTC+8上午9:40:13，Yun Thanatos写道：

在 2016年3月11日星期五 UTC+8上午10:19:14，肖贝贝写道：
版本: 1.9.7.2
场景: nginx 启动时, 启动 n 个worker, 通过 init_worker_by_lua脚本共同争用一把全局锁, 拿不到锁的, 结束init_worker_by_lua阶段, 开始正常处理请求, 拿到锁的, 进入 repeat ... until false, 同步一些请求处理需要的配置
期望: 拿到锁的 worker 永远在 init_worker_by_lua阶段, 通过死循环同步配置永不退出
问题: 线上2000台机器, 经过一晚上运行, 有2台机器出现死循环退出的情况
试图解决: repeat 已经做了如下处理:

repeat
pcall(cron.try_load)
until false

通过 pcall 捕获可能出现的任何异常

然而, 还是存在 worker 从循环退出的情况

从 error.log 中, 看不到 stack 信息
有每小时切分日志的信号发送, 可以看到, 在 worker 退出的时间点, 也处理了切分日志信号

可以判断, nginx worker 在死循环+pcall 的情况下, 异常退出

麻烦问一下, 问题可能出在哪

或者, 有没有其他解决方法

thanks

你好！

真是太巧了，最近我也在尝试这种玩法，但我并非让这些阻塞住的worker去做配置同步，而是做I/O进程。

先说下我的看法:

还好, 因为 worker 在 sleep 期间和同步期间是不占用 cpu 的, 单起一个 worker 跑也没什么问题

定时器有坑, 设置定时器之后, 在同步期间, 会有部分请求耗时过长, ab 压测下, 2核心, 加了定时器 qps 降低1000, 最长延时由16ms 到了2000ms+, 可能定时器的部分逻辑到了请求中执行

如果你只是做配置同步，拉出来若干worker来只干这件事情，是否几分杀鸡用牛刀之意呢？worker级别的定时器timer不是很好么？(要实现周期循环单例，加上timestamp即可)

worker 被杀死不是问题, 被杀死以后, nginx 会重启 worker, 由于有锁的逻辑, 会重新进入配置同步, 问题在于, worker 没有被杀死, 二是退出了死循环逻辑
若是必须采取这种方式，就要满足设计容错性的要求，就必须加上worker被杀然后重生时的抢锁逻辑:

同上, worker 重生不是问题
现在的DICT不大适合做这件事(它的超时释放到这儿就不大适合了)，建议使用内核为进程间同步所提供的锁(最方便的如文件锁)，进程被杀后，内核便会为它做锁释放，这样便可完美解决新worker重生时的身份判定问题。

--

YuanSheng Wang

---------------------------------------

My Github: https://github.com/membphis

OpenResty lover ^_^

agentzh

Hello!

2016-03-12 17:44 GMT-08:00 Yun Thanatos:
>   至于这种完全阻塞住某一部分workers的玩法，在nginx整体上逻辑是否严格正确，让我们等待春哥的帮助 :)
>

只要你能解决 HUP reload 这样的需要所有 nginx worker 及时退出的情形。

不过话说，我也在考虑让 ngx_lua 支持创建特殊的不服务客户端请求的 worker 进程，有些像 nginx 核心中现有的 cache
manager 这样的特殊 worker 进程。我们可以在这样的 worker 里面跑一些特殊的 Lua 逻辑。

Regards,
-agentzh

kytexzy

只要你能解决 HUP reload 这样的需要所有 nginx worker 及时退出的情形。

不过话说，我也在考虑让 ngx_lua 支持创建特殊的不服务客户端请求的 worker 进程，有些像 nginx 核心中现有的 cache
manager 这样的特殊 worker 进程。我们可以在这样的 worker 里面跑一些特殊的 Lua 逻辑。

我就非常想要一个独立的进程来处理和下游连接无关的业务逻辑，这个太赞了。