Docker

Docker 中未被任何容器使用的卷识别与清理实录

背景 在长期运行的 Docker 环境中，随着容器的反复创建、删除与重建，系统中可能残留未被任何容器使用的卷（volume）。这些卷如果不加区分地清理，存在误删有效数据的风险；如果完全不清理，又会造成系统状态不透明。 本文记录一次严格、可验证的 Docker 卷清理过程，目标是： 一、初步筛选：dangling volume Docker 提供了对“悬空卷（dangling volume）”的定义： 未被任何容器引用的卷 使用以下命令列出： 输出结果为两个卷 ID： 该步骤只能说明： 这些卷当前没有被容器引用 但仍需要进一步验证它们的空间占用与引用状态。 二、空间与引用状态交叉验证 通过 docker system df -v 查看本地卷的使用情况，并重点关注两项信息： 关键结果如下（节选）： 可以确认： 三、判断结论 综合两次验证结果： 卷 ID LINKS SIZE 状态 14ab1c74859f… 0 7.7 kB 未被使用 ebd2fa33478… 0 90 kB 未被使用 结论： 四、安全删除方式 明确目标卷后，采用精确删除而非批量清理： 该方式的优点是： 五、实践原则总结 …

Food

从 Brix 到砂糖：一次关于“控糖咖啡”的理性拆解

一、问题背景 在超市中常见一种标注为“糖度控制”的咖啡饮料。直观感受是甜度不高，但如果从理性角度出发，一个自然的问题是： 这种咖啡里，实际相当于摄入了多少“糖”？是否会对长期健康造成影响？ 本文从 糖度（Brix）定义、砂糖种类、折糖换算、热量估算 等角度，对这一问题进行一次完整拆解。 二、Brix（糖度）到底表示什么？ 糖度计上显示的 Brix（°Bx），并不等同于“真实加了多少糖”。 定义： 1 °Bx = 100 g 溶液中，含有 1 g 蔗糖当量的可溶性固形物 关键点在于： 因此： 在咖啡中，除了糖，还包括： 这些都会对 Brix 产生贡献。 三、为什么“糖度控制咖啡”不能直接读糖量？ 即使是完全无糖的黑咖啡，其 Brix 通常也在 0.5–1.5 °Bx 左右。 因此： 一定会高估实际糖摄入。 合理做法（理论上）： 但在日常生活中，更现实的方式是：根据配方和标称糖度进行估算。 四、砂糖的种类：グラニュー糖 vs 上白糖 在日本常见两种砂糖： 1️⃣ グラニュー糖（Granulated Sugar） 用途： 👉 食品分析与量化计算的“基准糖” 2️⃣ 上白糖 用途： 👉 …

Server

一次服务器磁盘 I/O 瓶颈的排查记录

一、问题背景 在一台长期稳定运行的 Linux 服务器上，近期观察到以下现象： 初步判断：瓶颈不在 CPU 和内存，而可能在磁盘 I/O。 二、第一步：整体负载判断（top） 通过 top 观察系统整体状态，发现： 这类特征通常意味着： CPU 有空闲，但进程在等待磁盘 I/O 完成。 此时需要进入磁盘层面分析。 三、第二步：磁盘层分析（iostat） 使用： 重点关注以下指标： 关键观测结果 这说明： 磁盘并非被“大流量读写”压满，而是被 高频小块 I/O（IOPS） 打满。 这是数据库 + 元数据密集型负载的典型特征。 四、第三步：进程级定位（iotop） 使用： 该工具可以实时展示 哪些进程在进行磁盘读写。 观察到的主要 I/O 来源 系统级进程（日志、容器运行时等）均处于正常噪音水平。 五、负载模式分析 综合 top、iostat、iotop 的结果，可以得到完整因果链： 这是一个教科书级的磁盘 I/O 瓶颈案例。 六、可能的直接诱因：文件同步行为 进一步结合业务场景，发现一个高度相关的可能性： 用户正在进行文件同步操作（如私有云客户端同步） 这类同步具有以下特征： 其表现形式与当前监控数据完全一致。 …