服务基本信息确认

• 目标服务：PostgreSQL（service 名称：postgresql）
• 系统环境：Debian 12（bookworm），systemd
• 实例特征：内部开发环境，已启用 pg_isready 健康检查
• 操作目的：调整 shared_buffers（需要重启生效）
• 重启方式：正常重启（不使用强制/立即模式）
• 多版本/多集群可能性：Debian 使用“版本/集群”布局（如 15/main）。建议先确认实际版本与集群名，以避免误操作。

建议先确认当前存在的集群：

sudo pg_lsclusters

输出示例（请以实际为准）：

Ver Cluster Port Status Owner    Data directory               Log file
15  main    5432 online postgres /var/lib/postgresql/15/main  /var/log/postgresql/postgresql-15-main.log

若输出如上，后续中的 用 15、 用 main、 用 5432。

推荐的重启命令

优先仅重启目标集群，避免影响同机其他集群。

• 重启指定集群（推荐）：

sudo systemctl restart postgresql@<VER>-<CLUSTER>

• 若仅有单一集群，也可重启整体服务（会影响所有集群）：

sudo systemctl restart postgresql

命令参数说明

• systemctl restart：对 systemd 管理的服务执行正常重启。PostgreSQL 的 unit 在 Debian 上会使用“快速（fast）”关停模式，确保尽快但安全地终止现有会话，不使用“立即（immediate）”等高风险模式。
• postgresql@-：systemd 模板单元，仅作用于特定版本与集群（如 postgresql@15-main）。
• 不使用 --force/-f 或立即模式，避免可能的数据一致性风险和连接粗暴中断。

执行步骤详解

1. 确认集群与端口

• 查看集群列表：

  sudo pg_lsclusters
  

• 记录 Ver、Cluster、Port、Data directory。

2. 记录并评估当前 shared_buffers

• 确认连接可用：

  pg_isready -p <PORT>
  

• 记录当前值（用于对比）：

  sudo -u postgres psql -p <PORT> -c "SHOW shared_buffers;"
  

• 评估目标值是否合理（一般不建议超过物理内存的 25% 左右；具体依工作负载而定）。

3. 备份配置文件

sudo cp /etc/postgresql/<VER>/<CLUSTER>/postgresql.conf /etc/postgresql/<VER>/<CLUSTER>/postgresql.conf.bak-$(date +%F_%H%M)

4. 修改 shared_buffers

• 使用安全编辑器：

  sudoedit /etc/postgresql/<VER>/<CLUSTER>/postgresql.conf
  

• 设置示例（按需调整）：

  shared_buffers = 4GB
  

• 保存后继续。

5. 语法/可用性预检查（尽量减少因配置错误导致的停机）

• 获取数据目录（来自 pg_lsclusters）并用 postgres 可执行程序读取配置参数，若配置语法有误会报错：

  sudo -u postgres /usr/lib/postgresql/<VER>/bin/postgres -D /var/lib/postgresql/<VER>/<CLUSTER> -C shared_buffers
  

  预期该命令输出你设置的值（例如 4GB）。如报错请修正配置后再继续。

6. 执行正常重启

• 仅重启目标集群（推荐）：

  sudo systemctl restart postgresql@<VER>-<CLUSTER>
  

• 或重启整体服务（若仅有一个集群）：

  sudo systemctl restart postgresql
  

7. 验证服务状态与就绪性

• 检查单元是否运行：

  systemctl is-active postgresql@<VER>-<CLUSTER>
  

  预期输出：active
• 健康检查：

  pg_isready -p <PORT>
  

  预期输出：accepting connections
• 查看近期日志（若有异常有助定位）：

  sudo journalctl -u postgresql@<VER>-<CLUSTER> -n 50 --no-pager
  

8. 验证配置已生效

sudo -u postgres psql -p <PORT> -c "SHOW shared_buffers;"

确认显示为你配置的新值。

9. 回滚方案（若出现问题）

• 还原备份并再次重启：

  sudo cp /etc/postgresql/<VER>/<CLUSTER>/postgresql.conf.bak-<时间戳> /etc/postgresql/<VER>/<CLUSTER>/postgresql.conf
  sudo systemctl restart postgresql@<VER>-<CLUSTER>
  

预期输出结果

• systemctl is-active：
  • active
• pg_isready：
  • /var/run/postgresql:5432 - accepting connections
• SHOW shared_buffers：
  • 新值（如 4GB）

常见问题处理

• 配置语法错误

  • 现象：journalctl 或单元状态显示 FATAL: configuration file contains errors
  • 处理：检查 postgresql.conf 改动的行是否漏写单位、引号或等号；使用步骤 5 的预检查命令定位；必要时恢复备份并重启。

• 内存不足导致无法分配共享内存

  • 现象：FATAL: could not map anonymous shared memory: Cannot allocate memory
  • 处理：降低 shared_buffers；确认主机可用内存（free -h）；如使用 huge_pages，确保配额充足或将 huge_pages 设为 try/off 再评估。

• 误重启了全部集群

  • 现象：同机其他版本/集群的连接中断
  • 处理：优先使用 postgresql@- 精确单元；在多集群环境中避免使用整体 postgresql 服务重启。

• 端口/套接字不一致

  • 现象：pg_isready/psql 连接失败
  • 处理：以 pg_lsclusters 输出为准使用正确 ；或用 SHOW port; 核对端口；确认 unix_socket_directories 设置。

风险提示和注意事项

• 重启将中断现有连接。请在可维护时段执行，并提前通知相关使用方。
• 调大 shared_buffers 会占用更多物理内存，过大可能导致系统内存压力、OOM 或影响文件系统缓存。建议循序渐进、观察负载。
• 避免使用强制/立即关停模式（immediate），以防事务未能正常结束造成更长的恢复时间。
• 在多集群环境下务必精准指定 postgresql@-，避免误操作影响其他实例。
• 修改配置前务必做好配置文件备份，并使用步骤 5 的方式进行语法与可用性预检查。
• 如存在连接池（如 pgbouncer）或依赖应用，需协调重启窗口并验证端到端连通性与性能指标。

服务基本信息确认

• 目标服务：docker（systemd 单元名：docker.service）
• 系统环境：CentOS 7.9，init 系统为 systemd
• 运行特征：宿主机运行多容器负载；现象为 dockerd 日志堆积导致 docker 管理命令卡住
• 行为预期：尽量优先“有序/温和”重启；在无响应时使用“受控的最后手段”强制终止 dockerd 主进程，但不杀死容器进程

说明：

• 重启 dockerd 不会终止已运行的容器进程（容器进程在各自的 cgroup/scope 中），但在停机窗口内容器的管理操作会不可用。
• 以下步骤从低风险到高强度逐步升级，确保尽量避免对容器造成影响。

推荐的重启命令

# 0) 基本检查（可选但推荐）
df -h / /var /var/log
journalctl -u docker -n 50 --no-pager || true
systemctl status docker -l --no-pager || true

# 1) 温和重启（优先）
# 如命令卡住，可用 timeout 给 systemctl 命令加一个安全超时
timeout 30s systemctl restart docker

# 2) 如果 1) 超时或停止阶段卡住，执行受控的停止 -> 启动
# 2.1 请求正常停止
timeout 30s systemctl stop docker

# 2.2 若仍未退出：仅向 dockerd 主进程发送 SIGTERM（不影响容器）
systemctl kill --kill-who=main -s SIGTERM docker
sleep 5

# 2.3 仍不退出（最后手段）：仅对 dockerd 主进程发送 SIGKILL
systemctl kill --kill-who=main -s SIGKILL docker

# 2.4 清理失败状态并重新拉起
systemctl reset-failed docker
systemctl start docker

# 3) 验证
systemctl is-active docker
systemctl status docker -l --no-pager
# 若 docker CLI 已恢复：
docker info
docker ps --format '{{.ID}} {{.Names}} {{.Status}}' | head -n 20

命令参数说明

• timeout 30s：为 systemctl 命令增加执行超时，避免管理会话被长时间卡死。
• systemctl restart/stop/start：按照 systemd 管理服务的标准流程优雅停止/启动 dockerd。
• systemctl kill --kill-who=main -s SIGTERM：
  • kill：由 systemd 定位并向单元内进程发信号，避免手工找 PID。
  • --kill-who=main：仅作用于主进程（dockerd），不会波及容器进程。
  • -s SIGTERM：请求优雅退出。
• systemctl kill --kill-who=main -s SIGKILL：最后手段的强制终止，仅限 dockerd 主进程。
• systemctl reset-failed：清理服务的失败状态，防止 start 被失败计数限制拦截。
• journalctl -u docker -n 50：查看最近 50 条 dockerd 守护进程日志，辅助判断卡顿原因。
• systemctl status -l：显示完整状态与最近日志，便于排错。

执行步骤详解

1. 准备与环境检查

• 确认磁盘空间充足，尤其是 /var 与 /var/log，避免因日志占满导致 I/O 阻塞。
• 通过 systemctl status 与 journalctl 了解 docker 当前状态与报错。

2. 温和重启

• 执行 systemctl restart docker，若担心卡住，可通过 timeout 包裹。
• 如果成功返回，跳至步骤 5 验证。

3. 受控停止

• 执行 systemctl stop docker，等待默认超时（或用 timeout 限制时长）。
• 若停不下，先发送 SIGTERM 到主进程（不伤及容器），再等待 5 秒。
• 仍不退出时，作为最后手段向主进程发送 SIGKILL。

4. 清理并启动

• reset-failed 清理失败状态，随后 systemctl start docker。
• 若 start 失败，立即查看 systemctl status docker -l 与 journalctl -u docker 获取失败原因。

5. 验证

• systemctl is-active docker 应返回 active。
• docker info 能正常返回，docker ps 可列出容器，说明 CLI 与 dockerd 通信恢复。
• 核对关键业务容器是否仍在运行并对外提供服务。

预期输出结果

• 正常重启成功：
  • systemctl is-active docker 输出 active
  • systemctl status docker 显示 Active: active (running)
  • docker info 正常输出，包含 Server 与 Storage Driver 信息
• 若需要强制终止：
  • 执行 SIGKILL 后，start 成功，随后 status 显示 running
  • 日志中可能出现先前挂起请求被断开的提示，属预期现象

常见问题处理

• systemctl restart/stop 卡住
  • 使用 timeout 限制时长；
  • 进入“受控停止”步骤，使用 systemctl kill 对主进程发送 SIGTERM/SIGKILL。
• docker CLI 一直报 Cannot connect to the Docker daemon
  • 检查 dockerd 是否已运行：systemctl status docker；
  • 若失败，查看 journalctl -u docker 的错误（如端口占用、存储驱动异常、配置文件错误）。
• start 失败且提示配置问题
  • 检查 /etc/docker/daemon.json 格式是否有效（注意 JSON 语法与逗号）。
  • 移除近期修改或临时改名 daemon.json 后重试启动：mv /etc/docker/daemon.json /etc/docker/daemon.json.bak && systemctl start docker。
• 容器运行但日志压力大、再次出现卡顿趋势
  • 若 dockerd 日志写入 journald，建议限制 journald 日志占用：
    • 在不影响合规要求的前提下，按需回收：journalctl --vacuum-size=1G 或 --vacuum-time=7d
    • 永久配置：编辑 /etc/systemd/journald.conf（如 SystemMaxUse=1G, SystemMaxFileSize=200M），然后 systemctl restart systemd-journald（会短暂影响日志采集，不影响容器进程）
  • 降低 dockerd 日志量：在 /etc/docker/daemon.json 配置 "log-level": "warn" 或 "error"（需重启/重载 docker 生效；卡顿时先完成重启，再调整）
  • 为容器启用日志轮转（若使用 json-file 日志驱动）：在 daemon.json 设置
    • "log-driver": "json-file",
    • "log-opts": { "max-size": "100m", "max-file": "3" } 然后 systemctl reload docker（若 reload 无响应，按上述重启流程进行）

风险提示和注意事项

• 优先使用标准的 restart/stop/start 流程。对主进程发送 SIGKILL 为最后手段，仅在 dockerd 无法优雅退出时使用。
• --kill-who=main 的使用是为了仅作用于 dockerd 主进程，避免影响到容器进程；请勿对 control-group 发送 KILL。
• 重启期间，容器仍运行，但所有管理面操作（创建/停止/拉取镜像等）不可用；对编排系统（如 Swarm/K8s on Docker）可能短暂产生管理面告警。
• 回收 journald 日志会删除旧日志，请先确认合规与留存要求。
• 修改 daemon.json 或 journald 配置前，建议备份原文件，变更后验证 JSON 语法与服务可用性。

如需，我可以根据你当前的 /etc/docker/daemon.json 与 journald 配置给出更针对性的日志治理建议，以避免后续再次因日志堆积导致 dockerd 卡顿。