标签频道
Linux运维
该标签下的文章、提问与讨论帖。
«结论先行："rsync --delete" 是运维日常里杀伤力最高、却最常被当成"普通参数"的一个开关。它让 rsync 从"增量同步"变成"以源为准的镜像删除"——源端少了什么，目标端就删什么。绝大多数误删事故不是 rsync 本身坏了
CPU 只有 38% 但上下文切换从 900/s 飙到 11000/s：用 pidstat 区分「自愿 vs 非自愿」锁住锁 convoy 的完整排查 «结论先行：「CPU 低 + P99 爆炸 + 上下文切换暴涨」是一个指纹，不是一个问题
«结论先行：journald 的「默认上限 4GB」只在 "/var/log/journal/" 持久化目录下生效；一旦存储落在 "/run/log/journal/"（内存型 tmpfs），上限只有 10% 内存，且重启即清零——而真正让
背景 我们一台 RHEL 9 节点的支付网关日志（RHEL 9.2，logrotate 3.21.0，应用 Java 直写文件，非 systemd-journald），logrotate 配置是这样的： /var/log/paygw/pay
«结论先行：宿主机 OOM 时内核不是按「谁更关键」挑受害者，而是按 oom_score 打分挑「RSS 占系统内存比例最高」的进程。业务上最不能死的 Redis（600MB）得分最低、反而最安全；业务上最该被杀、也最好重启的 Java（4
«作者视角：15 年运维，长期盯 Linux 基础层。这篇文章不聊「要不要上 ZFS」，只讲一个更常见、也更容易被忽略的坑：ext4 的 journal 默认只管元数据，不管数据——你在应用层看到 "write()" 全部成功、"close
«结论先行：systemd 的 "Restart="、"StartLimitBurst"、"WatchdogSec" 是三条互相独立、互相不兜底的防线。绝大多数团队只配了第一条（"Restart=on-failure"），于是「进程死了能拉
«结论先行："load average" 统计的是「运行队列 + 不可中断任务数」的平滑值，不是 CPU 使用率。当出现「load 高 + CPU 低 + IO util 低但 await 高」的组合，第一嫌疑是 D 状态堆积，最常见的来源
一、现象：一次「日志轮转」把服务打挂了 6 分钟 去年 12 月的一个凌晨 03:14，我们的 "order-svc"（RHEL 9.2，logrotate 3.21.0，systemd-journald 接管系统日志，但业务日志走文件）开
«结论先行："df" 和 "du" 对不上、磁盘明明"看着还有空间"却写不进去，十有八九不是文件系统坏了，而是有进程还攥着一个已经被 "unlink" 删掉的大文件不放——目录项没了（所以 "du" 扫不到它），但 inode 和数据块因为
一、现象：df 说还有空间，应用却说写不进去 去年 11 月凌晨 02:17，监控告警："order-gateway" 节点（CentOS 7.9，XFS 文件系统，系统盘 100GB）连续 3 分钟写入失败，业务日志刷满 "No spac
文
标题
摘要