排错 on 寻 Mi 处

凌晨两点收到 502 告警，最后查出来是文件描述符不够用

Sun, 23 Feb 2025 17:56:00 +0800

手机在枕头边上震了两下。我摸起来看了一眼，是监控发的，blog.mibase.top 返回 502。

当时是凌晨两点十分。我第一反应是想装死，第二天早上再说。但那台机器上还挂着别的东西，万一是一起挂了，拖到早上就麻烦。

爬起来开电脑，连上去看。

现象

`1`	`systemctl status nginx`

状态是 active (running)，但错误日志里一直在刷：

1
2

2025/02/23 02:08:41 [alert] 8123#8123: *55123 open() "/var/log/nginx/access.log" failed (24: Too many open files)
2025/02/23 02:08:41 [crit] 8123#8123: *55124 open() "/srv/www/blog/public/index.html" failed (24: Too many open files)

Too many open files，这个报错我见过，但一直以为离自己很远。

什么是文件描述符

Linux 里一切皆文件。不只是磁盘上的文件，网络连接、管道、设备、socket，在内核眼里都是一个文件，用一个整数来标识，叫文件描述符，简称 fd。

每个进程能同时打开多少个 fd，是有上限的。这个上限来自三个地方，一层压一层。

最外面那层是内核的全局上限，/proc/sys/fs/file-max，一般很大，几十万，通常不会撞到。

往里一层是用户级限制，ulimit -n，这个是每个登录会话的限制。

最里面是进程自己的限制，从父进程继承，可以用 prlimit 查看。

nginx 作为服务跑，它继承的是 systemd 给它的限制，而不是我 SSH 登录之后的 ulimit。这一点很关键，后面会说。

先看当前值

# 当前会话
ulimit -n

# nginx 主进程的实际限制
sudo cat /proc/$(pgrep -o nginx)/limits | grep 'open files'

# 系统全局
cat /proc/sys/fs/file-max

# 系统当前用了多少
cat /proc/sys/fs/file-nr

我那次查出来，nginx 的限制是 1024。

1024 这个数字是老系统的默认值，现在看着确实小。nginx 每个连接要占两个 fd，一个给客户端，一个给上游。1024 意味着理论上最多五百个并发连接，实际还要留一些给日志文件、监听 socket，能用的更少。

我那个站平时并发不高，但那天晚上有人在爬，连接数上去了，直接撞到天花板。

改系统级限制

/etc/security/limits.conf 是老办法：

1
2

*    soft nofile 65535
*    hard nofile 65535

这个文件只对通过 PAM 登录的会话生效，也就是 SSH 登录、su 这些。对 systemd 服务不一定管用，因为 systemd 启动服务的时候不走 PAM 的 limits 那一套。

所以还得改 systemd 的配置。

/etc/systemd/system.conf 或者针对单个服务写 override：

sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo tee /etc/systemd/system/nginx.service.d/limits.conf <<'EOF'
[Service]
LimitNOFILE=65535
EOF

然后：

1
2

sudo systemctl daemon-reload
sudo systemctl restart nginx

验证：

`1`	`sudo cat /proc/$(pgrep -o nginx)/limits \| grep 'open files'`

应该显示 65535。

还有一层：systemd 自己的默认值

Debian 12 和 Ubuntu 22.04 之后，systemd 有个 DefaultLimitNOFILE 的默认值，是 1024:524288。意思是软限制 1024，硬限制 524288。

也就是说，如果你不显式设置，服务拿到的软限制还是 1024，硬限制虽然是 524288，但进程不会自己去把它调高。

这就是为什么很多人改了 limits.conf 之后发现没效果。服务是通过 systemd 起的，不走 PAM。

/etc/systemd/system.conf 里可以全局改：

1
2

[Manager]
DefaultLimitNOFILE=65535

改完 daemon-reload，然后重启所有服务才生效。我一般不改全局，只给需要的服务单独写 override，影响面小一点。

nginx 自己的配置也要改

系统限制放开了，nginx 的配置里还有一个上限。

1
2
3

events {
    worker_connections 1024;
}

这个值决定了单个 worker 能同时处理多少个连接。

worker 的数量是 worker_processes，一般设成 CPU 核数或者 auto。总的并发能力大致是 worker_processes × worker_connections。

我把这两个都调了：

worker_processes auto;

events {
    worker_connections 8192;
    multi_accept on;
    use epoll;
}

multi_accept on 让一个 worker 一次接受多个新连接，高并发下能减少系统调用。

use epoll 在 Linux 上是默认值，写出来只是为了明确。BSD 系才需要 kqueue。

注意，worker_connections 不能超过 LimitNOFILE。如果系统限制是 1024，你写 8192 也没用，nginx 启动的时候会警告，实际还是被卡在 1024。

一个容易忽略的点：日志文件

nginx 每个 worker 都要打开 access.log 和 error.log。如果开了很多虚拟主机，每个都有自己的日志文件，这个数字会累积。

我那次有七个站点，每个两套日志，加上主配置的，一共十五个文件。乘以 worker 数，就是几十个 fd。虽然不多，但在接近上限的时候，这就是压死骆驼的最后一根稻草。

解决办法是减少日志文件数量，或者用 access_log off 关掉不需要的。我把几个不重要的站的 access log 关了，只留 error log。

排查当时到底谁在占

改配置之前，我想先确认一下是不是真的连接数暴涨。

ss -s

输出里有个 TCP: 1234 (estab 890, closed 210, orphaned 0, timewait 130)。890 个 established，对于那个站来说确实异常。

再看是谁：

`1`	`ss -tn state established '( sport = :443 )' \| awk '{print $5}' \| cut -d: -f1 \| sort \| uniq -c \| sort -rn \| head`

有一个 IP 占了三百多个连接。看 User-Agent，是一个很老的爬虫标识，明显是伪造的。

临时封掉：

`1`	`sudo iptables -I INPUT -s <IP> -j DROP`

连接数立刻下来了。但这只是止血，根本问题还在。

后来做的几件事

最直接的是给 nginx 加连接数限制：

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    limit_conn addr 20;
    limit_conn_status 429;
}

单个 IP 最多二十个并发连接，超了直接 429。这个比事后封 IP 有效得多。

另一个是 keepalive 的超时。默认 keepalive_timeout 75s，意味着一个空闲连接要占着 fd 七十五秒。我改成 20 秒：

1
2

keepalive_timeout 20s;
keepalive_requests 100;

keepalive_requests 是单个连接最多处理多少个请求，到了就关。默认是 1000，对于被爬的情况，调小能让连接更快轮换出去。

最后是把 LimitNOFILE 写进了所有需要高并发的服务，不只是 nginx。MariaDB、Redis 这些也都有各自的连接数上限，同样受这个限制。

怎么验证改对了

改完之后，我用 ab 压了一下：

`1`	`ab -n 5000 -c 200 https://blog.mibase.top/`

-c 200 是两百个并发。跑的时候盯着 fd 数量：

`1`	`watch -n 1 'ls /proc/$(pgrep -o nginx)/fd \| wc -l'`

这个数字应该随着并发上去，压测结束后回落到一个稳定的值，不报错就说明改对了。

如果还是报 Too many open files，那就是某一层的限制没改到位，按 ulimit → systemd override → nginx 配置这个顺序再检查一遍。

一点延伸

这个限制不只在 nginx 上有。

MySQL 的 open_files_limit、Redis 的 maxclients、Java 应用的 socket 数量，最后都会落到这个 fd 上限上。

还有一个容易被忽略的，就是 Docker 容器。容器里的进程继承的是宿主机的限制，但如果你在 compose 里没设，拿到的可能是 Docker daemon 的默认值。可以在 compose 里显式指定：

services:
  app:
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

这个写法比在容器里改 /etc/security/limits.conf 靠谱，因为容器里那个文件经常不生效。

现在

那天晚上折腾到快四点。改完配置，压测通过，才回去睡。

现在这台机器的 LimitNOFILE 是 65535，nginx 的 worker_connections 是 8192。跑了几个月，没再出过这个问题。

回头看，这个故障本身不复杂，但它的排查过程逼着我把 Linux 的资源限制体系理了一遍。fd 上限、ulimit、PAM、systemd、cgroup，这几层的关系搞清楚之后，很多类似的问题都能举一反三。

运维这件事，最怕的不是不懂，是以为自己懂。

journalctl 用熟了之后，排查问题快了一大截

Wed, 01 Jan 2025 13:22:00 +0800

刚开始用 systemd 那会儿，我对 journalctl 的理解就停在 journalctl -xe 这一个命令上。

出问题了就敲一下，刷出一大屏东西，然后肉眼从头翻。翻到中间发现前面还有线索，又得往上滚。滚着滚着忘了自己要找什么。

后来有一台机器的 nginx 每天早上六点准时挂一次，重启就好，第二天照旧。我靠翻日志翻了三天没找到原因，最后是同事提醒我，用 --since 把时间窗缩到五分钟。

那次之后我才认真学了这套工具。

它到底存在哪儿

先搞清楚一件事，journald 的日志默认是存在内存里的。

准确说是存在 /run/log/journal/，这是 tmpfs，重启就没了。所以很多人第一次用的时候会觉得，日志怎么只有今天的。

想让它持久化，改一下配置：

1
2
3

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

目录一建好，journald 下次启动就会自动把日志写进 /var/log/journal/，同时把 /run 里的搬过去。

这一步很重要。我见过太多人排查"昨天晚上的故障"，结果发现日志已经被重启清掉了。

时间过滤是最有用的一个

--since 和 --until 支持很自然的写法：

journalctl --since "2025-01-01 13:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until "today 06:00"
journalctl --since "-30min"

我常用的组合是这样：

`1`	`journalctl --since "today 05:50" --until "today 06:10" -u nginx`

意思是看今天早上六点前后二十分钟里 nginx 的日志。那次定时挂掉的问题，就是这么定位的。日志里有一段明显的 worker process exited on signal 9，再往前看，是 OOM killer 干的。

这个时间窗的思路比翻全部日志有用得多，尤其是日志量大的机器。

按服务看

-u 后面跟 unit 名：

`1`	`journalctl -u nginx -u php8.2-fpm`

可以跟多个，它会把两个服务的日志按时间交错排在一起。排查"nginx 502 到底是不是 php-fpm 挂了"这种问题，这个写法特别顺手。

看某个服务的全部历史：

`1`	`journalctl -u mariadb --no-pager \| less`

--no-pager 是让它别调用 less，直接输出，方便管道到 grep。

按优先级过滤

-p 参数，数字越小越严重：

0  emerg
1  alert
2  crit
3  err
4  warning
5  notice
6  info
7  debug

`1`	`journalctl -p err -b`

这个是看本次启动以来的所有错误及以上级别。-b 是 --boot 的缩写，只显示当前这次开机之后的。

-p 的行为有个细节，它是"该级别及以上"，也就是 -p err 会显示 err、crit、alert、emerg。所以只看 err 的话，得写 -p err..err。

按启动次数

-b 后面可以跟数字：

journalctl -b        # 本次启动
journalctl -b -1     # 上次启动
journalctl -b -2     # 上上次
journalctl --list-boots   # 列出所有启动记录

--list-boots 的输出长这样：

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 3f2a...                          Mon 2024-12-30 08:12:33 CST Sun 2024-12-31 22:01:09 CST
 -1 8b1c...                          Tue 2024-12-31 22:15:44 CST Wed 2025-01-01 09:33:12 CST
  0 a9d4...                          Wed 2025-01-01 09:40:02 CST Wed 2025-01-01 13:20:55 CST

这个表在排查"上次重启之前发生了什么"的时候特别好用。比如机器莫名其妙重启了，journalctl -b -1 -p err 就能看到重启前的最后几条错误。

前提是日志持久化了。没持久化的话，-b -1 是空的。

按进程和 PID

1
2

journalctl _PID=1234
journalctl _COMM=nginx

下划线开头的这些是 journald 的字段名。常用的几个：

_PID 进程号，_UID 用户 ID，_GID 组 ID，_COMM 命令名，_EXE 可执行文件路径，_SYSTEMD_UNIT 所属的服务。

_COMM 和 -u 的区别是，-u 是按 systemd 单元过滤，_COMM 是按进程名过滤。一个服务可能有多个进程，也可能有不属于任何单元的进程。

输出格式

默认的输出带颜色和缩写，人看方便，但贴到别处就乱了。

-o 参数可以换格式：

1
2
3

journalctl -o json-pretty -u nginx -n 1
journalctl -o short-iso -u nginx
journalctl -o cat -u nginx

json-pretty 能看到所有字段，调试的时候很有用。比如想看一条日志的所有元数据：

`1`	`journalctl -o json-pretty -n 1 \| jq .`

会输出 _HOSTNAME、_TRANSPORT、SYSLOG_IDENTIFIER、PRIORITY 一大堆字段。了解这些字段名，你才能写出精确的过滤条件。

short-iso 把时间戳改成 ISO 8601 格式，带时区。给别人发日志的时候用这个，不会因为时区不同产生误解。

cat 只输出消息内容，没有时间戳和主机名。适合管道给别的工具处理。

实时跟踪

1
2
3

journalctl -f
journalctl -f -u nginx
journalctl -f -p warning

-f 就是 follow，类似 tail -f。调试的时候开一个窗口挂着，另一边操作，看日志实时滚出来。

-f 加 -p warning 这个组合我经常用，它能过滤掉大量无关的 info 级别噪音，只留下值得看一眼的东西。

磁盘占用和清理

`1`	`journalctl --disk-usage`

我第一次跑的时候看到 1.8G，吓一跳。

默认的上限是文件系统的百分之十，但有最小值 4G 的兜底。也就是说，如果你的盘小于 40G，日志最多能占到 4G。这在 20G 的小机器上是灾难。

改 /etc/systemd/journald.conf：

[Journal]
Storage=persistent
SystemMaxUse=200M
SystemMaxFileSize=50M
SystemKeepFree=1G
MaxRetentionSec=1month

SystemMaxUse 是总量上限，SystemMaxFileSize 是单个文件上限，SystemKeepFree 是至少给文件系统留多少空间，MaxRetentionSec 是时间上限。

改完重启：

`1`	`sudo systemctl restart systemd-journald`

立刻清理到上限：

1
2

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=30d

这两个是手动触发的，不用等自动轮转。

权限这件事

普通用户默认只能看自己的日志。

`1`	`journalctl`

会输出 No journal files were found 或者只显示很少的内容。

要看得全，要么 sudo，要么把自己的用户加进 systemd-journal 组：

`1`	`sudo usermod -aG systemd-journal $USER`

加完要重新登录才生效。这个组是在安装 systemd 的时候建的，默认存在。

一个真实的排查过程

说说那次早上六点定时挂的问题，完整走一遍。

先确认现象：

`1`	`journalctl -u nginx --since "today 05:55" --until "today 06:05"`

看到 nginx 在 06:00:12 报了 worker process exited on signal 9，然后是 no live upstreams。

signal 9 是 SIGKILL，普通信号杀不掉它，只有 OOM killer 或者有人手动 kill -9。

看内核日志：

`1`	`journalctl -k --since "today 05:55" --until "today 06:05"`

-k 是 --dmesg 的简写，只看内核消息。果然：

`1`	`Out of memory: Killed process 12345 (nginx) total-vm:...`

那就清楚了，是内存不够。问题是为什么每天早上六点。

再查那个时间点有什么在跑：

`1`	`journalctl --since "today 05:58" --until "today 06:02" \| grep -i cron`

找到了，/etc/cron.d/backup 在 06:00 跑备份，tar 加 gzip 压缩的时候把内存吃满了。

解决办法是给备份脚本加 nice 和 ionice，再把 nginx 的 worker_processes 调小一点。改完第二天早上六点，一切正常。

整个过程大概十分钟。如果只会 journalctl -xe 从头翻，估计得翻半天。

几个小技巧

日志里有敏感信息的时候，--no-hostname 可以去掉主机名。

journalctl -n 50 是只看最后五十行，比 tail -n 50 快，因为它是从索引里直接取的。

journalctl --verify 可以检查日志文件的完整性。文件系统出过问题之后跑一下，能发现有没有损坏的段。

还有一个 journalctl -u nginx -o json | jq -r 'select(.PRIORITY=="3") | .MESSAGE'，用 jq 处理 json 格式，可以写出很复杂的过滤逻辑。日志量大的时候比 grep 好用。

现在

我现在的习惯是，遇到任何服务异常，第一步永远是：

`1`	`journalctl -u <服务名> --since "-30min" -p warning --no-pager`

这条命令基本能覆盖八成的场景。剩下的两成，才需要去翻更早的日志或者换过滤条件。

工具本身不复杂，关键是要知道它在哪儿、按什么维度组织。把时间、单元、优先级这三个维度用熟了，排查效率的提升是立竿见影的。