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 瓶颈案例。 六、可能的直接诱因：文件同步行为 进一步结合业务场景，发现一个高度相关的可能性： 用户正在进行文件同步操作（如私有云客户端同步） 这类同步具有以下特征： 其表现形式与当前监控数据完全一致。 …

Server

systemctl poweroff 和 shutdown now 的区别（systemd 时代）

写在前面 在现代 Linux（systemd 已成为事实标准）的环境下，很多关机命令在结果上是等价的，但在语义、设计出发点和适用场景上仍然存在差异。本文以实际使用为导向，梳理 systemctl poweroff 与 shutdown now 之间的关系与区别。 结论先行：在 systemd 系统中，它们最终走的是同一条关机路径，但入口不同。 一句话结论 systemctl poweroff：systemd 的原生方式 本质 systemd 实际执行流程 特点 适用场景 shutdown now：传统命令的 systemd 实现 在 systemd 系统中发生了什么 在现代发行版中： 也就是说： shutdown 的额外能力 这是它仍然存在的主要原因： 特点 等价关系整理（systemd 系统） 在 Arch / Debian / Ubuntu / RHEL 7+ 等 systemd 发行版中： 最终效果是相同的：系统正常关机并断电。 …

AI

NUC8 上使用 Ollama + Open WebUI 的轻量化本地大模型实践

背景与目标 在无 GPU、仅依赖 CPU 的环境中运行本地大模型，核心目标并不是追求参数规模，而是可长期运行、响应稳定、不干扰其他服务。本文记录了一套经过验证的实践方案：使用 Ollama 作为推理引擎，配合 Open WebUI 提供交互界面，并围绕模型体量、内存常驻、容器健康状态等关键点进行取舍与优化。 运行环境与约束条件 在该条件下，7B 级模型可以加载，但并不适合作为日常默认模型，会带来明显的加载延迟与系统压力。 模型选择策略（按体量与用途分层） 推荐的本地模型梯度 体量 模型示例 主要用途 评价 ~1.5B Qwen2.5 1.5B 兜底、系统繁忙时 极轻量，可长期常驻 ~2B Phi-3 Mini 默认工程模型 推理快、代码/脚本稳定 ~3B Qwen2.5 3B 中文/日语表达 语言自然度更好 ~7B Qwen2.5 7B 实验/对比 不建议常驻 结论：在 CPU-only 环境中，3B 以内是“甜点区间”，7B 更适合作为偶尔实验而非常驻。 部署架构概览 模型文件统一存放在持久化卷中，支持多模型并存，下载一次即可长期复用。 Docker Compose 配置（关键点） 在保持原有结构与注释的前提下，仅增加了模型内存常驻策略： …

AI

OpenWebUI + Ollama 的模型权限与语音能力整理

本文记录一次在自托管环境中使用 OpenWebUI + Ollama 的实际配置与排查过程，重点包括： 全文基于实践总结，不涉及任何具体主机名、端口、路径等敏感信息。 一、模型存在 ≠ 用户可用：OpenWebUI 的权限设计 在 OpenWebUI 中，即使已经完成以下操作： 普通用户依然可能看到： 模型列表为空 这并不是部署错误，而是 OpenWebUI 的权限模型设计所致。 1. 两个容易混淆的概念 OpenWebUI 将模型拆分为两个维度： 维度 含义 Enable 模型在系统中可用 Access / Visibility 哪些用户可以看到并使用 启用模型 并不等于 普通用户可见。 二、正确的模型授权方式（全局放行） 推荐做法是：由管理员统一放行模型给所有用户。 操作路径（管理员账号） 完成后，模型将正常出现在普通用户的模型列表中。 三、为什么会这样设计？ 这种设计对自托管场景其实是合理的： 对于长期运行的私有实例，这是一个偏“企业级”的设计思路。 四、OpenWebUI 是否支持语音对话？ 简短结论 支持，但不是一键式语音助手。 OpenWebUI 的定位是： UI + 编排层，而不是语音模型本体。 五、语音能力的模块化拆分 …

AI

Open WebUI + Ollama 反代与 WebSocket 400 问题排查记录

本文记录一次在 Docker + Nginx 反向代理 场景下，部署 Open WebUI + Ollama 时，遇到 WebSocket 400 与前端解析异常的问题，以及完整的定位与修复过程。本文采用工程记录风格，省略与具体环境强绑定的细节（路径、域名、IP 已脱敏），可作为同类问题的参考模板。 一、问题现象 部署完成后，表现为： 直观感受是： 二、初步排查：确认不是服务本身的问题 1. 确认容器状态 2. 直接访问容器端口 通过本机或内网直接访问 WebUI 暴露端口： 说明： 问题不在 Open WebUI 或 Ollama 本身 三、确认问题边界：反代之后才出问题 当通过 Nginx 反代访问时： 结论很明确： 问题发生在 Nginx → Open WebUI 的反向代理层 四、问题本质分析 1. Open WebUI 使用了什么通信机制？ 2. …

AI

自托管 Ollama + Open WebUI 实战记录（Docker Compose）

本文记录一次从 Ollama 后端模型服务 到 Open WebUI 前端界面 的完整搭建过程，重点放在 Docker Compose 架构、数据卷持久化、模型管理与常见误区。文中已对主机名、IP、端口等私人信息做统一脱敏处理。 一、目标与前提 目标 前提环境 二、关键概念澄清 在开始之前，先澄清几个容易混淆的点。 1️⃣ Ollama 版本 ≠ 模型大小 二者是完全不同的层级，不要混为一谈。 2️⃣ 7B 是什么 3️⃣ WebUI 与 Ollama 的关系 三、Docker Compose 结构设计 设计原则 四、最终 Docker Compose 配置（脱敏版） 五、启动流程 1️⃣ 启动服务 确认两个容器均为 Up 状态。 2️⃣ 下载模型（重点） 模型必须通过运行中的 Ollama 容器下载，否则会报错。 下载完成后验证： …

AI

Open WebUI 与 Ollama 的部署与权限设计实践

摘要 本文记录了一套可复制、低风险的 Open WebUI + Ollama 自托管方案，重点讨论二者是否应部署在同一个 Docker Compose 中、认证与管理员模型的设计，以及符合最小权限原则的日常使用方式。本文面向已有 Docker / 反向代理经验的读者，采用工程化视角，避免与具体路径、端口、域名等敏感信息绑定。 1. Open WebUI 的定位 Open WebUI 是为大语言模型交互设计的通用前端（Chat UI 层）： 其职责聚焦在用户交互、会话管理、权限控制与系统配置，而非模型训练或推理本身。 2. 与 Ollama 放在同一个 Compose 中是否合理 2.1 结论 在“单机一体化服务”的使用场景下，将 Open WebUI 与 Ollama 放在同一个 Docker Compose 文件中是高度合理的默认选择。 2.2 合理性依据 生命周期一致 安全边界清晰 运维成本低 故障域符合依赖关系 2.3 何时不建议放在一起 3. Open …

Hardware

R720 服务器本地大模型选型与 GPU 加速分析

一、背景与问题定义 在自托管大语言模型（LLM）的实践中，服务器硬件配置对可用模型规模与交互体验有决定性影响。本文以一台典型的企业级服务器为例： 核心问题包括： 本文围绕上述问题，给出工程化、可落地的分析结论。 二、无 GPU 情况下的模型能力边界 1. CPU 推理的本质限制 大语言模型推理的核心计算为大规模矩阵乘法与注意力计算，这类任务具备高度并行特征，但传统 CPU（即使是双路服务器）存在以下天然限制： 以 Xeon E5 v2 世代为例，其指令集通常仅支持 AVX，不支持 AVX2 / AVX-512，这会进一步放大与现代平台的性能差距。 2. 可运行模型规模（以内存为维度） 在使用 4-bit 量化（Q4）模型的前提下，大致内存占用如下： 模型规模 典型内存占用 7B 4–6 GB 14B 8–12 GB 32B 18–24 GB 70B 40–55 GB 从“是否能加载”角度看，128 GB 内存足以容纳 70B 量化模型；但从“是否可用”角度看，结论完全不同。 3. 实际可用档位 在无 GPU 情况下，7B–14B …