Zabbix数据库增长过大（PostgreSQL后端）

没有看到大桌子的统计数据（特别是它们被真空吸尘器真空吸尘器），我的主要build议是限制你保存的历史数量（具体来说是什么进入历史*表格，而不是趋势*表格）。

一般来说，Zabbix通过将历史（详细观测）转化为趋势（汇总观测）来pipe理收集的数据量; 这个想法是在一段短暂的时间内保持历史logging，一分一秒地查看确切的数据可能是有意义的，但是对于较长期的研究来说，汇总的数据是足够的。 而且，这意味着历史表（忙于添加数据）也更小，趋势表可以更大，但写入活动更less。

这听起来像是你正在做的相反，没有趋势数据，但所有的历史？ 是有原因还是意外？

除此之外，它在一瞬间变得相关：分区是一种工具，它不会解决你的直接问题，但是在这样的非常大的数据集上工作，它将成为你的朋友。 也就是说，分区（主要）需要历史logging和趋势保留，所以必须保持所有项目的时间长度相同，以便随着时间的推移可以删除相关的分区。 回到主要答案…

我所做的是看不同的项目，并决定如何使用它们，只要我真正需要的只是保持历史，并且保持趋势，只要一直保持良好。 例如，我有相当多的理智检查，如果有些东西不好意思，但是通常是返回0的项，“OK”或者其他的。 保留这几天是没有意义的。 但是，这个项目特定的保留与分区不一致，所以你决定。

更相关的是你的投票和多久。 积极筛选出没有人看的东西，我把我们的项目数减less了10倍。 其中一个最大的是接口 – 一些具有一个物理接口的设备可能有6或10个虚拟接口; 肯定（有人会说）他们有意义，但是是否有人正在查看从他们收集的数据？ 子接口，回送接口，（一些）虚拟接口等。networkingpipe理员通常会认为“我会保留所有的东西以防万一”，但是很less有用 – 对项目数据进行深入探讨，看看你有多大的接口你永远不需要知道。 或者最坏的情况，你可能不得不再次开始监测。 把他们从低层发现。

当你在那里，看看你正在收集的接口。 同样的想法; 人们经常收集SNMP显示的所有内容，因为他们可以。 假装你正在为每个数据项目付款，并问自己，如果你是通过项目付款，是否值得保留。 （从某种意义上讲，数据存储是明智的，你是）。 如果你已经做了几年的监测，问问自己，你是否需要一些碎片失败（一个简单的例子，听起来像一个真正有用的项目，也许是一些人）。 如果你说5出现，你会怎么做？ 如果它不可行，为什么要保留它？ 如果这是一种实时react native的东西，为什么要从历史的angular度来看它呢？

当你在那里的时候，问你为什么在某些项目上轮询的速度如此之快。 考虑数据包/字节计数的问题 – 当然，每60秒观看一次实时历史logging的图表就好了，但它是否可操作？ 它是否每180秒教你一个以上？ 每300秒？ 你可能很快收集了很多这样的数据 – 你会用它吗？ 我有networkingpipe理员说“但我需要对问题迅速作出反应”。 那么你会发现它们存在延迟和滞后现象，以避免误报和震荡。

放弃你收集的东西，多久你的历史将缩短10（+/-）倍，而不会显着影响其效用。 然后减less你详细logging的时间（vs趋势），它可以下降2或4倍。

漫长而漫长的答案，但基本上：如果不可行，不要保留。 如果你猜错了，你总是可以放回去。

最后：确保自动真空有效地工作，考虑把pipe家的删除最大值设置为0（一次全部删除），但是后来仔细地监视阻塞（在具有足够的内存/处理/磁盘速度的大小合适的系统上，这可以显着加速房屋保持，但是如果它试图同时做太多的话也会有风险）。

好的，最后真的是：如果你决定按照build议去做，并消除很多项目，考虑你是否可以重新开始数据。 清理数百个内务数据将是一个巨大的挑战。