网上搜了半天zabbix调优，最后结果都是一样的复制粘贴，主要都是1.8的，在这个2.0的时代，很让人难受。
在13年年末，zabbix推出了性能提升一倍的2.2版本。本�沤�线上zabbix数据库的备份导出在测试环境升级到2.2，在升级数据库这个环节，耗时近一周，因此本�畔衷谙呱嫌玫幕故�2.0
zabbix2.0哥们是去年7月份开始正式使用的，在这小半年的时间里，history和history_uint两张表加起来存了50亿条数据，这不得不让我对zabbix的性能表示五体投地的佩服。
说道调优，就得说说现在运行的状态：哥们部署的这套环境目前监控着1000多台机器，3w个活跃的监控项，每秒采集800个数据（这个值最高到过900+），用了三台服务器（一台server，一对mysql主从库）目前运行良好。
在这我仅将本�耪馕⒉蛔愕赖木�验陈列下，喷子们请见谅，恕小弟无知，谢谢。
我认为优化zabbix其实就是优化这几部分：架构、模板、server配置、数据库、用新版本
架构：用分布式。
虽然本�呕姑徽�式在线上用proxy，但我还是心仪已久，没啥经验，只是感觉和大牛们都这么认为，所以我也潜意识的这么想，分布式应该比cs性能强。
模板：一定要自定义监控项，尽量减少没用的以及设置合理的监控周期。
监控项我想说，第一点用不到或者功能重复的一定要去掉，最好是自己定制自己的模板，在定制过程中，削减监控项的个数是一点，第二点是一定要根据自己的实际情况，配置监控周期，我这点就没做好，现在都是30s采集一次，其实对于很多监控项而言，这么频繁没必要；第三点就是收集数据以及展示数据的方法，我就一个想法（能用zabbix自带的就别用自定义的）其他的官方总结的很到位，我就引用下：
| 因素 |
慢 | 快 |
|---|---|---|
| 数据库大小 | 特别大 | 适应内存大小 |
| 触发器表达式复杂程度 |
min(),max(),avg() | last(),nodata() |
| 数据收集方法 |
Polling(SNMP,No Proxy,被动式Agent) | Trapping(主动式Agent) |
| 存储数据类型 |
文本，字符串 |
数字 |
服务器端配置：就像其他帖子说的，优化进程数，角色分离等等。
我的前端是tengine+php，这里的优化工作我认为不是主要的，webserver用在zabbix上，基本没有瓶颈，可以在网上搜搜，做些简单的优化就行了。
重头戏在zabbixserver的配置上，默认的，server起的进程非常少，而且事实证明，数据级到了亿这个级别的时候，hoursekeeper的作用可以忽略不急了，所以我炒了他。我贴下我的配置吧：
LogFile=/tmp/zabbix_server_2.0.log PidFile=/tmp/zabbix_server_2.0.pid DBHost=******* DBName=******* DBUser=****** DBPassword=****** DBPort=3306 ListenPort=10051 SNMPTrapperFile=/tmp/zabbix_traps_2.0.tmp StartPollers=256 StartProxyPollers=4 StartDBSyncers=8 StartHTTPPollers=8 StartPingers=8 StartTrappers=64 StartPollersUnreachable=64 StartDiscoverers=32 HistoryCacheSize=128M CacheSize=1024M TrendCacheSize=32M #MaxHousekeeperDelete=10000 DisableHousekeeping=1 UnreachableDelay=60 UnavailableDelay=60 UnreachablePeriod=60 TrapperTimeout=300 Timeout=10
这是一台8g内存的机器的配置，server对内存和cpu的要求还是挺高的，这个之前没有规划好，建议用16g以上的机器。
数据库：我只用过mysql，所以这我就说mysql。
数据库：
mysql配置调优可以参考http://shanks.blog.51cto.com/3899909/1307636
我要说的重点是mysql的分区表，多了不说，直接上操作：
在create分区表时，需要对所有数据都做好分区，否则会报错，也就是说你要保证这条create的时候，该表内所有数据都能找到各自的分区。建分区的时候，实际上就是把数据导出再导入，因此这期间，该表是只读的。
在2.0中，history、history_str、history_uint、trends、trends_uint、events这几张表大家应该比较熟悉，大量的历史数据都存在这几张表中，我们现在就对这几张表做分区：
1、分别create
以history为例：
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 partition by range (clock) (partition p201307 values less than (unix_timestamp("2013-07-01 00:00:00")),partition p201308 values less than (unix_timestamp("2013-08-01 00:00:00")));
1.1 alter已有的表
alter table history_uint partition by RANGE (clock) (partition p201306 values less than (unix_timestamp("2013-07-01")),partition p201307 values less than (unix_timestamp("2013-08-01")),partition p201308 values less than (unix_timestamp("2013-09-01")));
2、发现分区已经超时了，需要添加
以history为例：
alter table history add partition (partition p201309 values less than (unix_timestamp("2013-10-01 00:00:00")));
这么做之后，你会发现当你查看近一个月的数据的时候，数据出来的比较快，同时有可能之前的图像断点问题也解决了。然后写脚本定期的去删除分区，同样可以做到删除垃圾数据的效果。