zabbix运行久了以后效率会变慢的原因分析

座机

　　公司zabbix 的规模500多台机器，日常操作感觉很卡，随着好奇心看了一下zabbix的实现。。发现了一些有趣的东西。。
　　首先是数据库特别的大，大概340g ，是我见的过比较大的。用的是mysql innodb ，里面表比较多，但是大多都比较平常，有一个特别之巨大，是history这个表，看了下，有30亿行数据。。
　　select table_name ,table_rows from tables  where table_schema='zabbix'  and table_name like 'history%';
　　+-------------------+------------+
| table_name        | table_rows |
+-------------------+------------+
| history           | 2881585282 |
| history_log       |          0 |
| history_str       |     720801 |
| history_str_sync  |          0 |
| history_sync      |          0 |
| history_text      |    5275879 |
| history_uint      |  352996499 |
| history_uint_sync |          0 |
+-------------------+------------+
　　这里table_rows这个并不是精确数值，是一个大概的值，每次查询得到的都不一样，而且相差个1，2亿是正常的。。要正确取得rows 的话只能count(*) ,但是运行一下的话全表遍历，估计要n久才能得出结果。
　　好吧，不去纠结具体多少，大概就是30亿数据这个数据量。
　　history的表结构如下，
　　Table: history
Create Table: CREATE TABLE `history` (
  `itemid` bigint(20) unsigned NOT NULL,
  `clock` int(11) NOT NULL DEFAULT '0',
  `value` double(16,4) NOT NULL DEFAULT '0.0000',
  `ns` int(11) NOT NULL DEFAULT '0',
  KEY `history_1` (`itemid`,`clock`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
　　说道这里就必须提一下zabbix的架构了，是一个典型的c/s架构，server段去拿agent 端的数据，然后把数据存在数据库里，这也是为什么运行server的时候一定要给出正确的连接数据库参数的原因了。
　　他很简单，叫拿到的数据按照itemid 存到数据库里面去，需要的时候select 出来，通过php 的frontpage 来展现给我们。
　　但是这个数据增长的有点快，已500个主机的监控为例，每个host默认有108项items ，当然有些不止108，可以自定义添加的。那么多是时间获取一次呢，这个也是不定的，system.cpu.load[,avg1],网卡流量net.if.in[eth0,bytes]等都是5s 一次的，system.cpu.util[,nice,avg1] 什么的都是10s一次，还有20s，30s ，60s等。
　　算他20s 平均，那么一天的数据流就是
　　500*100*20=20w  ,这个估算有作用，有个server 参数MaxHousekeeperDelete ，当开启自动清理history数据的时候，最大清理多少项，如果这个值设的太低，低于每天生成的数据，那么清理是无效的。
　　我看了下公司的zabbix 记录，可以看到1年前的图。。基本没起什么用，所以这个数据量才能达到惊人的30亿行！
　　大家都知道，在这么大的一个数据量上进行select ，不慢才怪了。。基本上生成一幅图表需要15s样子。。插入数据需要30多秒。。系统变的越来越臃肿，用户体验直线下降。。查询效率非常之慢！
　　那么写到这里大概找到整个系统运行慢的终极原因了。似乎有二条路可以分两步走，第一是手动把history数据给删掉点。。第二是设置正确的MaxHousekeeperDelete 参数。但是做之前先要备份数据库。这里没有实践。因为考虑到history有不少相关的其他的表
　　+-----------------------------+
| history                     |
| history_log                 |
| history_str                 |
| history_str_sync            |
| history_sync                |
| history_text                |
| history_uint                |
| history_uint_sync           |
　　把history删了以后，其他地方 导致不统一了怎么办？
　　这里我的做法 是先改大MaxHousekeeperDelete，每次多删有点，保持每天都在瘦的状态，那么最终会达到我们想要的效果。
　　怎么看是否有删除呢，我的做法是开启slow log ，基本上，这种操作都会被记录进slowlog 的，有记录那么肯定在删除了。而且5.1以后slow log都是可以动态开启的。不需要重启mysql。不要的时候关闭即可。非常方便。
　　========================================
　　隔了一段时间，再修改这篇文章，发现这个也是存在问题的，首先zabbix 卡不单是因为history这个表，还要一个events的表我觉得很有关系。还是，history 这个表时刻在insert数据，这么大量的删除，会和insert 争用锁？ delete的时候为了保证数据完整性，应该会用锁，而我觉得这个锁会对insert有 影响。
　　分析slowlog
　　Count: 10936 Time=18.11s (198094s) Lock=0.00s (0s) Rows=1.0 (10935), zabbix[zabbix]@2hosts
  SELECT e.eventid, e.value, e.clock, e.objectid as triggerid, e.acknowledged FROM events e WHERE e.object=N AND e.objectid=N AND e.value=N ORDER by e.object DESC, e.objectid DESC, e.eventid DESC LIMIT N OFFSET N
　　Count: 9435  Time=17.47s (164812s)  Lock=0.00s (0s)  Rows=1.0 (9434), zabbix[zabbix]@[192.168.0.75]
  select eventid,value from events where source=N and object=N and objectid=N and value in (N,N) order by object desc,objectid desc,eventid desc limit N
　　可以看到zabbix 一直在从events 数据库里面查询数据，这个表数据大概在8千万样子，1亿不到，物理数据有14G，
　　show engine innodb status
68.23 inserts/s, 0.50 updates/s, 11.75 deletes/s, 5300219.70 reads/s
　　发现大量的read 操作，再看这个sql 语句，14g的数据，虽然explain中有用到索引，我觉得这个量还是非常大的，如果减小这个表的规模，查询应该会很快。
　　这里我觉得有两个方法，一种是比较大胆的，删了events表的全部数据，当然14G的数据你不能这么干，否则老板也会把你干掉的。网上有种不错的方法是利用ln 硬连接,先drop了，然后再慢慢对付硬盘文件。
　　还一种是慢慢切割行，每天分钟删一点，那么一天累计起来也不错。这个数据要测试，不能太大，影响业务。