最近业务的快速增长，zabbix监控的VPS（Required server performance, new values per second）早已超过六位数，这也许是达到他的单server最大吞吐量。而zabbix server的CPU负载、内存使用率、网络IO、磁盘IO、MySQL的QPS等关键性能指标都不高（主要是server服务器的配置较高：64c/128G内存/SSD硬盘），这也许是达到他的单server最大吞吐量。架构为单server、单MySQL数据库、多代理的模式，出现几个代理数据队列延迟，报警异常的情况，此时只能清空代理节点的数据来临时解决。

通过观察zabbix server自身的性能指标，发现有几个指标在出现队列延迟时特别高：Zabbix busy history syncer processes达到100%，非常繁忙，（用于同步代理数据到server端，进而刷数据进数据库），Zabbix history write cache free、Zabbix value cache free基本为0，而查看zabbix server的配置文件看到已经设置为最大值。因为服务器的负载比较低，而zabbix server的负载比较低，显而易见服务器资源没有得到很好的利用。如果能通过源码修改这几个参数的上限，也许就可以给zabbix server的拆分争取到一定的时间。通过搜索这几个配置参数，在源码src/zabbix_server/server.c（server的配置参数最大值和最小值都在这里）找到了这几个参数的最大值，调整最大值，重新编译，启动，通过几天的观察，之前的现象消失，MySQL的QPS也上升不少（近30%）。

另外还有一个参数，当监控项和主机数量增多时，压力也比较大，Zabbix busy configuration syncer processes, in %（用于server同步监控源数据到代理）这个指标在源码中设置为1个进程，通过测试，这个值不能进行修改，否则多个线程同时查询数据库库，同样的SQL执行多次，效率反而更低，建议官方优化这个进程的同步流程，一次查出，多进程同步源数据，从而提升同步配置源数据性能。

建议官方适当放大这几个缓存值设置的最大值，这样能合理的利用服务器资源，提升zabbix server的最大吞吐量。同时建议官方出一个多server统一管理的UI，方便运维。作为运维，这种单server的架构比较省事，但是业务增长到一定数量的时候必须进行server拆分，统一管理监控数据等二次开发，确保监控服务的稳定运行。根据经验，通过数据库、硬件、server配置参数的优化，单server监控的VPS不建议超过5万，否则对运维的考验特别大。

另外服务器不好，监控业务量不大的，就不需要用这个方法修改了，没有意义。

src/zabbix_server/server.c 

StartDBSyncers-->100-->1000

CacheSize-->8--->64   #单位是G

HistoryCacheSize-->2-->64 #单位是G

HistoryIndexCacheSize-->2-->64 #单位是G

TrendCacheSize-->2-->64 #单位是G