Linux on 寻 Mi 处

每天几千次爆破登录，我把 SSH 彻底加固了一遍

Tue, 18 Aug 2026 00:33:00 +0800

新买的 VPS，装完系统第一次登录，我习惯先看一眼日志。

`1`	`journalctl -u ssh --since "1 hour ago" \| grep -c "Failed password"`

三百多次。这才开机一个小时。

再看来源，全世界各地，用户名从 root 到 admin 到 oracle 到 test，全都是自动化脚本在扫。

这些尝试基本不可能成功，因为我的密码是随机生成的。但看着这些日志还是不舒服，而且它们会占带宽、占 CPU、把日志撑大。

所以每台新机器，我都会花半小时把 SSH 加固一遍。

先建一个普通用户

root 直接登录是最危险的。一旦密码泄露，攻击者拿到的是最高权限。

建一个普通用户：

1
2

adduser mingyue
usermod -aG sudo mingyue

Debian 和 Ubuntu 上 sudo 组有 sudo 权限。CentOS 上是 wheel 组。

然后测试这个用户能不能登录、能不能 sudo。这一步很重要，因为后面要禁用 root，万一普通用户有问题，就进不去了。

密钥登录

密码再复杂，也不如密钥。

原理是非对称加密。你本地有一对密钥，私钥自己留着，公钥放到服务器上。登录的时候，服务器用公钥验证你手里的私钥，验证通过就放行。整个过程私钥不会离开你的机器。

生成密钥：

`1`	`ssh-keygen -t ed25519 -C "mingyue@laptop"`

-t ed25519 是算法。ed25519 比 rsa 更短、更快、更安全。现在的 OpenSSH 都支持。

如果你的客户端特别老，不支持 ed25519，那就用 -t rsa -b 4096。

-C 是注释，一般写邮箱或者用途，方便识别。这个不影响功能。

生成过程中会问你要不要设密码。这个密码是保护私钥文件的，不是登录密码。

设了之后，每次用这个私钥都要输一遍。可以用 ssh-agent 缓存，输一次管一段时间。

我的建议是设一个。私钥文件如果泄露了，有这个密码还能挡一层。

把公钥放到服务器

最方便的是 ssh-copy-id：

`1`	`ssh-copy-id -i ~/.ssh/id_ed25519.pub mingyue@服务器IP`

它会让你输一次密码，然后把公钥追加到服务器的 ~/.ssh/authorized_keys 里。

如果没有这个命令（Windows 的某些环境），可以手动：

`1`	`cat ~/.ssh/id_ed25519.pub`

复制输出的内容，然后登录服务器：

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "粘贴的公钥内容" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

权限必须对。.ssh 是 700，authorized_keys 是 600。权限不对，SSH 会拒绝使用这个文件，而且报错信息很含糊，只说什么 “bad permissions”。

这个坑我踩过，当时找了好久。

测试

新开一个终端，不要关掉当前这个。

`1`	`ssh -i ~/.ssh/id_ed25519 mingyue@服务器IP`

如果不需要输密码就进去了，说明密钥配好了。

如果还要输密码，说明公钥没生效。检查 authorized_keys 的内容和权限，还有 /etc/ssh/sshd_config 里的 PubkeyAuthentication 是不是 yes。

禁用密码登录

确认密钥能用之后，再改配置。

`1`	`sudo nano /etc/ssh/sshd_config`

找到这几行，改成：

1
2
3

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

注意 KbdInteractiveAuthentication 是新版的写法。老版本叫 ChallengeResponseAuthentication，Debian 12 用的是新的。

只改 PasswordAuthentication 不够，因为有些 PAM 配置会让键盘交互式认证绕过这个开关。两个都关掉才彻底。

改完先检查语法：

`1`	`sudo sshd -t`

没有输出就是没问题。

然后重启：

`1`	`sudo systemctl restart ssh`

Debian 12 的服务名是 ssh，不是 sshd。CentOS 上是 sshd。

重启之前一定要保持当前会话开着。 万一配置错了，你还能从这个会话里改回来。

禁用 root 登录

`1`	`PermitRootLogin no`

这个也要小心。如果你还没确认普通用户能 sudo，禁用 root 之后可能就进不去了。

保险的做法是先确认：

1
2

ssh mingyue@服务器IP
sudo whoami

能输出 root 就说明 sudo 是好的。

然后再改 PermitRootLogin。

改端口

22 端口是扫描器的重点目标。改成一个高位端口，能过滤掉绝大部分自动化扫描。

`1`	`Port 2222`

选端口的时候，避开常用的服务端口。2222 是常用的 SSH 替代端口，扫描器也会扫，但频率比 22 低得多。用一些不常见的端口效果更好，比如 50222。

改完还要改防火墙：

1
2
3

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo ufw reload

如果你用的是云服务器，安全组也要改。

本地配置别名

每次都敲端口和用户名太麻烦。本地 ~/.ssh/config：

Host blog
    HostName blog.mibase.top
    User mingyue
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

之后 ssh blog 就行。

ServerAliveInterval 60 是每六十秒发一个心跳包，防止连接因为空闲被断开。ServerAliveCountMax 3 是连续三次没响应就断开。

这两个参数在网络不稳定的环境下很有用，能避免那种"看着连着但已经死了"的情况。

fail2ban

改端口和密钥登录已经能挡掉大部分了，但总有些执着的扫描器会继续尝试。fail2ban 能让它们付出代价。

`1`	`sudo apt install fail2ban`

配置不要改 jail.conf，改 jail.local：

1
2

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

在文件末尾加：

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
backend  = systemd
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s

backend = systemd 是因为 Debian 12 默认没有 /var/log/auth.log，日志都在 journald 里。用 systemd 后端让 fail2ban 通过 journalctl 读。

maxretry = 3 是三次失败就封。bantime = 1h 是封一小时。

启动：

`1`	`sudo systemctl enable --now fail2ban`

看状态：

`1`	`sudo fail2ban-client status sshd`

输出里能看到当前封了多少个 IP，以及被封的列表。

更进一步

上面这些做完，安全性已经不错了。如果还想再收紧，有几件事可以做。

限制登录用户：

`1`	`AllowUsers mingyue`

只有这个用户能登录，别的都被拒绝。

限制登录来源 IP：

1
2

Match Address 1.2.3.4/32
    PermitRootLogin yes

这个可以给特定 IP 开特例。我一般不用，因为我的 IP 是动态的。

关掉 X11 转发：

`1`	`X11Forwarding no`

除非你真的需要图形界面转发，否则关掉能减少攻击面。

限制认证尝试次数：

1
2

MaxAuthTries 3
LoginGraceTime 30

LoginGraceTime 是登录的超时时间，默认是 120 秒。改成 30 秒，减少连接占用的时间。

只监听特定地址：

如果你的机器有多个 IP，可以只在一个上面监听：

`1`	`ListenAddress 1.2.3.4`

改坏了怎么救

这一步最重要。

如果配置改错，SSH 连不上，你还有几条路。

保留的会话。这是最简单的。改之前开着的那个会话，只要没关，就还能用。从这个会话里把配置改回去。

VNC 控制台。云服务器都提供这个功能，在网页上直接连到机器的显示器。用它登录进去修复。

救援模式。大多数云厂商有"救援模式"，会把机器重启到一个临时的系统，你可以挂载原来的磁盘修复配置。

重新装系统。最坏的情况，如果数据有备份，重装也很快。

我的习惯是，改 SSH 之前一定做三件事。备份配置文件，开一个新会话测试，确认云控制台能进。

这三件事花不了几分钟，但能在出事的时候救命。

现在的状态

我这台机器改完之后，每天的失败登录从几千次降到几乎为零。

fail2ban 的日志里，每天封几十个 IP，都是那种扫到 2222 端口然后试几个密码的。

有一次我看了一眼封禁列表，来自俄罗斯、巴西、印度、越南，全世界都有。这就是公网的真实环境。

安全这件事，没有一劳永逸。但把这些基础做好，就已经比绝大多数服务器安全了。大部分攻击都是广撒网，只要你的门槛比别人高一点，它们就换目标了。

断网之后命令跑到一半没了，我开始认真用 tmux

Sun, 12 Jul 2026 21:29:00 +0800

有一次我在服务器上编译一个东西，跑了快四十分钟。中间我去泡了杯茶，回来发现 SSH 断了。

笔记本进了休眠，网络断了。重新连上去，编译进程没了，得从头再来。

那次之后我才开始认真用 tmux。之前也装过，但一直停留在"知道有这么个东西"的阶段，没真正用起来。

它解决什么问题

简单说，tmux 让你的终端会话脱离 SSH 连接存在。

平时你 SSH 上去，开一个 shell，这个 shell 是挂在那条 SSH 连接上的。连接断了，shell 就收到 SIGHUP，进程跟着退出。

tmux 的做法是，先起一个服务端进程（daemon），你的 shell 跑在这个 daemon 下面。SSH 连接只是"附着"到这个 daemon 上。连接断了，daemon 还在，里面的进程继续跑。下次连上去，重新 attach 就能看到之前的样子。

这个概念叫"会话持久化"。它解决的不只是断线问题，还有多任务并行、窗口切换、远程协作。

装

`1`	`sudo apt install tmux`

版本检查：

tmux -V

3.x 之后的版本支持的东西比较全。Debian 12 自带的是 3.3a，够用。

三个概念

tmux 的结构分三层。

会话（session）是最外层的，一个会话可以理解成一个工作空间。比如一个会话做前端，一个会话做后端。

窗口（window）在会话里面，相当于浏览器的标签页。一个窗口占满整个终端。

面板（pane）在窗口里面，把终端切成几块。可以横向切，也可以纵向切。

日常用的时候，我一般是按项目分会话，每个会话里按任务分窗口，需要同时看两个东西的时候才切面板。

最常用的命令

从外部操作会话：

tmux new -s work        # 新建一个叫 work 的会话
tmux ls                 # 列出所有会话
tmux attach -t work     # 附着到 work
tmux kill-session -t work  # 杀掉 work

attach 可以简写成 a：

`1`	`tmux a -t work`

如果只有一个会话，tmux a 就够了。

从里面脱离：

`1`	`Ctrl+b 然后按 d`

Ctrl+b 是默认的前缀键，所有的 tmux 快捷键都要先按它。

快捷键

前缀键按完之后，再按一个键。常用的：

c 新建窗口，n 下一个窗口，p 上一个窗口，0-9 跳到指定编号的窗口，, 重命名窗口。

% 左右切分，" 上下切分。这两个符号有点反直觉，% 是竖着切（左右分），" 是横着切（上下分）。

方向键在面板之间切换。z 把当前面板最大化，再按一次还原。这个在需要看长输出的时候很有用。

[ 进入复制模式，可以用方向键或者 vi 的键位翻页。按 q 退出。

d 脱离，$ 重命名会话，s 列出所有会话并切换。

? 显示所有快捷键。这个最有用，记不住的时候按一下。

配置文件

默认的配置太素了，而且有些键位不顺手。

~/.tmux.conf：

# 改前缀键为 Ctrl+a，和 screen 一致，手更习惯
set -g prefix C-a
unbind C-b
bind C-a send-prefix

# 从 1 开始编号，和键盘上的位置对应
set -g base-index 1
setw -g pane-base-index 1
set -g renumber-windows on

# 更快的转义时间，vim 里按 esc 不用等
set -sg escape-time 10

# 支持 256 色和真彩色
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256col*:Tc"

# 鼠标支持
set -g mouse on

# 历史行数
set -g history-limit 50000

# 窗口和面板的分割线用细线
set -g pane-border-style fg=colour238
set -g pane-active-border-style fg=colour39

# 状态栏
set -g status-style bg=colour235,fg=colour250
set -g status-left "#[fg=colour39,bold] #S "
set -g status-right "#[fg=colour250]%Y-%m-%d %H:%M "
set -g status-interval 30

# 用 vim 的键位在复制模式里移动
setw -g mode-keys vi

# 分屏的时候保持当前目录
bind '"' split-window -v -c "#{pane_current_path}"
bind '%' split-window -h -c "#{pane_current_path}"
bind c new-window -c "#{pane_current_path}"

# 用 v 和 y 做复制粘贴，贴近 vim
bind -T copy-mode-vi v send -X begin-selection
bind -T copy-mode-vi y send -X copy-selection-and-cancel

几个值得解释的。

base-index 1 是让窗口从 1 开始编号。默认从 0 开始，但键盘上 1 在最左边，按起来更顺。

renumber-windows on 是关掉一个窗口之后，后面的自动重新编号。不加的话会出现 1、3、4 这样的空档。

escape-time 10 默认是 500 毫秒。在 tmux 里用 vim 的时候，按 esc 要等半秒才响应，很难受。改成 10 毫秒就好了。

mouse on 这个有人喜欢有人不喜欢。开着之后可以用鼠标点面板、拖滚动条、调整分割线。我觉得挺方便的，尤其是刚上手的时候。

pane_current_path 那几行是让新窗口和新面板继承当前目录。默认是新窗口从 home 目录开始，每次都要 cd 过去，很烦。

插件管理

tmux 的插件生态也不错，用 TPM（Tmux Plugin Manager）管理：

`1`	`git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm`

在 .tmux.conf 末尾加：

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'

run '~/.tmux/plugins/tpm/tpm'

然后按 Ctrl+a 再按 I（大写 i），它会自动安装。

tmux-sensible 是一堆合理默认值的集合，省得自己一条条配。

tmux-resurrect 能保存和恢复会话。机器重启之后，按 Ctrl+a 再按 Ctrl+r，之前的窗口和面板布局全都回来了。

tmux-continuum 是让 resurrect 自动保存，每十五分钟一次。还能设置成开机自动恢复。

这两个配合起来，体验很好。有一次我的服务器意外重启，恢复之后 tmux 自动把之前的会话全拉起来了，连每个面板的当前目录都在。

不过要注意，resurrect 默认不保存正在运行的程序的输出，只保存布局和目录。想让它保存 vim 的会话或者别的程序状态，得额外配置。

zsh

说完 tmux，说 zsh。

bash 用了很多年，够用。但 zsh 的补全和主题确实更好看，也更顺手。

1
2

sudo apt install zsh
chsh -s $(which zsh)

重新登录之后就是 zsh 了。

第一次启动会有一个配置向导，选 2 创建一个基础的 .zshrc。

然后装 oh-my-zsh：

`1`	`sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"`

oh-my-zsh 是个框架，提供主题和插件管理。有人觉得它太重，启动慢。确实有这个问题，在慢速文件系统上能感觉到。

如果在意启动速度，可以用 zinit 或者手动管理插件。我用了几年 oh-my-zsh，觉得还行，启动大概两百毫秒，能接受。

主题

我用的主题是 powerlevel10k，比 oh-my-zsh 自带的快很多，而且配置灵活。

1
2

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git \
  ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

.zshrc 里改：

`1`	`ZSH_THEME="powerlevel10k/powerlevel10k"`

第一次启动会进入一个配置向导，问你要什么风格的提示符、要不要图标、要不要显示时间。按自己的喜好选就行。

有个前提，终端字体要支持 Nerd Fonts，不然那些图标会显示成方块。我用的是 JetBrainsMono Nerd Font，在终端设置里选上。

插件

.zshrc 里加：

plugins=(
  git
  z
  zsh-autosuggestions
  zsh-syntax-highlighting
  zsh-completions
)

git 提供一堆 git 别名，比如 gst 是 git status，gco 是 git checkout。

z 是目录跳转。它会记录你去过的目录，之后 z blog 就能跳到 /srv/www/blog，不用敲完整路径。这个用熟了回不去。

zsh-autosuggestions 会根据历史命令给出灰色提示，按右方向键接受。敲长命令的时候特别省事。

zsh-syntax-highlighting 让命令有颜色，正确的命令是绿色，错误的是红色。敲错的时候能立刻发现。

后两个要单独装：

git clone https://github.com/zsh-users/zsh-autosuggestions \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

git clone https://github.com/zsh-users/zsh-syntax-highlighting.git \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

注意 zsh-syntax-highlighting 必须放在 plugins 数组的最后，因为它会包装所有命令，放前面会干扰别的插件。

别名

我在 .zshrc 末尾加了一堆别名：

alias ll='ls -alF'
alias la='ls -A'
alias ..='cd ..'
alias ...='cd ../..'

alias gs='git status'
alias gc='git commit -m'
alias gp='git push'
alias gl='git log --oneline --graph --decorate'

alias dps='docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"'
alias dcu='docker compose up -d'
alias dcd='docker compose down'
alias dcl='docker compose logs -f'

alias ngt='nginx -t && systemctl reload nginx'
alias jc='journalctl -u'
alias ports='ss -tulpn'

这些别名省下的时间不多，但每次省几秒，一天下来也不少。

两个配合起来

tmux 和 zsh 配合，体验最好的是这个场景。

我在本地开一个 tmux 会话，里面分三个面板。左边是编辑器，右上跑测试，右下看日志。

然后 Ctrl+a d 脱离，去干别的事。

回来 tmux a，三个面板原样还在，测试还在跑，日志还在滚。

这个工作流一旦形成习惯，就再也回不去了。

一个小技巧

tmux new -s work -d 是后台新建会话，不附着。

配合 ssh 可以做一件有意思的事。在本地 .ssh/config 里：

Host blog
    HostName blog.mibase.top
    User deploy
    Port 2222
    RequestTTY yes
    RemoteCommand tmux new -A -s main

tmux new -A -s main 的意思是，如果 main 会话存在就附着，不存在就新建。

这样每次 ssh blog 都会直接进到同一个 tmux 会话，不用手动 attach。断线重连也是回到原来的地方。

这个配置我用了一年多，非常舒服。

现在

tmux 已经是我每天都要用的东西，和编辑器一样重要。

回头看，真正让我开始用它的是一个很小的事，编译到一半断线。但用下来之后发现，它改变的是整个工作方式。你不再需要担心连接状态，不再需要开一堆终端窗口，所有东西都在一个会话里，随时可以离开，随时可以回来。

zsh 那边，提升的是日常操作的顺手程度。补全、提示、别名，每一样都不起眼，加起来就是每天少敲几百次键盘。

工具的价值就在这儿。它不解决什么大问题，只是让你每天重复的事情变得轻松一点。

把一百多 G 的网站数据搬到新服务器，中间没停过服务

Mon, 29 Sep 2025 02:00:00 +0800

那台老 VPS 跑了三年，配置早就跟不上了。1 核 2G，40G 硬盘，用到了 78%。新买的机器是 2 核 4G，80G 盘，价格还便宜一点。

换机器这件事，我拖了两个月才动手。不是因为难，是因为怕。上面跑着博客、两个小站、一个数据库、一堆容器，任何一个环节出错都是麻烦。

后来定了个策略，把整个过程拆成几段，每一段都可以单独验证，出问题能退回去。这才敢开始。

先盘点

动手之前先把老机器上有什么理清楚。

`1`	`du -sh /srv/* \| sort -h`

12G     /srv/docker
38G     /srv/www
  4G     /srv/backup
  2G     /srv/git

/srv/www 占了三十八个 G，主要是几个站点的图片和历史备份。/srv/docker 是镜像和卷。

再看系统层面：

1
2

crontab -l
systemctl list-unit-files --state=enabled

定时任务有五个，启用的服务有十一个。这些都要在新机器上重建。

`1`	`dpkg --get-selections > /tmp/packages.txt`

把装的软件包列表存下来，新机器上可以照着装。

新机器的准备

先把基础环境搭起来。

1
2
3

apt update && apt upgrade -y
apt install -y rsync nginx mariadb-server docker.io docker-compose-plugin \
  fail2ban ufw git curl htop tmux

然后是用户和权限。老机器上有个 deploy 用户，新机器也要建：

1
2

useradd -m -s /bin/bash deploy
usermod -aG sudo deploy

这一步要提前做，因为 rsync 同步的时候如果目标用户不存在，属主会变成数字，后面还得用 chown 改。

rsync 的参数

全量这一轮，我用的命令是这样：

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' \
  --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

一个个说。

-a 是 archive，等于 -rlptgoD，递归、保留权限、保留时间、保留属主属组、保留设备文件。这一项基本是必加的。

-v 显示进度，-z 压缩传输。压缩对于文本类文件有效，对已经压缩过的图片视频没效果，反而浪费 CPU。我这次因为大部分是图片，-z 其实没帮上什么忙，但也没坏处。

-H 保留硬链接。这个很重要，如果你用 rsnapshot 或者类似工具做备份，硬链接丢了体积会翻好几倍。

-A 保留 ACL，-X 保留扩展属性。如果你的文件有 SELinux 标签或者设置了 ACL，必须加这两个。

--numeric-ids 让 rsync 用数字 ID 而不是用户名来匹配属主。跨机器同步的时候，如果两边的用户名不一样，不加这个会按名字找，找不到就跳过。加了之后，即使 uid 不同也能保留。

--delete 删除目标端多出来的文件。这个参数要小心，它会让目标端和源端完全一致。这一轮我加了，因为新机器上什么都没有。但如果目标端有东西你不想要它删，就得去掉。

--exclude 排除日志和缓存。日志没必要同步，新机器会自己产生。

-e "ssh -p 2222" 是因为我把 SSH 端口改成了 2222。默认的话不用写。

先来一轮全量

第一次同步要把三十多个 G 传过去，按我那台机器的带宽，大概跑了四十分钟。

time rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

跑的时候建议用 tmux 或者 screen 挂着，万一 SSH 断了，rsync 会中断。虽然可以用 --partial 续传，但重跑一次也不费事。

实际上我建议加上 --partial 和 --progress：

1
2

rsync -avzHAX --numeric-ids --delete --partial --progress \
  ...

--partial 保留中断的临时文件，下次同步可以续。--progress 显示每个文件的进度和总进度。

再补一轮增量

全量跑完之后，老机器上的数据还在变，数据库在写，日志在滚。所以要再跑一次增量。

这一轮会快很多，因为 rsync 的算法只传变化的部分。

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

这一轮跑了六分钟。

数据库怎么办

直接 rsync 数据库的数据文件是不行的，因为文件在写入的过程中，你复制出来的可能是不一致的。

有两种做法。

一种是在迁移窗口里停掉数据库，然后 rsync 一次。这样最安全，但会有停机。

另一种是用 mariadb-dump 导出，然后在新机器上导入。这个不需要停库，但导入的时间取决于数据量。

我的库不大，不到两个 G，选了导出导入这条。

1
2

mariadb-dump --all-databases --single-transaction --routines --triggers \
  -u root -p > /tmp/all-db.sql

然后在老机器上直接通过 ssh 管道到新机器：

`1`	`cat /tmp/all-db.sql \| ssh -p 2222 deploy@new-host "mariadb -u root -p"`

或者先传文件再导入，看你的网络情况。

--single-transaction 保证导出的是一致性快照。前提是表都是 InnoDB，如果有 MyISAM 就得锁表。

权限和属主

同步完之后，检查一下属主对不对。

`1`	`ssh deploy@new-host "ls -ln /srv/www"`

-n 是显示数字 ID 而不是名字。如果显示的是 1000 1000 而不是 deploy deploy，说明 uid 对不上。

这种情况用 --numeric-ids 之后会发生，因为新机器上的 deploy 用户可能是 1001。

解决办法有两个。一是把新机器上的 deploy 改成和老机器一样的 uid，二是同步完之后统一 chown。

我选了统一 chown，因为改 uid 可能影响其他已经存在的文件。

`1`	`ssh deploy@new-host "sudo chown -R deploy:deploy /srv/www /srv/git"`

nginx 要读的文件，组设成 www-data：

`1`	`ssh deploy@new-host "sudo chgrp -R www-data /srv/www && sudo chmod -R g+rX /srv/www"`

chmod g+rX 里的大写 X 有特殊含义，它只给目录和已经有执行位的文件加执行权限。用小写 x 会给所有文件都加上执行位，那就不对了。

服务配置

把老机器上的配置文件同步过来，然后逐项改。

`1`	`rsync -avz -e "ssh -p 2222" /etc/nginx/ deploy@new-host:/tmp/nginx-config/`

先放到临时目录，人工看一遍再放到 /etc/nginx。直接覆盖有风险，因为两台机器的环境可能不一样。

重点检查这几处。

server_name 里的域名。这个不用改，因为 DNS 还没切。

proxy_pass 里的地址。如果老机器上是 127.0.0.1:8080，新机器上也是，那就没问题。但如果涉及容器名或者别的机器，要核对。

SSL 证书的路径。证书文件也要同步过去。

数据库的连接配置。新机器的密码可能不一样。

切换

前面几步做完，新机器上应该已经能通过 IP 访问了。先用 hosts 文件绑定测试：

1
2

# 本地 /etc/hosts
1.2.3.4  blog.mibase.top

浏览器访问，确认页面正常、样式正常、数据库有数据、图片能加载。

确认没问题之后，进入切换窗口。

先停掉老机器上的写入。把 nginx 停掉，让所有请求失败，这样就不会有新数据产生。

`1`	`ssh old-host "sudo systemctl stop nginx"`

然后最后一次增量同步，这次加上数据库：

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

再导出一次数据库，导入新机器。

然后改 DNS。把 A 记录指向新 IP。

DNS 生效需要时间，取决于 TTL。我提前一天把 TTL 从 3600 改成了 300，这样切换的时候五分钟就能生效。

DNS 切换的过程中，有一部分用户还在访问老机器，有一部分到了新机器。这段时间老机器的 nginx 是停的，所以那部分用户会看到错误页。这是不可避免的，只能尽量缩短窗口。

回滚的预案

切换之前，我把老机器的 nginx 配置备份了，也记下了怎么恢复。

如果新机器有问题，回滚就是把 DNS 改回去，然后启动老机器的 nginx。

`1`	`ssh old-host "sudo systemctl start nginx"`

因为老机器的数据只是停止更新了几个小时，没有删除，所以回滚是无损的。

这个预案让我在切换的时候心里有底。知道能退回去，才敢往前走。

切换之后

DNS 生效之后，观察了两天。

`1`	`tail -f /var/log/nginx/access.log`

看有没有异常的状态码。看数据库的连接数。看磁盘的使用情况。

有几个小问题。

一个是时区。新机器默认是 UTC，日志时间对不上。改成 Asia/Shanghai：

`1`	`sudo timedatectl set-timezone Asia/Shanghai`

一个是 Docker 的存储路径。新机器默认在 /var/lib/docker，我改到了 /srv/docker，因为 /srv 那块盘更大。

sudo systemctl stop docker
sudo mkdir -p /srv/docker
sudo rsync -aHAX /var/lib/docker/ /srv/docker/
sudo tee /etc/docker/daemon.json <<'EOF'
{
  "data-root": "/srv/docker"
}
EOF
sudo systemctl start docker

还有一个是防火墙。老机器上用的是 iptables 的直接规则，新机器我换成了 ufw，规则要重写一遍。

老机器的处理

确认新机器稳定之后，老机器不要立刻退。

我保留了两周。这两周里如果发现有什么东西忘了迁，还能上去找。

两周之后，把老机器上的数据打包下载到本地，然后才退掉。

`1`	`ssh old-host "sudo tar -czf - /srv" > old-srv-backup.tar.gz`

这个备份我留了三个月，确认没用了才删。

一点总结

整个迁移从准备到完成，花了大概一周，其中真正的切换窗口只有半小时。

花时间最多的是准备阶段。盘点、装环境、同步数据、验证配置，这些都是一步一步来的，每一步做完都能停下来检查。

我觉得迁移这件事，最重要的不是技术，是心态。不要想着一次搞定，把它拆成能验证的小步骤，每一步都有回滚的方案。

还有一点，永远不要在周五下午做这种事。

1G 内存的小机器跑 MariaDB，我把能省的都省了

Thu, 03 Apr 2025 04:28:00 +0800

手里有台很便宜的 VPS，1 核 1G，一年一百多块。上面跑着一个小论坛，用户不多，但数据库不能少。

装完 MariaDB 之后，我 free -h 看了一眼，可用内存只剩三百多兆。系统自己占了点，MariaDB 占了将近五百兆。

当时没太在意，觉得还能跑。结果第三天凌晨，机器挂了。

先看是怎么死的

`1`	`journalctl -k --since "yesterday" \| grep -i 'out of memory'`

`1`	`Out of memory: Killed process 812 (mariadbd) total-vm:1024000kB, anon-rss:520000kB`

OOM killer 干的。MariaDB 吃到 520M，加上系统的，超过物理内存，内核直接把它杀了。

有意思的是，杀完之后 systemd 又把它拉起来，然后继续涨，第二天再杀一次。这就是为什么我早上起来发现论坛打不开，但服务状态显示 running。

内存都花在哪儿了

MariaDB 的内存占用分几块，得先搞清楚再动手。

`1`	`SHOW ENGINE INNODB STATUS\G`

输出里的 BUFFER POOL AND MEMORY 那一段，能看到 buffer pool 的实际大小。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'innodb_log_buffer_size';
SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
SHOW VARIABLES LIKE 'sort_buffer_size';
SHOW VARIABLES LIKE 'join_buffer_size';
SHOW VARIABLES LIKE 'read_buffer_size';
SHOW VARIABLES LIKE 'read_rnd_buffer_size';

我查出来的默认值是这样的：

innodb_buffer_pool_size    134217728    (128M)
innodb_log_buffer_size     16777216     (16M)
max_connections            151
tmp_table_size             16777216     (16M)
max_heap_table_size        16777216     (16M)
sort_buffer_size           2097152      (2M)
join_buffer_size           262144       (256K)
read_buffer_size           131072       (128K)
read_rnd_buffer_size       262144       (256K)

看着每一项都不大，但问题是，sort_buffer_size、join_buffer_size 这些是每个连接独占的。151 个连接乘上 2M 的 sort buffer，理论上就是 300M。虽然实际不会所有连接都用到满，但这个乘数关系很吓人。

改配置

MariaDB 的配置我放在 /etc/mysql/mariadb.conf.d/99-small.cnf，这样不会被升级覆盖。

[mysqld]
# 内存相关的核心参数
innodb_buffer_pool_size = 64M
innodb_log_buffer_size = 8M
innodb_buffer_pool_instances = 1

# 连接数
max_connections = 30
max_user_connections = 25
thread_cache_size = 4
table_open_cache = 64
table_definition_cache = 256

# 每个连接的缓冲区，越小越好
sort_buffer_size = 256K
join_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 256K
tmp_table_size = 16M
max_heap_table_size = 16M

# 日志和刷盘
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 32M

# 关掉用不到的功能
performance_schema = OFF
innodb_stats_on_metadata = OFF

一条条说。

innodb_buffer_pool_size 是最大的一块。它是 InnoDB 的缓存池，索引和数据页都放里面。默认 128M 对 1G 的机器太大了，我改成 64M。这个值的经验法则是物理内存的百分之五十到七十，但在小内存机器上，得先保证系统和其他服务能活。

innodb_buffer_pool_instances 默认会按 buffer pool 大小自动分，分成多个实例能减少锁竞争。但在 64M 这个量级，分成多个反而浪费，因为每个实例有自己的最小页数。设成 1 就行。

max_connections 从 151 降到 30。这个小论坛日常在线不到十个人，三十个连接足够。这个改动省下的不是连接本身，而是每个连接的缓冲区乘数。

thread_cache_size 是缓存的线程数。连接断开之后线程不立刻销毁，留着给下一个连接用。设成 4 意味着常驻四个空闲线程，占的内存不多，但能减少频繁创建销毁的开销。

performance_schema 这个功能是用来做性能分析的，很强大，但默认开着会占不少内存，大概几十兆。小站用不上，关掉。

innodb_flush_log_at_trx_commit = 2 这个要谨慎。它控制事务提交时怎么刷日志。

设成 1 是最安全的，每次提交都刷盘，保证不丢数据。设成 2 是每秒刷一次，性能好很多，但极端情况下可能丢一秒的数据。设成 0 是交给操作系统，最不安全。

小论坛丢一秒的数据可以接受，我选了 2。如果你的业务涉及钱，别改这个。

innodb_flush_method = O_DIRECT 让 InnoDB 绕过操作系统的页缓存，直接写磁盘。这样同一份数据不会在内存里存两遍。小内存机器上这个能省下可观的空间。

重启之后看效果

1
2

sudo systemctl restart mariadb
free -h

改完 MariaDB 占了 180M 左右，比之前的 520M 小了一大截。

再看一下实际的 buffer pool：

1
2
3

SELECT
  POOL_SIZE * 16 / 1024 / 1024 AS buffer_pool_mb
FROM information_schema.INNODB_BUFFER_POOL_STATS;

确认是 64M。

一个更细的观察方法

free -h 只能看到整体，想看每个进程实际用了多少：

`1`	`ps -eo pid,comm,rss,vsz --sort=-rss \| head -10`

rss 是实际占用的物理内存，vsz 是虚拟内存。看 rss 才有意义，vsz 包含了大量没有真正分配的地址空间。

还可以看 MariaDB 自己的内存统计：

1
2

SHOW STATUS LIKE 'Innodb_buffer_pool_bytes_data';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';

pages_free 如果一直是 0，说明 buffer pool 不够用，可以适当调大。如果有一半以上是空闲的，说明给多了。

我观察了一周，pages_free 稳定在 40% 左右，说明 64M 是合适的。

swap 要不要开

这个问题争论很多。

我的看法是，小内存机器一定要开一点。不是因为 swap 能提升性能，而是因为它能在内存尖峰的时候给你一个缓冲，避免进程被直接杀掉。

我配了 1G 的 swap：

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

然后调一下 swap 的使用倾向：

`1`	`sudo sysctl vm.swappiness=10`

默认是 60，意思是内存还有富余的时候就开始往 swap 里挪。设成 10 让它尽量先用物理内存，真的不够了才用 swap。

这个值我写在 /etc/sysctl.d/99-swap.conf 里，重启也生效。

不过要提醒一句，如果你的 VPS 用的是机械盘或者网络存储，swap 的性能会很差，用到 swap 的时候整个系统会卡住。这种情况得权衡。

慢查询日志

内存调小了，可能会有些查询变慢，因为 buffer pool 小了，缓存命中率下降。

开个慢查询日志观察：

1
2
3

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

跑一周，看看有没有超过两秒的查询。有的话，先优化 SQL，加索引，比加内存便宜。

我那台机器上确实发现了两条，一条是论坛的帖子列表，没走索引，全表扫描。加了复合索引之后，从三秒降到几十毫秒。

这个收益比调参数大得多。

还有一个坑：临时表

tmp_table_size 和 max_heap_table_size 这两个值要设成一样。

原因是有个隐藏的行为。内存临时表的大小受这两个值里较小的那个限制。如果不一样，实际生效的是小的那个，你改大的那个没用。

我一开始只改了 tmp_table_size，改成 64M，结果发现没效果，因为 max_heap_table_size 还是 16M。

另外，临时表超过这个大小之后，会转成磁盘临时表。磁盘临时表慢很多，但至少不会把内存撑爆。所以这两个值别设太大，16M 到 32M 就够了。

长期观察

调完到现在跑了三个多月，没再被 OOM 杀过。

free -h

现在的样子：

1
2
3

               total        used        free      shared  buff/cache   available
Mem:           979Mi       412Mi       102Mi       8.0Mi       464Mi       512Mi
Swap:          1.0Gi        12Mi       1.0Gi

MariaDB 稳定在 180M 左右，swap 只用了 12M，基本没动。

available 有 512M，说明还有余量。这个指标比 free 更有参考价值，因为它把可回收的缓存也算进去了。

一点心得

小内存机器上跑数据库，核心思路是"知道自己需要多少，然后只给这么多"。

默认配置是为通用场景设计的，它假设你有足够的内存。在 1G 的机器上，这些默认值就是灾难。

调参的顺序应该是，先降 max_connections，因为它带来的乘数效应最大；再降 innodb_buffer_pool_size，这是单项最大的一块；最后调各种 per-connection 的缓冲区。

调完之后别急着走，观察几天，看 buffer pool 的命中率和 free 页面数，再微调。

还有一点，如果你的库真的很小，比如就几兆数据，那其实可以考虑 SQLite。省掉整个数据库进程，内存占用直接降到几兆。我这个论坛是因为要用全文检索和并发写，才留着 MariaDB。

凌晨两点收到 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，这几层的关系搞清楚之后，很多类似的问题都能举一反三。

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

根分区用到 92% 那天，我把 LVM 扩容的流程走了一遍

Sun, 12 Jan 2025 07:26:00 +0800

上个月收到监控告警，说根分区使用率 92%。

登录上去 df -h 一看，四十个 G 的盘只剩三个多 G。du -sh /* 挨个看，/var/lib/docker 占了大头，还有一堆构建缓存。

清了一轮，回到 60%。但我知道这只是暂时的，服务还在长，早晚得扩。

还好当初装系统的时候选了 LVM。要是普通分区，扩容就得停机、进救援模式、用 fdisk 调分区，风险大得多。

先理清楚 LVM 的三层

很多人被 LVM 绕晕，是因为它的名字太多。其实就三层。

物理层是 PV，Physical Volume，一块硬盘或者一个分区，初始化之后交给 LVM 管。

中间层是 VG，Volume Group，一个池子，把多个 PV 合成一个大的存储空间。

上层是 LV，Logical Volume，从池子里划出来的一块，格式化之后挂载使用。

扩容的时候，顺序是从下往上。先让 PV 变大，VG 才会跟着变大，然后才能扩 LV，最后扩文件系统。

搞反了就白做。

看现在的状态

lsblk

输出大概是这样：

NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda             254:0    0   40G  0 disk
├─vda1          254:1    0    1M  0 part
├─vda2          254:2    0  512M  0 part /boot/efi
└─vda3          254:3    0 39.5G  0 part
  ├─vg0-root    253:0    0   20G  0 lvm  /
  ├─vg0-swap    253:1    0    2G  0 lvm  [SWAP]
  └─vg0-data    253:2    0 17.5G  0 lvm  /data

这块盘 40G，vda3 是 LVM 的物理分区，占了 39.5G。里面划了三个 LV。

问题是我这块盘本来就只有 40G，没有剩余空间。所以要扩，得先给虚拟机加盘。

加盘

在云控制台或者虚拟化平台里，把磁盘从 40G 调到 80G。这一步在云厂商那边点一下就行，不用停机。

加完之后，虚拟机里 lsblk 还是显示 40G，因为内核还没重新读分区表。

1
2

lsblk
# vda 显示 80G，但 vda3 还是 39.5G

这就是关键的一步。vda 本身变大了，但 vda3 这个分区没变。

扩分区

有两种情况。

如果你用的是 GPT 分区表，而且分区后面没有别的分区，用 growpart 最省事：

`1`	`sudo growpart /dev/vda 3`

growpart 是 cloud-utils-growpart 包里的工具，大部分云镜像都预装了。

如果没装，apt install cloud-utils-growpart 或者 yum install cloud-utils-growpart。

跑完再看：

lsblk

vda3 应该变成 79.5G 了。

如果是 MBR 分区表，growpart 也能处理，但有个限制，主分区最多四个，而且扩展分区后面的空间不好扩。这种情况下得用 fdisk 删了重建分区，fdisk 的 d 删分区只删分区表项，不动数据，只要起始扇区没变就是安全的。不过操作的时候手要稳。

让 PV 认识新的大小

分区变大了，但 LVM 还不知道。因为 PV 里记录了自己的大小。

`1`	`sudo pvresize /dev/vda3`

这个命令会让 PV 重新读取分区的大小，然后更新自己的元数据。

验证：

`1`	`sudo pvs`

输出里的 PSize 应该变成 79.5G，PFree 是新增的空间。

如果 PFree 没变，说明 pvresize 没生效，回头检查分区是不是真的扩了。

扩 LV

`1`	`sudo lvs`

看当前的 LV 大小。

扩的时候有两种写法。

按绝对值扩到某个大小：

`1`	`sudo lvextend -L 40G /dev/vg0/root`

注意 -L 是最终大小，不是增量。如果你写 -L 40G 而当前已经是 40G，它什么都不会做。

按增量扩：

`1`	`sudo lvextend -L +20G /dev/vg0/root`

这个更直观，加二十个 G。

或者干脆把池子里的空间全用掉：

`1`	`sudo lvextend -l +100%FREE /dev/vg0/root`

注意这里是小写的 -l，后面跟百分比。大写的 -L 后面跟具体数值。这个大小写很容易看错。

扩文件系统

这一步最容易被忘。LV 变大了，但上面的文件系统还是原来的大小，df -h 看不出变化。

ext4 用：

`1`	`sudo resize2fs /dev/vg0/root`

不用给大小，它会自动扩到 LV 的边界。

xfs 用：

`1`	`sudo xfs_growfs /`

注意 xfs 的 xfs_growfs 参数是挂载点，不是设备名。写 /dev/vg0/root 会报错。

这是两个文件系统最明显的区别。ext4 可以缩，xfs 只能扩。所以如果你的盘用 xfs，规划的时候要留点余量，缩不回去。

在线扩容

好消息是，上面这些操作除了 growpart 之外，全都可以在线做，不用卸载不用停机。

ext4 从内核 3.6 开始支持在线扩容，resize2fs 会自动检测并走在线模式。xfs 一直是在线的。

我用的是 ext4，整个流程在跑着服务的机器上做完，中间没有中断。nginx 和数据库都没感觉。

不过还是建议在业务低峰做。虽然理论上是安全的，但万一 growpart 把分区表写坏了，那就是大事故。

一次完整的操作

把上面的命令串起来，加上 df 前后的对比：

# 扩容前
df -h /

# 分区扩容
sudo growpart /dev/vda 3

# PV 重新读取
sudo pvresize /dev/vda3

# LV 扩容
sudo lvextend -l +100%FREE /dev/vg0/root

# 文件系统扩容
sudo resize2fs /dev/vg0/root

# 验证
df -h /

我实际跑的时候，每一步之间都 lsblk 或 pvs 确认一下。多敲几条命令，比出问题再回头找强。

几个坑

growpart 之后忘了 pvresize，这是最常见的。pvs 里 PFree 是 0，你就会以为是分区没扩成功，其实只是 LVM 不知道。

lvextend 用了 -L 但写的是增量值，比如 -L 20G 而当前已经是 20G，它什么都不做，也不报错。

xfs 用 resize2fs 会直接报错说不支持，别慌，换 xfs_growfs。

还有一个，如果你的 /boot 在 LVM 上，扩它是可以的，但 grub 那边可能需要重新生成配置。我这个机器的 /boot 是独立分区，没在 LVM 里，所以没遇到。

缩容的注意事项

扩容易，缩难。

ext4 缩容要三步。先 umount，然后 e2fsck -f 检查，再 resize2fs <设备> <目标大小>，最后 lvreduce。

顺序不能反。先缩文件系统再缩 LV。如果先缩 LV，文件系统就损坏了，数据基本找不回来。

xfs 根本不支持缩容。要用 xfs 又想缩，只能备份、重建、恢复。

所以我的建议是，宁可一开始规划得保守一点，也不要给自己留缩容的活。

磁盘规划的一点经验

装系统的时候我习惯这么分：

/boot 给 512M，独立分区，不在 LVM 里。这是为了让 grub 和系统救援都能正常工作。

swap 给内存的一到两倍，但不超过 4G。现在很多云厂商建议不给 swap，我的看法是留一点，防止突发的内存尖峰直接把进程打死。

/ 给剩下的全部。不用单独分 /var 和 /home，因为 LVM 的好处就是可以动态调，一开始分太细反而失去了灵活性。

这样分下来，如果哪天 /var/lib/docker 涨得太快，我直接扩根分区就行，不用去动别的。

现在的状态

扩到 80G 之后，根分区用了 38%，/data 那边还有空间。跑了一个多月，稳定。

顺手做了两件事。一是给 docker 加了 data-root 的迁移，把镜像目录挪到了 /data 下面，这样系统盘的压力小很多。二是加了个监控，磁盘到 85% 就推消息，不用等到 92% 才被叫醒。

LVM 这个东西，平时感觉不到它的存在，真正需要的时候才发现它的好。当初装系统多勾了一个选项，省了今天一晚上的事。

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`

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

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

两个容器明明在同一个宿主机上，就是互相连不上

Mon, 29 Jul 2024 02:54:00 +0800

有段时间我在搭一个小的内部工具，前端是一个 PHP 的容器，后端是一个 Redis 容器。两个都在同一台机器上，端口也都正常开着。

但 PHP 那边一连 Redis 就报错，Connection refused，或者更奇怪一点，php_network_getaddresses: getaddrinfo failed。

我当时的第一反应是，两个容器不是都在 172.17.0.x 这个网段吗，怎么可能连不上。

这个想法本身就是错的。花了小半个晚上才想明白问题出在哪，记一下。

先看清楚默认的 bridge 网络

我当时的启动命令大概是这样的：

1
2

docker run -d --name redis redis:7
docker run -d --name web -p 8080:80 php:8.2-apache

两条命令都没指定 --network，所以它们都跑在默认的 bridge 网络上。

docker network inspect bridge 看一眼：

`1`	`docker network inspect bridge --format '{{json .Containers}}' \| jq`

两个容器确实都在里面，IP 分别是 172.17.0.2 和 172.17.0.3。

那我先进 web 容器里试一下：

1
2

docker exec -it web bash
ping 172.17.0.3

通。说明二层是通的，两个容器确实能互相访问。

`1`	`ping redis`

ping: bad address 'redis'

到这里问题就很清楚了。IP 能通，名字解析不了。

默认 bridge 没有内置 DNS

这是 Docker 里一个非常容易踩的点。

在默认的 bridge 网络上，Docker 是不提供自动服务发现的。容器之间只能通过 IP 通信，不能通过容器名。你想让 redis 这个名字能解析，得自己用 --link，而这个参数早就被标记成废弃了，官方文档里明确说不建议用。

那为什么我印象里"容器名可以互相访问"呢。

因为自定义网络可以。

只要你自己建一个 bridge 网络，Docker 就会给它启用一个内置的 DNS 服务器，所有接入这个网络的容器都会自动注册自己的名字。之后容器之间直接 ping 服务名 就能通。

这就是关键区别。默认 bridge 是个历史包袱，为了兼容早期的行为，它没开这个功能。

改成自定义网络

1
2
3

docker network create appnet
docker run -d --name redis --network appnet redis:7
docker run -d --name web --network appnet -p 8080:80 php:8.2-apache

再进 web 容器：

`1`	`docker exec -it web bash -c "getent hosts redis"`

这次输出 172.18.0.2 redis，解析成功了。

不过这里还有个细节。ping 在 php:8.2-apache 这个镜像里可能没装，getent hosts 更通用一些。curl、nc 这些也未必有，排查的时候先确认工具在不在。

内置 DNS 是怎么回事

Docker 在每个自定义网络的容器里塞了一个 127.0.0.11 的 DNS 服务器。你可以看一下容器里的 /etc/resolv.conf：

`1`	`docker exec web cat /etc/resolv.conf`

输出大概是：

1
2

nameserver 127.0.0.11
options ndots:0

这个 127.0.0.11 是 Docker 的 embedded DNS。它拦截容器内的所有 DNS 查询，先查自己维护的一张表，也就是同一网络里其他容器的名字。查不到再转发给宿主机的 DNS 或者你在 daemon.json 里配的上游。

ndots:0 这个选项也有讲究。它决定了域名里有多少个点才被当成绝对域名。设成 0 意味着任何带点的名字都先当绝对域名查，不做 search domain 的拼接。这个值能减少很多无谓的查询延迟。

那我当初为什么连 IP 也失败过

前面说 IP 能 ping 通，但那是后来验证的。我最初遇到的报错是 Connection refused，这个和 DNS 没关系，是另一个问题。

Redis 的镜像默认只监听 127.0.0.1。这是从 Redis 3.2 开始的默认行为，官方镜像也继承了这个配置。也就是说，就算你从外面连得上这个容器的 IP，Redis 本身也只接受本机回环的连接。

解决办法是启动的时候覆盖掉：

`1`	`docker run -d --name redis --network appnet redis:7 redis-server --bind 0.0.0.0`

或者用配置文件：

1
2
3

docker run -d --name redis --network appnet \
  -v ./redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7 redis-server /usr/local/etc/redis/redis.conf

配置文件里写 bind 0.0.0.0，再配一个 requirepass，因为一旦绑到 0.0.0.0，同网络里任何容器都能连，得有个密码。

这里顺便说一句，bind 0.0.0.0 不等于把 Redis 暴露到公网。只要你没做端口映射，外面还是进不来，只有同一 Docker 网络里的容器能访问。这个边界很容易搞混。

名字里的下划线和连字符

还有一次，我在 Compose 里把服务名写成了 my_redis，然后在应用配置里写 my_redis，死活解析不了。

查了半天，是 Docker 的 DNS 对下划线的处理有点特殊。容器名里带下划线的时候，有些客户端库在做解析的时候会失败，因为下划线在主机名规范里本来就不是合法字符。

把服务名改成 my-redis，问题立刻消失。

所以我的建议是，容器名和服务名只用小写字母、数字和连字符。别用下划线，也别用大写。这个约定能省掉很多莫名其妙的解析失败。

Compose 里的网络行为

Compose 比裸 docker run 好一些，它会自动为每个项目建一个网络，项目内的服务默认都接进去，名字自动能解析。

但有几个地方还是会踩。

一个是跨项目。项目 A 的容器想连项目 B 的容器，默认是连不上的，因为它们在两个不同的网络里。得建一个外部网络，两边都声明 external: true 接进去。

另一个是 container_name 和 services 键的区别。如果你设了 container_name: redis，那这个容器在网络里的别名就是 redis。如果你没设，Compose 生成的容器名是 项目名-redis-1，但它在网络里的别名同时包含 redis 和 项目名-redis-1。所以在同一个 Compose 项目里，写服务名总是能通的。

这个行为在扩容的时候会变。docker compose up --scale web=3 之后，三个 web 容器会共享 web 这个别名，DNS 返回的是一组 IP，客户端连到哪个不确定。这时候做负载均衡是它自带的，不需要额外配置。

一个特别隐蔽的坑：网络别名冲突

我有一次把两个不同的项目都接到了同一个外部网络里，然后两边都有一个叫 db 的服务。

结果就是 DNS 返回两个 IP，客户端随机连，有时候连到 A 的数据库，有时候连到 B 的。数据错乱了一整天才发现。

解决办法是给服务加显式的网络别名：

services:
  db:
    networks:
      shared:
        aliases:
          - projectA-db

然后应用里就写 projectA-db。这样不会撞。

或者干脆别共用网络，用不同的网络隔离。这个我后来更倾向，隔离得越清楚，出问题的概率越小。

排查顺序

踩过这几次之后，我形成了一个固定的检查顺序。

先看容器在不在同一个网络：

1
2

docker inspect web --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'
docker inspect redis --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'

两个输出里得有至少一个共同的网络名。

再看容器里的 DNS 配置：

`1`	`docker exec web cat /etc/resolv.conf`

得看到 127.0.0.11。

再试解析：

`1`	`docker exec web getent hosts redis`

能解析出 IP 说明名字这块没问题了。

最后测连通性：

`1`	`docker exec web nc -zv redis 6379`

到这一步还不行，那就是服务本身没监听对地址，或者有防火墙规则。

这套顺序跑一遍，基本五分钟内能定位。

现在的习惯

我现在新起一个服务，一律先建自定义网络，绝不往默认 bridge 里塞东西。

Compose 的话，我习惯显式写一个 networks 段，哪怕只是默认的那个。写出来心里有数，不用去猜它自动生成了什么名字。

还有个小习惯，我在容器里排查的时候，如果发现 ping、curl、nc 都没有，会临时起一个 nicolaka/netshoot 容器接到同一个网络上：

`1`	`docker run -it --rm --network appnet nicolaka/netshoot`

这个镜像里工具很全，dig、tcpdump、curl、nc 什么都有。比自己往业务镜像里装工具干净得多。

这类网络问题，说穿了就是"默认配置不是你以为的那个"。默认 bridge 没有 DNS，Redis 默认只听回环，容器名别带下划线，这三件事记住了，能省掉一大半的排查时间。

20G 的硬盘被 Docker 吃干净了，我把清理这件事理顺了

Wed, 22 May 2024 10:46:00 +0800

那天早上是被监控机器人的 Telegram 消息震醒的。

[WARN] rootfs usage 92%，我那台 20G 硬盘的小机器。前一天晚上看还是 78%，一夜之间涨了十几个点。

登上去 df -h 一看，/ 确实快满了。但奇怪的是，du -sh /var/lib/docker 只有 9 个多 G，和我印象里的数字差不多。真正占地方的东西藏在哪儿了。

这次排查让我把 Docker 的磁盘占用彻底搞清楚了一遍，记下来。

先搞清楚它到底占了多少

`1`	`docker system df -v`

这个命令比 docker system df 详细得多，它会把镜像、容器、本地卷、构建缓存四类分开列，每一类还列出具体的条目和大小。

我第一次跑出来的结果是这样的：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          42        9         18.6GB    13.2GB (71%)
Containers      11        8         210MB     180MB (85%)
Local Volumes   17        6         3.1GB     1.4GB (45%)
Build Cache     88        0         2.4GB     2.4GB

十八个 G 的镜像，只有九个是活跃的。这就是问题所在。

我这两年在同一台机器上试过太多东西，什么 GitLab、Drone、MinIO、各种数据库版本，装完觉得不好用就 docker compose down 了，容器没了，镜像还躺在那儿。每个都几百兆，攒起来就是十几个 G。

镜像怎么清

最直接的是清掉那些没有标签的悬空镜像：

`1`	`docker image prune`

它只会删掉 <none>:<none> 那种，也就是构建过程中产生的中间层，或者被新版本顶掉标签的旧镜像。这个操作是安全的，因为没有任何容器在用它们。

如果想连"有标签但没有容器使用"的一起删：

`1`	`docker image prune -a`

这个就要小心了。它会问你确认，确认之后把所有没被容器引用的镜像全删掉。我当时脑子一热跑了这个，结果把我准备好的 mariadb:10.11 也删了。虽然能重新拉，但那台机器的网络拉大镜像很慢，花了十几分钟。

后来我的做法是先看清单再决定：

`1`	`docker image ls --filter "dangling=false" --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}\t{{.CreatedSince}}"`

按创建时间排序，心里有个数，再挑着删。

单个删：

`1`	`docker image rm <IMAGE_ID>`

如果提示被容器引用，先看是哪个容器：

`1`	`docker ps -a --filter ancestor=<IMAGE_ID>`

容器和它的可写层

docker ps -a 里那些 Exited 状态的容器，很多人以为删了容器就干净了，其实容器本身的可写层也占空间。

`1`	`docker container prune`

这个只删已停止的容器。有几点要提醒。

容器删了，它的可写层就没了。如果你在容器里手动改过什么文件、装过什么包，没写进镜像也没挂载出来，那部分就彻底丢了。我之前有个容器，为了图省事直接在里面 apt install 了个工具，后来 prune 一跑，第二天发现功能没了，又得重来一遍。

所以正确做法是，要么写进 Dockerfile，要么挂载出来，别指望容器的可写层能长期保存东西。

数据卷是最需要小心的一类

`1`	`docker volume prune`

这个命令删的是"没有被任何容器引用"的卷。听起来很安全，实际上有个陷阱。

我那次跑完之后，发现一个早就停掉的测试容器的数据卷被删了。虽然那个容器本来也没用了，但里面存着我早期的一些实验数据。删掉之后想找回来是不可能了。

所以我的建议是，跑之前先列出来看看：

`1`	`docker volume ls --filter "dangling=true"`

确认这些名字你都不认识、也不想要，再执行 prune。

更稳的做法是一个一个删：

`1`	`docker volume rm <VOLUME_NAME>`

麻烦，但至少你知道自己删了什么。

还有一种情况要注意。如果卷的名字是 Compose 自动生成的（形如 项目名_卷名），你 docker compose down 的时候不加 -v，卷是会保留的。加了 -v 就会连卷一起删。这个 -v 我在文档里看到过好几次，但真正记住是在一次误操作之后。

构建缓存：最容易被忽略的大头

这个是我这次排查才发现的大户。

`1`	`docker builder prune`

它会删掉 BuildKit 的缓存。现在的 Docker 默认用 BuildKit，每次 docker build 都会把中间层缓存下来，下次构建能复用。这个机制很好，但缓存不会自己过期，越攒越多。

我那次看到 2.4G，基本上都是几个月前折腾某个项目留下的。

想连所有缓存一起清：

`1`	`docker builder prune -a`

-a 是 all，包括那些还在被引用的缓存。清完之后下次构建会慢一些，但空间能立刻回来。

还有个带时间过滤的用法，我觉得挺实用：

`1`	`docker builder prune --filter "until=168h"`

只删七天以前的。这样常用的缓存还能留着，老的自然淘汰。

一键清理，以及为什么我不推荐

网上到处都写着这条：

`1`	`docker system prune -a --volumes`

它会把停止的容器、没用的网络、所有没被引用的镜像、所有没被引用的卷、所有构建缓存，一次性全清掉。

确实爽，我那次跑完从 92% 降到了 51%。

但我不推荐把它当成日常操作。原因有三个。

它不问你就删卷。数据卷里可能有你还没意识到重要的东西。

它把镜像全清了。下次起服务要重新拉，如果网络不好，等于给自己挖坑。

它不区分环境。你在开发机上跑和在跑着线上服务的机器上跑，风险完全不一样。我有一次在生产机上顺手跑了，把一个还没启动但准备切换的旧版本镜像删了，回滚的时候抓瞎。

我现在的固定动作

经过这次，我给自己定了一套流程，每个月做一次。

先看占用：

`1`	`docker system df -v`

然后按风险从低到高依次清：

1
2
3

docker container prune -f
docker image prune -f
docker builder prune -f --filter "until=336h"

这三条都是只删"明确没用"的东西，相对安全。卷我单独处理，先 docker volume ls --filter dangling=true 看清单，确认了再手动删。

再加上一条，给日志设上限。这个比清理更治本。Docker 默认的 json-file 驱动不限制大小，一个话多的服务能写到几个 G。我在每个 compose 文件里都加了：

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

这样单个容器最多占 30M 日志，怎么跑都撑不爆。

顺手发现的一个问题

清理的时候我注意到 /var/log 下面也有几个 G。是 journald 的日志，默认能占到磁盘的 10%。

`1`	`journalctl --disk-usage`

看到是 1.8G。我改了 /etc/systemd/journald.conf：

`1`	`SystemMaxUse=200M`

然后 systemctl restart systemd-journald，空间立刻回来了。

这个问题和 Docker 没关系，但它们是同一类问题，都是"某个东西默认不限制自己，跑久了就把盘吃满"。清理只是补救，设上限才是根治。

现在的状态

清完之后稳定在 55% 左右，跑了两个月没再告警。

我也顺手在监控里加了一条，磁盘超过 80% 就推消息。这次是被 92% 才叫醒的，有点晚。早点知道，处理起来从容得多。

回头看，这件事本身没什么技术含量，真正花时间的是搞清楚哪些能删、哪些不能。Docker 把很多东西藏起来了，system df -v 这个命令就是那把钥匙。知道东西在哪儿，才谈得上管理。