HDUO Lab

标签： MySQL调优

  • 深入 Zabbix Proxy 雪崩排查：断网恢复引发的 Trapper 耗尽与 MySQL InnoDB 锁死实战

    某次排查过程中，某跨机房专线发生了一次约 15 分钟的抖动，导致该机房的 Zabbix Proxy 节点与中心 Zabbix Server 短暂失联。当专线恢复的瞬间，中心 Zabbix Server 瞬间陷入瘫痪：Load Average 飙升至 120+，监控大盘变成一片空白，所有告警通道静默。最终排查结论极其经典——典型的“重试风暴与并发写入雪崩”。Proxy 在离线期间囤积了海量历史数据，恢复网络后全量、高并发地向 Server 端倾泻。Server 端的 Trapper 进程瞬间耗尽，且底层 MySQL 因未做针对性调优，在海量并发 INSERT 下触发 InnoDB 严重锁等待（Lock wait timeout）与 IO 饱和，最终拖垮了整个监控体系。

    将企业级监控系统当成黑盒跑默认配置，是对生产环境的极度不负责任。监控系统的架构设计同样需要“防御性编程”思维，任何一个下游组件的故障恢复，都不应该成为压垮中心节点的最后一根稻草。

    案发现场：队列爆炸与 DB 假死

    故障发生时，登录中心 Zabbix Server，终端已经非常卡顿。第一时间查看系统指标与核心进程状态：

    1. 系统负载极高，IO 成为瓶颈 执行 top 发现 mysqld 进程 CPU 占用达到 600%，但更致命的是 %wa（IO Wait）高达 45%。

    2. Zabbix Server 内部运行状态崩溃 查看 /var/log/zabbix/zabbix_server.log，满屏的告警日志： text Zabbix server history syncer processes more than 75% busy Zabbix server trapper processes more than 75% busy [Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction [insert into history_uint (itemid,clock,ns,value) values ...] server is out of memory: out of memory (allocating 4294967296 bytes) Trapper（负责接收 Proxy 数据）和 History Syncer（负责将数据刷入 DB）进程全部处于打满状态。

    3. MySQL 锁等待与堆积 直连 MySQL 数据库，执行 SHOW PROCESSLIST，看到上百个状态为 update 的线程，全部卡在写入历史表： sql INSERT INTO history_uint (itemid,clock,ns,value) VALUES ... 查看 SHOW ENGINE INNODB STATUS\G，发现大量的 Record Lock 争用，Buffer Pool 命中率急剧下降，磁盘 IOPS 被写 Redo Log 和 Flush Page 彻底榨干。

    根因剖析：为什么一次断网恢复会引发全局瘫痪？

    问题的核心在于 Zabbix Proxy 的离线缓存机制 与 中心数据库的并发写入能力 极度不匹配。

    在分布式架构中，Zabbix Proxy 在与 Server 断开连接时，会将采集到的监控数据缓存在本地（默认是 SQLite 或轻量 MySQL/PostgreSQL）。当网络恢复，Proxy 会尝试将离线期间积压的数据（通过 DataSenderFrequency 控制周期）打包发送给 Zabbix Server（端口 10051）。

    雪崩的传导链条如下：

    1. Proxy 数据洪峰：一个承载了 10,000 NVPS（每秒新值）的 Proxy，断网 15 分钟会囤积约 900 万条数据。网络恢复后，Proxy 会以极具攻击性的方式将这些数据并发推向 Server。

    2. Trapper 耗尽：Zabbix Server 的 StartTrappers 进程负责接收这些数据，存入内存共享池。面对突发洪峰，Trapper 进程瞬间被全部分配完毕，导致其他正常的 Proxy 或 Agent Active 检查也无法建立连接，监控出现全局断点。

    3. History Syncer 阻塞：内存池迅速填满，StartHistorySyncers 进程开始疯狂从内存中提取数据拼接成 INSERT 语句写入 MySQL。

    4. MySQL InnoDB IO 饱和与锁死： 这是最致命的一环。如果 MySQL 采用了默认的 innodb_flush_log_at_trx_commit = 1，意味着每一次 History Syncer 的批量事务提交，都会强制触发一次 Redo Log 的 fsync 刷盘。 机械硬盘或普通 SSD 的 IOPS 瞬间被击穿。IO 阻塞导致 INSERT 事务执行变慢，持有的行锁或间隙锁迟迟不释放。新的写入请求被阻塞（Lock wait timeout），进而导致 History Syncer 挂起，最终内存池爆满，Zabbix Server 进程直接 OOM 崩溃。

    止血与根治方案：防御性监控架构的落地

    面对这种雪崩，常规的重启服务毫无意义，启动后几秒钟内又会被积压的数据再次击穿。正确的止血操作是：先切断洪峰源头，再提升消化能力。

    紧急止血操作：

    1. 停掉故障节点的 zabbix_proxy 服务。

    2. 重启中心 zabbix_server，让其消化掉内存中和 DB 中积压的残余事务，确保其他机房的监控恢复正常。

    3. 如果 Proxy 积压数据已经失去时效性且无关紧要，直接清空 Proxy 侧本地 DB 的 proxy_history 表（极其暴力的断臂求生，视业务容忍度而定）。

    深度调优与根治配置（必须落地的最佳实践）：

    1. MySQL 底层性能释放（关键） 监控数据是典型的“写多读少、允许极少量丢失”的时序数据。严格的 ACID 对 Zabbix 历史表来说是性能毒药。

    # /etc/my.cnf
# 牺牲极为罕见的 MySQL 宕机（非 OS 宕机）时 1 秒的数据，换取成百上千倍的写入性能提升
innodb_flush_log_at_trx_commit = 2 

# 将 Buffer Pool 设置为物理内存的 60%-70%，让尽可能多的数据在内存中合并写入
innodb_buffer_pool_size = 64G 

# 提升 IO 线程数，榨干 NVMe SSD 的并发能力
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000

    注：对于 TB 级别的企业级 Zabbix，强烈建议对 history 和 history_uint 表实施按天/周的 MySQL Table Partitioning（表分区），利用 DROP PARTITION 替代 Zabbix 自带的 Housekeeper 删除过期数据，这能彻底解决 Housekeeper 引发的数据库 CPU 毛刺死锁。

    2. Zabbix Server 并发与缓冲调优 扩展 Server 的吞吐管道，并增加共享内存以缓冲洪峰。

    # /etc/zabbix/zabbix_server.conf
# 增加处理 Proxy 数据的 Trapper 进程（视代理数量和内存而定）
StartTrappers=50
# 增加历史数据同步进程，加速刷盘
StartHistorySyncers=30
# 扩大缓存池，避免瞬间 OOM 或假死
CacheSize=8G
HistoryCacheSize=2G
HistoryIndexCacheSize=512M

    3. Proxy 侧的防御性限流 控制离线数据的囤积量和发送频率，避免在恢复时“一波流”带走中心端。

    # /etc/zabbix/zabbix_proxy.conf
# 离线数据最多保留时长（小时）。断网太久的数据直接丢弃，保全大局
ProxyOfflineBuffer=2
# 控制 Proxy 发送数据的频率，避免过高的并发连接
DataSenderFrequency=1

    排查清单：Zabbix 并发写入雪崩同类问题速查

    1. 检查 Zabbix Server 内部队列与进程瓶颈：使用 zabbix_get -s 127.0.0.1 -k "zabbix[process,history syncer,avg,busy]" 获取内部指标，超过 75% 即需警惕 DB 写入瓶颈。

    2. 排查 MySQL InnoDB 锁等待：在 MySQL 执行 SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'LOCK WAIT'; 揪出阻塞源头，通常是 Housekeeper 与 History Syncer 发生了锁冲突。

    3. 确认磁盘 IO 饱和度：使用 iostat -xz 1 观察 %util 和 await，如果 %util 长期 100% 且以写 IO 为主，必须立刻调整 innodb_flush_log_at_trx_commit。

    4. Housekeeper 负载自查：如果未开启 DB 表分区，检查 zabbix_server.log 中 housekeeper 每次删除数据耗时，若超过 1 分钟，必须调整 MaxHousekeeperDelete 或尽快实施分区改造。

  • 深入 Zabbix 监控雪崩排查：自定义 LLD 滥用引发的 MySQL IO 饱和与 History Syncer 阻塞实战

    近期处理了一起极为惨烈的监控系统雪崩事故。故障表现为 Zabbix Server 队列疯狂飙升，延迟监控项（Queue over 10 minutes）达到数十万，所有告警延迟触发甚至丢失，DB 节点的 Load Average 飙到 80+，底层 NVMe 磁盘 %util 锁死在 100%。最终排查结论：业务研发在未经评审的情况下，引入了一个存在严重缺陷的自定义 LLD（Low-Level Discovery）模板，将大量高频更新的容器环境变量作为 Text 类型全量上报。这直接撑爆了 history_text 表，触发了 Zabbix 内部 Housekeeper 的疯狂 DELETE 清理操作，导致 MySQL InnoDB 产生海量随机 IO 与 Undo Log 积压，最终拖垮 History Syncer 进程，引发监控全局假死。

    把关系型数据库当成时序库甚至日志库来用，是监控系统运维中最不可原谅的低级错误。自定义监控脚本返回几百 KB 的冗余字符串，还要每隔 30 秒上报一次，这种粗暴的做法不仅毫无数据价值，更是对底层存储 IO 的公开处刑。

    排查过程的 Dashboard 是一片刺眼的红。首先看 Zabbix Server 的自身监控，核心指标 Zabbix server history syncer processes more than 75% busy 和 Zabbix server history cache, % used 均已触顶 100%。 这说明 Zabbix Server 接收到的数据已经塞满了内存中的 History Cache，但负责将 Cache 刷入数据库的 History Syncer 进程被严重阻塞，无法写入。

    顺藤摸瓜，直接登录 Zabbix 的 MySQL 后端节点，抓取现场指标：

    # 查看磁盘 IO 情况
$ iostat -x 1
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1           0.00     0.00  120.50 8500.20  1928.00 136003.2  31.97    145.20   16.80   25.50   16.60   0.12 100.00

# 查看 MySQL 进程状态
$ mysql -e "SHOW FULL PROCESSLIST;" | grep -i "history_text"

    不出所料，SHOW PROCESSLIST 中堆积了大量处于 updating 状态的 SQL，其中最致命的是这条： DELETE FROM history_text WHERE itemid=105432 AND clock<1690000000

    此时再看 InnoDB 引擎状态：

    mysql> SHOW ENGINE INNODB STATUS\G
---TRANSACTION 4598234, ACTIVE 45 sec fetching rows
mysql tables in use 1, locked 1
100345 lock struct(s), heap size 8345120, 5345020 row lock(s), undo log entries 3450920

    Undo log entries 达到 300 万级别，History List Length 严重超标。到这里，整个雪崩的逻辑链条已经非常清晰了：

    1. 毒模板泛滥：业务层添加了自定义的 LLD 规则，自动发现并生成了近 50 万个 Text 类型的 Item。这些 Item 每 30 秒抓取一次，数据载荷大。

    2. 写放大与表膨胀：history_text 表在短时间内急剧膨胀。对于 MySQL InnoDB 而言，大批量变长字符串的写入会引发严重的页分裂（Page Split）。

    3. Housekeeper 绞肉机：Zabbix 默认启用了内部的 Housekeeper 来清理过期历史数据。当它试图通过 DELETE 语句清理数亿条历史记录时，由于 clock 字段的索引效率在庞大的表体量前急剧下降，操作退化为缓慢的范围扫描。

    4. IO 饱和与雪崩：巨量 DELETE 产生了惊人的 Undo Log 和 Redo Log，将 NVMe 的写带宽榨干。History Syncer 进程在执行 INSERT 时等不到锁和 IO 资源，集体挂起。History Cache 随之满载，Poller 无法继续收集数据，监控队列彻底爆掉。

    解决这种系统级阻塞，第一步必须是止血，而不是优雅地等待 SQL 执行完毕。

    第一步：暴力阻断清理任务并清理毒模板 直接在 DB 端 Kill 掉所有 Housekeeper 相关的 DELETE 线程，同时在 Zabbix Server 配置中紧急禁用内部清理：

    # /etc/zabbix/zabbix_server.conf
HousekeepingFrequency=0

    重启 zabbix-server 服务。随后在 Web 端找出那个罪魁祸首的 LLD 模板，强制 Unlink and clear，并批量禁用相关主机上的遗留 Item。

    第二步：DB 层面的历史表彻底改造（MySQL Partitioning） Zabbix 原生 Housekeeper 依赖 DELETE，这在千万级以上的监控规模中是绝对的性能毒药。防御性运维的最佳实践是：永远不要用 DELETE 清理 Zabbix 历史，全部改用表分区（Table Partitioning）并通过 DROP Partition 来回收空间。

    对 history、history_uint、history_str、history_text 以及 trends 系列表实施按天/月分区：

    -- 以 history_uint 为例，按天分区
ALTER TABLE history_uint PARTITION BY RANGE (clock) (
    PARTITION p20231001 VALUES LESS THAN (UNIX_TIMESTAMP('2023-10-02 00:00:00')),
    PARTITION p20231002 VALUES LESS THAN (UNIX_TIMESTAMP('2023-10-03 00:00:00')),
    ...
);

    配合 Crontab 每天执行存储过程，自动 ALTER TABLE history_uint DROP PARTITION p_old，耗时仅需几十毫秒，彻底根除 IO 灾难。

    第三步：Zabbix Server 核心参数调优 为了防止未来再出现单点突发流量打挂整个 Server 的情况，必须对 Cache 和 Syncer 进行硬性隔离和扩容：

    # 提高历史缓存，给 DB 抖动留出缓冲池 (根据 RAM 大小调整)
HistoryCacheSize=2G
HistoryIndexCacheSize=256M
ValueCacheSize=1G

# 增加 Syncer 进程数，但不要超过 CPU 核心数的一半
StartDBSyncers=16

# 限制自定义脚本超时时间，防止 Poller 假死
Timeout=10

    经过上述改造，截断庞大的 history_text，重构分区表后，Zabbix Server 的 Queue 在 5 分钟内迅速清零，IO 恢复到个位数，系统平稳落地。

    同类问题排查清单（Zabbix 性能速查）

    1. 观察 History Cache 使用率 若 Zabbix server history cache, % used 持续走高，说明后端 DB 已经成为瓶颈。切勿盲目增加 Zabbix Poller 数量，这只会加重 DB 负担，应优先排查 MySQL IO 及慢查询。

    2. 检查 Housekeeper 状态 查看 Zabbix Server 日志中 housekeeper 每次执行的耗时。如果耗时超过几十分钟甚至小时级，必须立即停用内部 Housekeeper，改用 MySQL 数据库表分区（Partitioning）策略。

    3. 排查 Unsupported Items 与高频 LLD 使用 zabbix_get 测试自定义脚本耗时。严格限制 LLD 的发现频率（通常建议 1 小时以上），并慎用 Text 和 Log 类型监控项。对于单纯的日志采集，请移步 ELK 或 Loki，Zabbix 不是日志垃圾桶。

    4. MySQL InnoDB 参数防御 确保 innodb_buffer_pool_size 分配了机器物理内存的 60%-70%；innodb_flush_log_at_trx_commit 在极致性能要求且允许少量数据丢失时可设为 2；innodb_io_capacity 需根据底层 SSD/NVMe 性能调高（如设为 10000+）。