經過修改源碼突破zabbix單server監控數量

最近業務的快速增加，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