搜索響應時間不定時增加了一倍

我們的系統最近面臨CPU使用率高峯，其原因仍然未知。過去我們遇到了高內存使用率和磁盤警報，因爲我們每天都在運行批量索引的夜間工作，更新了幾乎所有的文檔。但高CPU使用率不成問題。搜索響應時間不定時增加了一倍

迄今收集的數據：

節點03（出6個數據節點和3主）從高CPU使用（> 95％）所受5分鐘，得到在1秒的響應時間尖峯，而平均響應時間是40毫秒。查看指標，給定高CPU節點上的索引計數有輕微波動，同時Young GC出現輕微波動（儘管在兩種情況下都沒有出現峯值）。

我不排除大量索引，因爲我們確實有一位卡夫卡消費者在任何時間接受大量索引數據，但是它的速度控制在每秒250個文檔，每個時間間隔爲250 ms批量呼叫。

此外，熱線程端點確實提供了一些數據，但我無法破譯它。

Hot threads

更新

更新了問題的標題，因爲以前的意見是錯誤的。主要問題是響應時間增加了一倍，並且CPU使用率並不高，因爲一段時間後使用情況已經穩定下來

已經有一些發展。在秒殺之後，CPU使用率逐漸下降並且正常。但是，我們的響應時間始終保持在100-250毫秒之間（平均值爲35-100毫秒）。

當前響應中存在接近齒鋸（不完全一致的齒鋸）模式。

而且，在老GC計數小凸點秒殺時有發生。

在節點統計信息中未發現任何異常。將在找到時更新。仍在張貼調查。

node stats

還發布了近期的熱點話題 -

hot_thread_2

來源

2016-09-21 Utkarsh Mishra

如果您有權訪問日誌，請檢查您在CPU峯值期間運行的查詢類型。排序結果是Cpu密集型的。您可能正在運行返回大量結果的查詢。只是猜測... – jay

@jay我們有一個硬編碼結果大小值的業務邏輯設置。還檢查了任何分析日誌。找不到任何東西。 –

所有熱門主題都與搜索有關。在秒殺期間你有沒有熱線轉儲？你的查詢有沒有改變？聚合？如果您在這些服務器上有任何監控設置，您是否可以檢查Node 03在峯值時是否正在經歷嚴重合並？ – jay

節點03肯定似乎已經經歷了沉重的索引。

   "bulk": { 
       "threads": 8, 
       "queue": 0, 
       "active": 0, 
       "rejected": 0, 
       "largest": 8, 
       "completed": 9528532

我比較節點04的統計與節點03.一些事情，我注意到在03

4144165個文檔，但256087749（index_total）建立索引的請求？
只有節點03有41個open_contexts。所以當你使用這個數據時，它有41個搜索請求。所有其他節點都是0。
與其他節點相比，節點03和節點01的合併數量非常高。

您是否有任何路由邏輯將特定文檔發送到特定節點？或者可能這些節點包含更頻繁更新的索引？

當你看到尖峯時，你還有什麼機會對節點03上的索引進行優化？查看節點統計信息，03是唯一具有「完成」優化的節點

"optimize": { 
       "threads": 1, 
       "queue": 0, 
       "active": 0, 
       "rejected": 0, 
       "largest": 1, 
       "completed": 1 
      },

另外，您的refresh_interval是什麼？ ES中的默認值是1秒。批量索引時可能會觸發大量合併。

來源

2016-09-21 23:30:30 jay

索引請求數量的增加可能是因爲我們的午夜工作幾乎全部更新了我們的文檔。此外，我們目前沒有邏輯路由搜索請求。目前，我們將所有搜索請求發送到前3個節點。此外，我們的批量索引主要在午夜時間運行，如果搜索響應在此期間上升，我們也可以。當前的refresh_interval設置爲1秒。 –

關於路由問題。我懷疑只有1個節點會收到所有的搜索請求。雖然我們沒有合適的路由邏輯，但我們的應用服務器會根據可用性向節點發送請求。即便如此，我們沒有儘可能多的搜索請求來控制任何單個節點。 –

搜索響應時間不定時增加了一倍

回答

相關問題