Linux 磁盘空间充足却无法创建文件:inode 耗尽的排查与治理实践
## 适用场景 应用报出 `No space left on device`,但 `df -h` 显示磁盘使用率不高;Nginx 无法写入访问日志、容器无法创建临时文件、CI 构建失败,甚至 `touch` 一个空文件也失败。这通常不是字节空间耗尽,而是文件系统可分配的 inode 已经用完。 本文以 ext4/X
技术笔记、项目复盘、阅读摘录和问题清单。
## 适用场景 应用报出 `No space left on device`,但 `df -h` 显示磁盘使用率不高;Nginx 无法写入访问日志、容器无法创建临时文件、CI 构建失败,甚至 `touch` 一个空文件也失败。这通常不是字节空间耗尽,而是文件系统可分配的 inode 已经用完。 本文以 ext4/X
## 适用场景 服务运行正常,但在故障窗口里 `journalctl` 中恰好缺少应用最关键的一段日志;常见于 Java、Python、Nginx/OpenResty、容器运行时或短时间大量报错的 systemd 服务。运维人员往往把它误判为程序没有输出,实际日志可能已经被 `systemd-journald` 的限
## 适用场景 Linux 宿主机的根分区或 Docker 数据盘持续告警,`/var/lib/docker/overlay2` 占用不断增加;但镜像和容器数量并不多,普通镜像清理也没有效果。本文给出 overlay2 的归属定位、止血和治理流程。 > 以下路径以 `/var/lib/docker` 为例。先用 `
## 适用场景 使用 Celery + Redis/RabbitMQ 承担异步任务。队列中仍有大量待执行任务,但监控显示少数 Worker 忙碌、其余 Worker 空闲;或者短任务被长任务“压住”,整体延迟持续升高。本文以默认的 `prefork` 并发池和 RabbitMQ 为例,Redis broker 的排查
## 适用场景 部署在 Kubernetes 中的 Web、API 或消费服务在高峰期 CPU 已长期接近上限,但 HorizontalPodAutoscaler(HPA)始终保持原副本数;也可能在 `kubectl get hpa` 中看到 CPU 显示为 `<unknown>`。本文以基于 CPU 利用率的 HP
## 适用场景 Linux 服务器上的 Java、Python、Go 或 Node.js 服务由 systemd 托管。发布后或依赖异常时,进程在几秒内连续退出;即使问题随后已修复,执行 `systemctl restart` 仍失败,状态显示为 `failed`,日志里出现 `Start request repea
## 适用场景 Redis 采用主从复制,业务高峰时偶发写入延迟、主库 CPU 或网络突刺。日志中反复出现 `Full resync requested`、`Partial resynchronization not accepted`,从库短时间内加载 RDB,甚至与主库断开后很久才恢复。 本文适用于 Redis
## 适用场景 本文适用于 Prometheus 运行一段时间后出现以下现象的场景: - Prometheus 数据目录持续膨胀,磁盘空间很快被打满; - `prometheus_tsdb_head_series`、`prometheus_tsdb_head_chunks` 持续上涨; - 查询变慢,Prometh
## 适用场景 业务表按租户、状态和创建时间查询列表。数据量从几十万增长到千万级后,接口 P95 延迟突然升高;应用监控中数据库耗时占比明显增加,但 CPU 和磁盘利用率并不一定很高。 本文以常见的订单列表为例,说明如何确认“建了索引却没有用好”的联合索引问题,并在不影响线上写入的前提下完成优化。 ## 现象描述
## 适用场景 本文适用于 Kubernetes 集群中出现以下问题的场景: - 新发布的 Pod 长时间处于 `Pending` 状态; - `kubectl describe pod` 中看到 `node(s) had disk pressure`; - 节点状态出现 `DiskPressure=True`;