最近經常收到業務方配置的ES查詢延遲告警，同樣的請求手動在Kibana控制台執行隻需幾十毫秒就傳回結果。受影響的整個鍊路情況如下，php應用程式通過部署在ES叢集各節點上的nginx通路ES請求查詢資料。
查詢延遲原因可能有2個方面的因素：
1、ES叢集異常，ES應用故障或者叢集節點主機故障。
2、業務請求異常，業務請求量突增高于正常的水準。
業務上的請求異常主要通過分析ES各節點nginx代理的通路日志錯誤日志，前端web服務以及php的日志。
寫入方用戶端寫ES的請求記錄，請求時間，狀态碼，響應時間。
找到ES叢集中告警延遲索引的相關文檔确切的寫入時間。
找到查詢方用戶端的查詢記錄，請求時間，狀态碼，響應内容。
TIPS：
檢視監控圖表發現業務通路并無異常，使用sar -B檢視記憶體ES節點記憶體情況，發現在問題時間點各節點的pgscand/s一列數值較高，說明核心線程kswapd回收記憶體，由于系統free記憶體不足，當應用突然需要額外記憶體。使用者程序或線程配置設定記憶體或發生缺頁中斷時，會在使用者線程上下文中直接進行回收記憶體(pgscand)和配置設定記憶體。
建議根據機器的規格調大以下兩個值，32C64G機器可以調大至2-4G
vm.min_free_kbytes系統所保留白閑記憶體的最低限
vm.extra_free_kbytes系統保留給應用的free記憶體