Monthly Archives: 4 月 2019

Nginx+Tomcat偶现502分析

问题

业务为了负载均衡，前面放了个 Nginx，但最近 502 报警有点频繁，影响了 SLA，因此对这个问题做了较深入的研究。

502 Bad Gateway

简单来说就是 Nginx 找不到一个可用的 upstream，可能的原因有：

  1. 压根是配置错误
  2. 连接 upstream server 发生错误/超时
  3. upstream server 到了处理瓶颈

还有一个重点是轮询了 upstream server 后任然没有一个可用的。但是不管什么原因，都能在 Nginx 的 error log 中找到报错详情。

upstream prematurely closed connection

在 Nginx 中找到错误日志（开了 debug）：

看了下 Nginx 代码，发现是 c->recv(); 读到的内容为 0，日志中也有显示 recv: fd:65 0 of 4096，说明没有获取到 response

同时也查了 Tomcat access 日志，请求还没到 Tomcat。看情况就像日志里面说的，连接被断掉了。

一开始怀疑是网络原因导致连接断掉了，但出现较频繁，期间内网也无网络故障，应该和网络无关。

再看日志发现报错前后有很多 keepalive 信息，尝试关掉 keepalive，502 就没了，但这会对性能有一定影响，感觉有点因噎废食了，还得继续研究。

keepalive

HTTP 持久连接（HTTP persistent connection，也称作 HTTP keep-alive 或 HTTP connection reuse）是使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。

一般 Nginx 会配置 keepalive 以提高性能：

Syntax: keepalive connections;

Activates the cache for connections to upstream servers.

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以配置每个 worker 对 upstream servers 最大长连接数量。同时这个长连接受 keepalive_requests（默认100） 和 keepalive_timeout（默认60s）配置的影响。

但 keepalive 也有缺陷，会加重 webserver 的负担，因为需要绑定一定数量的线程或者进程来维持长链接。注意 keepalive 并没有连接复用（即同一时间窗口不能处理多个请求，这个在 HTTP/2 中才实现），仅节省了新建/关闭连接的开销，类似连接池了。所以 webserver 一般都有类似 nginx 的 keepalive_requests、keepalive_timeout 配置，让空闲的连接断掉。

查看了 upstream(tomcat) 配置的 timeout 是20s，lighttpd 的 requests 是16，timeout 是 5s，都远小于 nginx 的配置。

原因就清楚了，upstream servers 先断了 keepalive 的长连接，但 nginx 仍使用了这个已经断掉的连接。

至于 nginx 为什么不主动检测一下连接是否可用呢？猜测应该是性能原因，一直检查连接池中的连接是否可用没必要，keepalive 协议本身也没业务心跳啥的。PS：商业版的 ngx_http_upstream_hc_module 可以主动监测（世界加钱可及）。

proxy_next_upstream

那么 Nginx 如何保证高可用呢？答案是重试。这就涉及另一个重要配置 proxy_next_upstream，在什么情况下进行重试，默认为 error timeout。按理说我们这个场景应该会重试，但没有重试。这是因为 Nginx 较新版本（1.9.13）多了个 non_idempotent 配置，默认 POST, LOCK, PATCH 等请求不重试，因为这些操作是非幂等操作，会对服务端数据造成影响（比如发消息接口，重试可能会重复发消息）。日志中也发现 502 的全都是 POST 请求。

要完全解决这个问题就需要对 proxy_next_upstream 配置簇深入看看，我们先做个测试。 Continue Reading...

Windows 10生产力提升之WSL实践

Mac 和 Windows 哪个更好，估计还能再吵几年。抛开部分硬件上的差距，Windows 用作开发上确实有点不顺手，毕竟大部分后端程序都是运行在 Linux 服务器上，macOS 占有先天优势。之前都是通过在 Windows 上起虚拟机来解决这个问题，如今 Windows 10 推出的 WSL（Windows Subsystem for Linux），成为了新的选择。

WSL 的官方介绍：

The Windows Subsystem for Linux lets developers run GNU/Linux environment - including most command-line tools, utilities, and applications - directly on Windows, unmodified, without the overhead of a virtual machine

简单来说就是不需要修改，无需虚拟机，就可以在 Windows 上直接使用 Linux 环境（grep, sed, awkd等），运行 Linux 程序（vim, MySQL, Apache等）。这就很舒服了，小孩子才做选择，大人全都要，实际如何我们来实践一番。

安装

首先是按照，非常简单，开启子系统功能后在应用商场选择一个发行版的 Linux 安装就行。官方指南：https://learn.microsoft.com/en-us/windows/wsl/install

启动之后就可以使用了，你可以根据自己使用习惯，做一些初始化的设置（oh-my-zsh啥的）这里就不细说了。WSL 默认是通过安装的应用进入的（直接运行 bash.exe 也行），但大家还是喜欢通过 Xshell 等工具进入了，这就需要做一些配置。WSL 和 Windows 本机是端口共用的（这点特别注意，防止程序端口冲突了），直接通过 127.0.0.1 就能连接上，剩下的就和直接使用 Linux 差不多了。

但是，等你重启电脑，再使用 Xshell 连接时发现连不上了，没有 sshd 进程了，每次都需要打开 WSL 程序然后再运行 sudo service ssh start 有点麻烦。这就是 WSL 不一样的地方了，WSL 不是真正的一个系统，没有开机启动这一说，把 sshd 设置成开机启动也没有用。既然不能加入到 WSL 的启动项，那就加入到 Windows 的启动项中：

编写 run_wsl.vbs 脚本，用来在 bash.exe 中启动 sshd，然后将脚本放到系统启动目录里面（WIN+R 运行 shell:Common Startup 或者 shell:startup）就行了。

不过需要注意 sudo 需要输入密码，还得把密码关了。WSL 中运行 sudo visudo 增加一行：ubuntu ALL=(root) NOPASSWD: ALL，表示 ubuntu （换成自己的）这个用户使用 sudo 运行任何命令时都不用输入密码。

当然安装之后可能会遇到一些其它问题，主要是一些安全软件和 WSL 不兼容，比如卡巴斯基会让 WSL 无法联网，腾讯的 TGP 会影响绑定端口，遇到了只能暂时关掉相关软件，相信之后这些问题会越来越少。

使用 Redis

之前在 Windows 上使用 Redis 比较麻烦，有一个 Windows 版的 Redis 但已经很久没有更新了，还有就是选择虚拟机。现在直接在 WSL 里面编译安装（make & make install）就行了。写好配置文件，sudo redis-server /etc/redis/redis.conf 运行即可。

不过有些同学可能会像我之前把 Redis 注册为 systemd 服务，但发现会报错：System has not been booted with systemd as init system (PID 1). Can't operate 说的也比较明白，系统不是通过 systemd 启动的。其实 WSL 不是一个真正的系统，应该说是一个容器，类似 Docker（这么一说感觉微软野心好大）。

LXSS diagram

（图片来源：https://learn.microsoft.com/zh-cn/archive/blogs/wsl/windows-subsystem-for-linux-overview）

在 WSL 中运行的程序是真正的 Linux 二进制文件，不是移植版，不过当程序由用户态切换到内核态时lxss.sys和lxcore.sys驱动将会将 Linux 的系统调用翻译为  NT APIs 来模拟 Linux 内核。简单来说 WSL 是将 LInux 底层 API 用 NT 实现了一遍（所以 WSL 中没有 Linux kernel 代码），而且有些操作还是 Linux 独有的，比如fork()，可想而知这里面工作量有多大，任重而道远。

言归正传，Redis 已经在 WSL 中启动了，我们试试在 Windows 上能不能连上：

完美，就和 Windows 本地装的 Redis 一样。

与IDE集成

虽然说大部分语言都是跨平台的，但是还是有很多差别，比如 Python 的 epoll 只能在 Linux 下使用。在 Windows 上开发不是很方便，没有智能提示，还需要上传到服务器运行、调试。有了 WSL，现在可以在 Windows 上开发，然后直接在 WSL 里面运行。 Continue Reading...