专栏首页皮振伟的专栏[linux][nginx]nginx的graceful shutdown和worker shutdown timeout

[linux][nginx]nginx的graceful shutdown和worker shutdown timeout

前言: 某大佬问作者,nginx做proxy的时候,重新加载配置的时候,会不会影响已有的连接? 作者基于too young too simple的认知:client和proxy之间有established连接,proxy和upstream直接有established连接;重启proxy就以为着重新启动proxy worker进程,kernel在进程exit的试试,会关闭掉所有的fd(socket本身就是fd的一种),就会发生重新连接。。。 然而,作者还是用最新的nginx做了一下实验,nginx实力打脸!作者查了一下git log,大约有两个feature起的影响比较大:graceful shutdown和worker shutdown timeout 分析: 1,client – proxy – upstream环境

简单的client – proxy – upstream环境,为了简化模型,proxy和upstream都是单worker的。实际情况下,一般worker都是per-cpu的,upstream也会比较多。 2,reload

修改nginx的conf文件,执行nginx -s reload,就会让proxy重新加载配置。在没有graceful shutdown这个feature之前,nginx proxy的worker重新启动,会给client和upstream发送FIN信号(TCP断开连接的过程)。如果client需要继续访问,就需要重新连接。 3,graceful shutdown & worker shutdown timeout

在有了graceful shutdown这个feature之后,worker并不是直接关掉的。而是让之前的连接继续保持在原来的worker上,并设置了worker的名字是“worker process is shutting down”(ps -ef | grep “worker process is shutting down”即可查到),而新的连接则连接到了新的worker上。实现细节如下图: 在nginx/src/os/unix/ngx_process_cycle.c中的ngx_worker_process_cycle函数中

对于之前的worker进程,并不是直接执行ngx_worker_process_exit退出的。会先执行ngx_close_listening_sockets把listen fd关闭掉,则可以保证不处理新的SYN包,也就不会建立新的连接了;而设置ngx_set_shutdown_timer,则可以在timeout的时候,依次主动关闭掉所有的连接,并退出。

timeout的默认时间是无限,也就是需要等到所有连接失效的时候主动关闭,这个feature需要的nginx版本是1.11.11之后:

4,影响 graceful shutdown看起来是一个非常完美的方案,是不是没有side effect呢? 这个实验需要的量级比较大,作者没有实验,但是猜测:在执行graceful shutdown这段时间里,之前的worker上的连接是逐渐减少的,新worker的连接是逐渐增多的。在这段时间里,会短暂的存在多一倍的worker数量。而一般nginx的配置是per-cpu的,那么就2倍数量的worker短暂存在,这段时间的context switch会增多,多个进程切换也会让延迟增加一点点延迟。

本文分享自微信公众号 - AlwaysGeek(gh_d0972b1eeb60),作者:AlwaysGeek

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-04-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • ​[usb][tcp]usbredir的优化---TCP keepalive

    前言: 前文《[kvm][qemu]影响虚拟化热迁移的设备》中提到了usbredir技术,也顺便提到了对它的TCP keepalive的优化。 本文分析usbr...

    皮振伟
  • [linux][network]互联网后台模型

    前言: 虽然话题的范围有点大,但是在这里作者不打算谈框架,侃架构。 这里也只是作者最熟悉的一种后台架构模型。 并发模型: 多进程模型: 来一个请求,设定环境...

    皮振伟
  • [virt][clock]steal time技术分析

    前言: 在《clocksource的管理和虚拟化》中,大概分析了kvm clock,tsc,hpet等clock source。其中尤其是kvm clock计算...

    皮振伟
  • nginx并发配置之worker_connections,worker_processes与 max clients

    原文:http://blog.51cto.com/liuqunying/1420556

    后端技术探索
  • 又拍云tokers-谈谈 nginx 信号集

    昨天下午的时候,一台引流测试机器的一个 ngx_lua 服务突然出现了一些 HTTP/500 响应,从错误日志打印的堆栈来看,是不久前新发布的版本里添加的一个 ...

    用户2825413
  • Node.js多线程完全指南[每日前端夜话0x43]

    很多人都想知道单线程的 Node.js 怎么能与多线程后端竞争。考虑到其所谓的单线程特性,许多大公司选择 Node 作为其后端似乎违反直觉。要想知道原因,必须理...

    疯狂的技术宅
  • node 线程池技术让文档编译起飞

    最近在维护微信文档这块内容,遇到一个问题,文档数量多起来编译时间会变慢,而且有时候会越来越慢。后面,发现文档的编译一直走的是单线程的,只用到了一个核,顿时感觉有...

    villainhr
  • Nginx架构初探(值得细品的长篇好文)

    众所周知,nginx性能高,而nginx的高性能与其架构是分不开的。那么nginx究竟是怎么样的呢?这一节我们先来初识一下nginx框架吧。 nginx在启动后...

    用户1263954
  • Nginx核心模块常用指令

    配置示例 user www www; worker_processes 2; error_log /var/log/nginx-error.log info; ...

    用户1263954
  • nginx 多进程架构详解

    一、进程模型 众所周知,nginx性能高,而nginx的高性能与其架构是分不开的。那么nginx究竟是怎么样的呢?这一节我们先来初识一下nginx框架吧。

    后端技术探索

扫码关注云+社区

领取腾讯云代金券