维护
-
PVE 8.x 环境下 N100 核显 SR-IOV 直通保姆级教程，实现多虚拟机同时硬件解码
在低功耗工控机和 NAS 领域，Intel N100（Alder Lake-N）因其极低的功耗和优秀的 24 EU Xe 核显性能，成为了目前最火爆的选择。 以往在 Intel 核心上，我们常用 GVT-g 技术来实现核显虚拟化，...
-
物理黑群晖 vs PVE虚拟化：家用低功耗NAS，谁在硬盘休眠和省电上更胜一筹？
在折腾家用 NAS 的圈子里，“功耗”和“硬盘休眠”永远是绕不开的两个核心话题。 很多新手在规划自己的 low-power NAS 时，往往会被 PVE（Proxmox VE） 强大的虚拟化能力所吸引，幻想着“一台主机搞定群晖、软...
-
拒绝重启：KVM 虚拟机 SR-IOV 直通极速网络与网卡热插拔实战
在高性能计算、低延迟网络传输（如金融交易、电信网元 NFV）等场景下，普通的 VirtIO 虚拟网卡即使开启了 vhost-net，也无法满足极致的吞吐和延迟要求。**SR-IOV（Single Root I/O Virtualizati...
-
N100 平台 PVE 8 开启核显 SR-IOV 后的整机功耗实测与深度调优指南
在低功耗小主机和 NAS 界，Intel N100 凭借 4 个 Alder Lake-N 核心和 24EU 的 Xe 核显，直接成为了新一代的「神U」。而 Proxmox VE (PVE) 作为家用虚拟化平台的首选，配合 SR-IOV...
-
N100核显SR-IOV虚拟化：PVE 8.x下Jellyfin与Plex开启QSV硬解保姆级教程
在 PVE 8.x 下，Intel N100 凭借其极低的功耗和出色的 QSV 解码能力，成为了家用 NAS/All-in-One 路由器的明星 CPU。传统的核显直通（Passthrough）只能将核显分给单一虚拟机，而通过 SR-I...
-
PVE 8.0下Intel 12代及以上核显SR-IOV虚拟化实操教程（保留宿主机HDMI输出）
在 Intel 11 代之前的消费级平台上，我们常用 GVT-g 技术来对核显进行分片虚拟化。但从 12 代（Alder Lake）及以后的架构（包括 N100、i3-12100、i7-13700 等）开始，Intel 彻底废弃了 GVT...
-
N100 部署 PVE 8.1：用 SR-IOV 虚拟显卡完美搞定黑群晖 Photos 人脸识别与 Plex 硬解转码
在单台轻量级服务器（如搭载 Intel N100 处理器的小主机）上，既想让 PVE 主机保留控制台输出，又想让黑群晖（DSM）实现独占般的显卡硬件加速（用于 Plex/Jellyfin 转码和 Synology Photos 人脸识别）...
-
13代Intel核显在PVE 8.1下完美的SR-IOV虚拟化配置指南
在玩转 Homelab 和 PVE（Proxmox VE）时，核显虚拟化一直是高频需求。自 Intel 11 代 CPU 开始，传统的 GVT-g 虚拟化方案（可以将核显切分为多个 vGPU 供不同虚拟机使用）已被彻底废弃。取而代之的是 ...
-
PVE 虚拟机 vs LXC 容器：Jellyfin 硬件解码直通深度评测与避坑指南
在 Proxmox VE（PVE）环境下部署 Jellyfin 媒体服务器时，如何让其高效地调用显卡（核显或独显）进行硬件转码，是每个 HomeLab 玩家必须要面对的课题。 最常见的两条路线是：**LXC（Linux 容器）**与 ...
-
不重启系统，如何实现 SPDK 用户态存储引擎元数据版本的在线热升级？
在构建基于 SPDK（Storage Performance Development Kit）的高性能用户态存储引擎时，**“在线热升级”（Live Upgrade / Hot Upgrade）**通常是研发中后期必须啃下的硬骨头。 ...
-
SPDK Blobstore在高频元数据写入场景下的碎片整理与GC架构设计
在高性能存储系统设计中，SPDK Blobstore 凭借其用户态、异步、无锁以及轮询（Polled-mode）的特性，成为了构建新型分布式存储和数据库底层引擎的热门选择。然而，当面临高频、小包的元数据（如目录树修改、KV索引更新、对象属...
-
跑满 NVMe 极限：基于 SPDK 的无锁分布式元数据引擎架构设计
在单盘 NVMe SSD 轻松突破百万级 IOPS、百微秒级延迟的今天，分布式存储系统的性能瓶颈早已不再是底层物理硬件的读写速度，而是软件栈在 CPU 上的开销。 在传统架构中，元数据引擎（如基于内核态文件系统的 RocksDB）在面...
-
解决RocksDB在时序高并发场景下MemTable频繁Flush、WAL积压与写放大的系统性方案
在基于 RocksDB 构建高并发时序数据库（TSDB）时，很多架构师和内核开发人员都会遭遇一个经典的技术「死锁」： 在高吞吐写入下，为了保证写入性能和防止 OOM，系统会频繁触发 MemTable Flush。这看似释放了内存，却直...
-
不重启 RocksDB，如何动态、精准地获取当前 Compaction 引起的 WAF 趋势？
在生产环境的高并发写入场景下，RocksDB 的写放大（Write Amplification Factor, WAF）是导致 I/O 抖动和吞吐量下降的罪魁祸首。很多时候，我们发现磁盘 I/O 跑满，怀疑是 Compaction 引起的...
-
SSD FTL 碎片化是如何击穿数据库 P99 延迟的？
在评估数据库性能时，平均响应时间（Average Latency）往往是一片风平浪静，但 P99 甚至 P99.9 延迟的突然飙升（比如从数百微秒暴涨至数十毫秒），却常常成为线上系统的“无形杀手”。 这种偶发性的延迟毛刺，很多时候并非...
-
深入 RocksDB/Titan：如何优雅地针对特定 CF 禁用与启用 KV 分离？（附动态切换避坑指南）
在海量 KV 存储场景中，RocksDB 的写放大（Write Amplification）一直是架构师的心头大患。为此，PingCAP 开发了 Titan 作为 RocksDB 的 KV 分离插件，通过将大 Value 写入独立的 Bl...
-
Cassandra 5.0 遭遇节点长周期离线，Accord 协议的元数据堆积如何一步步诱发写放大雪崩
在 Apache Cassandra 5.0 中，最令人瞩目的特性莫过于引入了 Accord 协议 （CEP-15）。它通过无主（Leaderless）的一阶段/两阶段共识机制，在不引入外部协调器的前提下，为 Cassandra 带来了...
-
Cassandra 5.0 中的 Accord 事务引擎是如何解决元数据与依赖日志无限膨胀问题的？
作为 Cassandra 5.0 最受瞩目的特性之一，基于 Accord 协议 的全局多 Key 无锁 ACID 事务（CEP-15）彻底改变了 Cassandra 过去只能依靠 LWT（轻量级事务）实现单行一致性的局限。 然而，分...
-
从 EPaxos 到 Accord：分布式共识如何突破 1 RTT 的极限？
在分布式系统领域，传统的强一致性共识算法（如 Multi-Paxos、Raft）通常依赖一个稳定的 Leader。这种设计虽然直观，但在跨地域（Geo-distributed）部署或高并发写入场景下，会暴露出明显的局限性： 网络...
-
嫌 Cassandra 的 Paxos 慢？聊聊如何实现高性能的“无锁”强一致性写入
在分布式数据库领域，Cassandra 一直以极高的写入吞吐量（AP 系统的典范）著称。然而，一旦业务场景要求 强一致性（Linearizability） ，比如余额扣减、唯一性约束，大家的第一反应往往是使用 Cassandra 的轻量级...
