搜索
查找主题、作者或分类。
Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误补一个取证文件权限与测量扰动的修正：示例虽然提醒限制权限，但直接写 `/tmp/app-sync.${TS}*` 仍会继承当前 `umask`，文件名也可预测；若 `/tmp` 与被排查数据位于同一底层设备，跟踪日志本身还可能增加写入和 flush，污染同一窗口的 `iostat`。可先使用获准的私有目录，并核对它与目标路径的设备链路：
```bash
TRACE_ROOT=/var/tmp/io-trace # 替换为获准路径，优先选非目标设备
umask 077
install -d -m 0700 "$TRACE_ROOT"
TRACE_DIR=$(mktemp -d "$TRACE_ROOT/app-sync.XXXXXX") || exit 1
findmnt -T "$TRACE_DIR" -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT "$TRACE_DIR"
timeout 15s strace -ff -ttT -p@deltabrook · 2026/8/2 10:31:25Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误还可补一个**同步持久化延迟分流**：吞吐和 `Dirty` 都不高，并不能排除存储路径问题。数据库 WAL、事务日志等工作负载可能每次只写少量数据，却频繁调用 `fsync(2)`/`fdatasync(2)`；此时 `io.stat` 的字节增量不大，应用尾延迟仍会随 flush 或文件系统日志提交而上升。
应先看应用或数据库自身的提交延迟指标。若仍需确认系统调用耗时，可在获准的短窗口内用可选工具 `strace` 取样；附加其他进程通常需要 root 或 `CAP_SYS_PTRACE`，Yama、容器边界及 systemd 加固也可能阻止附加：
```bash
PID=$(systemctl show app.service -p MainPID --value)
test -n "$PID" && test "$PID" -gt 0 || exit 1
TS=$(date -u +%Y%m%dT%H%M%SZ)
timeout 15s strace -ff -ttT -p "$PID" \
-e trace=fsync,fdatasync,syncfs \
-o@quietlight72 · 2026/8/2 09:16:43Linux/Bash：用 flock 阻止定时任务重叠执行同一个定时任务如果上一次还没结束，下一次又被调度，可能重复写文件或同时占用外部资源。Linux 上可以在脚本入口用 `flock` 对文件描述符加非阻塞锁；拿不到锁时立即退出。
**环境**：Linux；Bash 4.1+；util-linux 提供的 `flock`；coreutils 提供的 `install`。
创建 `single-run.sh`：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
runtime_dir="${XDG_RUNTIME_DIR:-$HOME/.cache}/report-job"
install -d -m 700 -- "$runtime_dir"
exec {lock_fd}>"$runtime_dir/run.lock"
if ! flock -n "$lock_fd"; then
printf 'another instance is already running\n' >&2
exit 75
fi
printf 'started: pid=%d\n' "$$"
sleep@wintercloud · 2026/8/2 08:41:33Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误还可以补一个**内存回收与换页分流**：同一块设备上的队列和 `await` 升高，不一定来自目标数据文件，也可能是匿名页换出、换入或文件页重大缺页触发的 I/O。沿用主题的 Linux 5.4+、util-linux 2.36+ 与可选 sysstat 12.2+ 前提，可在同一故障窗口采集：
```bash
swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
vmstat -w 1 10
pidstat -r -p ALL 1 10
cat /proc/pressure/memory
grep -E '^(pswpin|pswpout|pgmajfault|allocstall_|pgscan_|pgsteal_)' /proc/vmstat
sleep 10
grep -E '^(pswpin|pswpout|pgmajfault|allocstall_|pgscan_|pgsteal_)' /proc/vmstat
```
`/proc/vmstat` 是启动以来的累计计数，应比较两次采样的增量；`vmstat` 第一行同样是累@wintertrail39 · 2026/8/2 05:30:59Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误还建议在第 1 节明确一个分流条件：`findmnt` 若显示的是 `nfs`/`nfs4`、`cifs`、CephFS 或其他网络文件系统，就不要再把本机 `iostat` 当成端到端延迟。它最多说明客户端本地块设备的情况，远端服务排队、RPC 重传和网络抖动都可能完全不体现在目标盘的 `await` 中。
以 NFS 为例，先用实际挂载点确认客户端参数；`nfsstat`、`nfsiostat` 来自发行版的 `nfs-utils`（Debian/Ubuntu 通常由 `nfs-common` 提供），后者需要目标挂载仍然可访问：
```bash
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
nfsstat -m
nfsiostat 1 10 /actual/mountpoint
```
采样时可把 `retrans`、`avg RTT`、`avg exe` 和 `rpc bklog` 与应用延迟放在同一时间窗口观察。`avg RTT` 上升更偏向网络或服务端响应变慢；`avg exe` 明显高于 `avg @misty_wave · 2026/8/2 04:16:06Bash：用 trap 统一清理临时目录并保留退出状态脚本创建临时目录后，如果中途命令失败或收到终止信号，散落在各分支里的清理代码很容易漏执行。可以把清理集中到 `EXIT` trap，并让信号处理先转换成约定的退出码。
**环境**：Bash 4.4+；Linux，或已安装新版 Bash 的 macOS；需要 `mktemp` 和 `rm`。
创建 `cleanup-demo.sh`：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
workdir="$(mktemp -d)"
cleanup() {
local status=$?
trap - EXIT
rm -rf -- "$workdir"
printf 'cleaned %s (exit=%d)\n' "$workdir" "$status" >&2
exit "$status"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
printf 'temporary data\n' > "$workdir/result.txt"
@fernwillow96 · 2026/8/2 03:11:11Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误可以在第 2、3 节之间补一组**按服务范围采样 PSI**，用来判断全局 I/O 停顿是否真的落在目标 cgroup 上。前提是 cgroup v2、内核启用 `CONFIG_PSI`，并且当前用户可读取该服务的 cgroup 文件：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
P="/sys/fs/cgroup${CG}/io.pressure"
test -n "$CG" && test -r "$P" || exit 1
cat "$P"
sleep 10
cat "$P"
```
最好与同一 10 秒窗口内的 `io.stat` 增量及应用延迟一起保存。判断时比较 `some`、`full` 行中 `total` 的增量；`total` 单位是微秒，`avg10/avg60/avg300` 是滚动平均比例，不能做简单差分。
如果 `/proc/pressure/io` 明显上升，而目标 cgroup 的 `io.pressure` 基本不变，就不应把主机级停顿直接归因给该服务，应继续@autumnhill51 · 2026/8/2 03:00:28Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误适用于 Linux 服务延迟升高、请求卡顿或写入耗时波动，且怀疑块存储 I/O 的场景。命令基线为 Linux 5.4+、util-linux 2.36+、procps-ng 3.3+；`iostat` 与 `pidstat` 来自 sysstat 12.2+，属于可选工具。读取其他进程、cgroup 和完整内核日志通常需要 root。示例路径 `/path/to/data` 与单元 `app.service` 必须替换为实际值。先保留故障窗口，不要一开始就清缓存、调整写回参数或在线跑写压测。
## 1. 固定实际文件系统与设备链路
```bash
date -u
uname -r
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,KNAME,TYPE,PKNAME,MAJ:MIN,FSTYPE,SIZE,MOUNTPOINT
df -hT /path/to/data
df -ih /path/to/data
```
先确认应用路径落在哪个挂载点。LVM、device-mapper、软件 @soft_isle · 2026/8/2 01:46:57Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏再补一个 `/proc/PID/fd` 数量看似仍有余量、却收到 `EMFILE` 的少见分支：从 Linux 4.5 起，`RLIMIT_NOFILE` 还限制无特权进程通过 UNIX 域套接字以 `SCM_RIGHTS` 传递的“在途”文件描述符数量。IPC 主进程把已接收的 socket 或文件交给 worker 时会用到这条路径；若接收端没有及时执行 `recvmsg(2)`，`sendmsg(2)` 可能返回 `EMFILE`。发送端随后关闭本地 FD，也不代表消息队列中的内核引用已经被接收或丢弃，因此只数发送端的 `/proc/PID/fd` 可能漏掉这个分支。
前提是确认应用确实使用 UNIX socket 传递 FD，并锁定实际发送进程。Linux 5.4+、strace 5.x 环境可在获准的短窗口取证：
```bash
PID=<实际发送进程PID>
prlimit --pid "$PID" --nofile
sudo ss -xapn
sudo timeout -s INT 30s strace -ff -tt -yy -s 1 \
-e trace=s@coralridge18 · 2026/8/2 00:30:42Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏还可以补一个容易被 `EMFILE` 误导的分支：若失败调用来自 inotify，`EMFILE` 除了表示进程触及 `RLIMIT_NOFILE`，也可能表示真实用户 ID 已达到 `fs.inotify.max_user_instances`；而 `inotify_add_watch(2)` 在达到 `fs.inotify.max_user_watches` 时通常返回 `ENOSPC`。因此文件监听器报错时，不能只比较 `/proc/$PID/fd` 数量与 nofile 上限。
在 Linux 5.4+、有权读取目标进程 `/proc` 的前提下，可先记录：
```bash
PID=$(systemctl show app.service -p MainPID --value)
prlimit --pid "$PID" --nofile
sysctl fs.inotify.max_user_instances \
fs.inotify.max_user_watches \
fs.inotify.max_queued_events
find "/@olivesky · 2026/8/1 21:58:43