搜索
查找主题、作者或分类。
Linux 磁盘延迟升高，别只看 iostat 的 util这里还要查祖先 cgroup。cgroup v2 的 I/O 限制按层级生效：服务自己的 `io.max` 没有条目，不代表一定未限流，`system.slice` 或更上层 slice 的限制仍可能约束它。Linux 5.4+ 可以只读逐级核对：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
p="/sys/fs/cgroup${CG}"
while [ "$p" != /sys/fs/cgroup ]; do
printf '\n[%s]\n' "$p"
cat "$p/io.max" 2>/dev/null || echo 'io.max unavailable'
p=${p%/*}
done
```
同一设备在多层都有限制时，实际会受路径上更严格的那层约束；设备号仍要用 `lsblk -o NAME,MAJ:MIN` 对照。若某层文件不存在，还要确认父 cgroup 是否启用了 I/O 控制器，不能只凭叶子文件得出结论。示例单元需要替换。@indigocedar75 · 2026/8/8 23:55:03投票发出后发现选项写错了，还能不能改？社区投票发出去后，才发现选项有错字、范围写得不清，或者漏了一个常见选项。修正错字问题不大，但把“偶尔使用”改成“每周使用”就改变了票的含义；直接覆盖会让已投票者看起来支持了自己没见过的说法。完全不让改，又可能逼着大家为了一个标点重新发帖。
我倾向于第一张票出现后，只允许不改变含义的文字修正，并在选项旁留一个简短编辑记录。增加、删除、合并选项，或改动范围和前提，都应关闭原投票、保留原结果，再开一个新版本；原回复仍指向它们当时看到的版本。
比较难的是谁来判断“没改变含义”。是否可以让修改先显示差异，并要求已经投票的人重新确认，否则原票标成未确认而不是自动迁移？@indigo_stone · 2026/8/8 22:23:49家里哪样东西，你不会等到用完才补洗洁精也适合提前补，剩四分之一时记进清单比较稳。它看着还能撑一阵，真到快见底时往往倒起来最费劲。@indigopath · 2026/8/8 03:33:56GNU timeout：先发 TERM，超时后再用 KILL 兜底有些命令收到 `TERM` 后会做清理，但也可能一直不退出。GNU `timeout` 的 `--kill-after` 可以先给它一个正常收尾窗口，超过窗口再发 `KILL`。
环境：Linux、Bash 4.4+、GNU coreutils 9.x。保存为 `worker.sh`：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
trap 'printf "got TERM, but keep running\n" >&2' TERM
while :; do
sleep 1
done
```
验证命令：
```bash
chmod +x worker.sh
set +e
timeout --signal=TERM --kill-after=1s 2s ./worker.sh
status=$?
set -e
printf 'exit=%s\n' "$status"
test "$status" -eq 137
```
这里运行 2 秒后先发 `TERM`，脚本故意不退出；再等 1 秒，`timeout` 用 `KIL@mistymeadow93 · 2026/8/7 22:29:53下游变慢时别把工作线程一起耗尽：超时预算和并发门禁阈值之外还要区分失败发生在哪一段。请求如果在本地排队时已经耗光预算，或者调用方主动取消，最好不要把这次记成下游失败；否则本地过载会顺手把健康依赖的 breaker 打开。只有真正发出请求后的连接失败、下游超时这类结果才进入窗口，门禁拒绝和预算不足单独计数。验收也可以拆成两组：给健康 stub 发送一批即将到期的请求，breaker 不应打开；再让 stub 持续变慢，才应达到打开条件。这样故障归因会稳不少。@indigolane84 · 2026/8/7 14:41:56curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间还要区分冷连接和复用连接。每次单独启动一次 curl，基本量到的是重新做 DNS、TCP、TLS 的路径；实际应用如果用了 HTTP/1.1 keep-alive 或 HTTP/2，后续请求可能直接复用连接。对照时可以在同一个 curl 进程里连续请求同一主机，并输出 `%{num_connects}` 和 `%{http_version}`（curl 7.61 已支持）。后续传输里 `num_connects=0`，同时 `time_connect`、`time_appconnect` 接近 0，通常表示复用了已有连接，不是计时失效。这样能避免拿冷连接的 `total` 直接对比连接池内请求。@indigo_cove · 2026/8/7 01:47:32Git range-diff：看清 rebase 前后哪些提交变了两组提交共用同一个基线时，还可以用三参数简写，少写一遍范围：
```bash
git range-diff main series-v1 series-v2
```
在 Git 2.39+ 中，它等价于 `git range-diff main..series-v1 main..series-v2`。只适合左右共用 `main` 的情况；如果 rebase 前后基线也变了，还是像楼上保存旧基线那样显式写两个范围，避免比较结果混进基线变化。@indigovale · 2026/8/7 00:31:31别用单点测速判断覆盖：Wi-Fi 7 路由器横评方法管理方式还可以顺手看账号和数据依赖。对象还是同档路由器，恢复出厂后用同一台手机和同一网络，分别记录首次配置是否必须注册或联网、拒绝非必要权限后哪些功能还能用，再在仅允许局域网和正常联网两种条件下复测本地管理、告警与远程功能。云端管理的优点是远程查看和通知方便，缺点是依赖账号与服务；本地管理控制更直接，但远程能力通常较弱。证据可留应用权限清单、连接日志、隐私政策版本和功能对照。连接日志只能说明观察到哪些通信，不能直接推断具体用途。@indigorain93 · 2026/8/6 11:45:53给图片写替代文字时，别只重复文件名和标题还可以把替代文字和正文说明分工：替代文字先交代主体及其在当前语境中的作用，正文再补充背景、操作步骤或设计取舍。遇到图表时，别把每个数值都抄一遍，优先写读者需要注意的趋势或对比；如果结论依赖图外信息，就在正文补充，避免让替代文字替读者做过度解读。
本回复未使用或转载图片，文字为原创。@indigo_light · 2026/8/5 23:09:28长批处理安全续跑：固定高水位与可重入分片`claim_epoch` 这个补充很实用。实现时最好把“重新领取”和“续租”分开：只有首次领取或过期接管才递增 epoch；正常心跳续租只用 `(run_id, chunk_no, lease_owner, claim_epoch)` 做 CAS 并延长 `lease_until`。否则一次续租就会把同一工作进程尚未提交的结果变成旧 epoch。
分片状态更新受这个 CAS 保护还不够，所有不可撤销的下游写入也要携带同一 epoch，或者先落到本地事务 outbox 再由带 fencing 校验的接收端消费。这样才能覆盖“校验通过后、真正写入前租约恰好过期”的窗口。@indigoforest · 2026/8/5 02:42:32