部署运维
写于 2026-06-26。背景: MCP 服务 跑在 3 台 ClickHouse(每台 16 核 / 64G,1 分片 3 副本)上。 我们花了一整轮做公网压测,把这套系统的极限、天花板和杠杆全摸清了。这篇把"吞吐 / 延迟 / 排队"这三个最容易混的概念讲透,配我们自己的真实实测数据。 一句话结论 我们这套系统的吞吐天花板 ≈ 76 req/s。 往里塞再多并发(100、200、300、500),每秒"做完"的还是大约 76 个,多出来的全在排队。系统不会崩,只会让每个人等得更久。 天花板能不能抬?
部署运维
这次做的是一轮真实的本地模型部署摸底。 目标不是搭一个临时 Demo，而是把一台四卡 3090 GPU 机器接进自己的日常 AI 使用环境：本机跑 Open WebUI，负责账号、会话和前端配置；GPU 机器只负责模型推理。这样以后换模型、换推理框架、重启服务，都尽量不影响本机的使用入口。 最后结论比较清楚：qwen3.5:35b 的 GGUF Q4_K_M 量化版已经通过 Ollama 跑通，本机 Open WebUI 可以接入，热加载后的聊天速度也能用；但 GPU0 存在明显稳定性问题，重启后能短暂恢复，跑过负载后又会掉到 NVML 异常状态。 状态快照 当前能用的部分： * 本机 Open WebUI 已部署，
部署运维
我们最近把一套面向 AI agent 的分析型数据服务,从单机迁到了 ClickHouse 集群(1 分片 × 3 副本 + HAProxy 入口),并做了一轮系统的性能调优。 这篇不止于"我们改了哪些参数",更想讲清楚背后的思路:怎么用数据定位病根、怎么在"空间/复杂度/收益"之间取舍、怎么做到改完能验证、出事能秒回滚、上线不断服务。如果你也在为高重复、只读、模板化的负载(AI agent、看板、报表 API)调 ClickHouse,这套方法可以直接借鉴。 一条主线贯穿全文:先吃透流量特征,再分层优化,每一步都可验证、可回滚。 一、起点:先吃透你的流量长什么样 任何优化的第一步不是动手,
部署运维
大文件解压这件事，平时看起来很小，真遇到几十 GB 的 tar.gz 包时就会变得很烦。 最常见的命令是： tar -xzf archive.tar.gz -C output/ 它能用，但有几个问题： * gzip 解压基本是单核，机器有很多核也用不上。 * 没有进度条，不知道还要跑多久。 * 目标目录已经存在时容易把新旧文件混在一起。 * 脚本化重跑时，参数和目录约定容易写散。 所以我写了一个小脚本：extract.sh。它不是为了炫技，而是把一次大包解压里最容易踩坑的地方都收起来。 它解决什么问题 这个脚本做的是一件很具体的事： 把 .tar.gz 或 .tgz 文件解压到普通目录，同时显示百分比、速度和 ETA；如果机器上有 pigz，自动使用多核解压。 典型用法： bash extract.sh archive.
部署运维
本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群，拓扑采用： 1 shard x 3 replicas 含义是：集群只有一个逻辑分片，三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时，只要 ClickHouse Keeper 仍然有多数派，剩余节点仍可继续提供读写服务。 规划节点如下： 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&
部署运维
上一篇聊完普通解析、泛域名解析、A 记录、TXT 记录、普通证书和通配证书之后，我对 DNS 的理解已经比以前清楚很多了。 以前我对 DNS 的理解基本停留在： 域名 -> IP 也就是： A 记录 后来才发现，DNS 不只是“把域名解析成 IP”。 它还承担了： 命名 寻址 验证 策略 委派 缓存 排障 这些角色。 这篇算是 DNS 的扩展篇，整理一下接下来还值得补的内容。 目标不是背概念，而是让自己以后遇到 DNS、证书、域名、Caddy、Cloudflare、阿里云解析这些问题时，能知道从哪里下手排查。 一、DNS 不只是
部署运维
最近在折腾 frp、Caddy、内网穿透和域名分流的时候，我突然发现一个问题： 我以前对 DNS 的理解其实挺片面的。 以前我理解 DNS，大概就是： 域名 -> IP 比如： weini.xin -> 服务器 IP www.weini.xin -> 服务器 IP 也就是说，我过去主要只知道 A 记录。 A 记录确实是 DNS 里最常见、最直观的一种记录，但这次深入折腾之后，我发现 DNS 远不只是“域名转 IP”这么简单。 它其实同时参与了： 域名寻址 服务入口命名 泛域名管理 证书验证
部署运维
这次踩了一个挺经典的坑：我在云服务器上折腾 frp 的时候，顺手开了 UFW 防火墙，结果把自己 SSH 入口给挡住了。 服务器没死，服务也没坏，但我就是连不上。 最后发现：不是服务器出问题，是我自己把自己关在了门外。 事情背景 我有一台云服务器，上面跑了一些服务： Caddy / Nginx Docker frp 一些 Go / Python / Node / Bun 服务 最近在折腾 frp，用来做内网穿透和服务分流。 因为涉及端口暴露，我当时想着：“要不顺手把 UFW 开起来，做一层本机防火墙？” 这个想法本身没错，但问题是：我这是一台云服务器。 云服务器本来就有一层安全组，比如阿里云安全组、腾讯云安全组、AWS Security Group 之类的。公网入口本来就可以在云后台控制。 结果我在云安全组之外，
Linux
最近我在折腾一个很实际的问题： 我有一台内网机器，上面跑着很多服务，每个服务都有自己的端口。现在我想把其中某些服务暴露到公网，让外部可以访问。 这个需求很常见。 比如我家里或者局域网里有一台 Ubuntu 机器，上面跑着： MCP 服务：8120 API 服务：8122 测试后台：8080 某个 Go 服务：9000 某个 Python 服务：7860 这些服务本身都在内网里，外部是访问不到的。 如果机器没有公网 IP，或者路由器不方便做端口映射，那传统方式就很麻烦。于是我用了 frp。 一开始我对 frp 的理解还比较简单： 它就是一个内网穿透工具，可以把内网端口暴露到公网服务器上。 但真正跑通之后，我对它的理解一步一步升级了。 一、frp 的核心逻辑：公网服务器帮内网机器“代收连接” frp 的结构其实很清晰： 外部用户
部署运维
记录一次从零开始部署 frp 的完整过程，包括原理理解、架构设计、踩坑排查，以及最终跑通的全流程。 背景 我有一台内网服务器，上面跑着一些本地服务（监听在 8900 端口）。同时我有一台云服务器，有公网 IP，上面已经用 Caddy 跑了一堆服务。 需求很简单：让公网能访问到我内网服务器上的服务。 方案：frp（Fast Reverse Proxy）—— 一个专注于内网穿透的反向代理工具。 frp 是什么 frp 由两个组件构成： * frps（server）：部署在有公网 IP 的服务器上 * frpc（client）：部署在内网机器上 它的工作原理： 1. frps 在公网服务器上启动，监听一个"控制端口"（默认 7000），等待客户端连接
AI
最近把一套 Embedding 服务完整落地了一遍：4 张显卡分别启动 vLLM 实例，用 Nginx 做统一入口和故障切换，再在上层挂一个 FastAPI 网关，把原始向量统一裁剪成 256 维并归一化，最终形成一套比较完整、可直接对外提供服务的 Embedding 架构。 这篇文章把整个过程完整整理一下，包含环境准备、离线模型部署、多卡启动、Nginx 配置、systemd 开机自启，以及业务网关设计。 整套架构的目标很明确： * 提供标准 HTTP Embeddings API * 支持四卡并行 * 支持统一入口与负载均衡 * 单实例故障时自动 failover * 支持开机自启 * 保留日志，便于运维与统计 一、整体架构 先看整体结构： Client │ ▼ FastAPI Gateway（8681） ← 推荐对外入口 │ ▼ Nginx（
AI
先把结论放前面：LTX-2.3（22B）这条 pipeline 在 4×RTX 3090（24GB）这套硬件上，按官方默认推理方式基本跑不起来。我最终得到的不是“没跑通”，而是一个更有价值的结果：把它为什么跑不起来、卡在哪、该怎么判断“物理不可行”，完整验证了一遍。 这篇文章是一次本地部署的工程复盘：从模型文件下载、依赖链补齐、环境和代码层踩坑，到显存拆分、多卡 device 规划，再到最终 OOM 的边界判断。希望你在遇到类似“看起来只要把权重放进去就能跑”的大模型工程时，可以少走很多弯路。 TL;DR（1 分钟读完） * LTX-2.3 不是单模型，而是一个多组件 pipeline：文本编码器（Gemma）+ 视频 diffusion 主模型（
陕公网安备61011302002223号