Redis性能問題？

我試圖在我的Redis上加載一些重負載用於測試目的，並找出任何上限。首先，我使用大小爲32個字符的大小爲32個字符的50,000和100,000個鍵來加載它。這兩個密鑰大小的時間不超過8-15秒。現在我試着把4kb的數據作爲每個鍵的值。首先10000個按鍵需要800毫秒設置。但從這一點開始，它會逐漸減慢，並設置完整的50,000個按鍵需要40分鐘。我正在使用帶有node_redis (Mranney)的NodeJ加載數據庫。我正在做什麼錯誤，或者是Redis對於大小爲4 KB的大值緩慢嗎？Redis性能問題？

我現在發現的另外一件事情是，當我運行另一個客戶端並行到當前的客戶端並更新密鑰時，第二個客戶端在8秒鐘內完成加載50000個密鑰與4kb值，而第一個客戶端仍然永遠做它的事情。它是節點或Redis庫中的錯誤嗎？這是令人震驚的，並且不適合生產。

來源

2011-04-18 Lalith

您是否使用hiredis？ – generalhenry 2011-04-18 23:16:15

嗯..我安裝hiredis，但我不知道它是否自動加載到程序中，當我需要（'redis'）。這是問題嗎？ – Lalith 2011-04-18 23:17:39

要驗證是否安裝了hiredis模塊，可以運行節點，然後執行'require（「hiredis」）'。 – 2011-06-30 19:23:37

您需要爲從節點到Redis的批量寫入獲得某種背壓。默認情況下，節點將對所有寫入進行排隊，並且不對傳出隊列大小強制實施上限。

node_redis有一個「漏」事件，您可以監聽以實現一些基本的背壓。

來源

2011-04-25 09:51:35

嗨馬特，我試着查看client.command_queue.length並停止，直到我收到「漏」事件。 client.command_queue.length始終是0.所以我正在檢查client.offline_queue.length，它給了我正確的數字，但漏失事件只被解僱了一次，我會再試一次，並回來與代碼。謝謝。 – Lalith 2011-04-27 18:01:21

我已附加代碼在這裏https://gist.github.com/945441。這似乎不是反壓的正確方法？ – Lalith 2011-04-27 23:11:23

這裏有幾個不同的問題。首先是預連接命令排隊。第二個是，一旦你有一個連接，另一個隊列維護髮送的命令，但尚未收到答覆。我已經添加了一個處理這兩種情況的一般方法的示例：https：//github.com/mranney/node_redis/blob/master/examples/backpressure_drain.js – 2011-06-30 20:44:59

默認的redis配置沒有針對這種用法進行優化。我懷疑你已經把它交換到32字節的頁面大小的磁盤，這意味着每個添加的密鑰必須找到128個連續的空閒頁面，並且最終可能會使用系統虛擬機或需要擴展交換文件。

更新密鑰時，空間已分配，因此您看不到任何性能問題。

來源

2011-04-19 00:56:57

這只是爲了測試目的，所以我不在乎。但是如果這種需求實時發生並且我的應用程序需要存儲如此多的數據呢？有沒有可以改變的配置以符合我的要求？ – Lalith 2011-04-19 02:56:48

甚至在第一個客戶端創建所有50000個密鑰之前如果我運行第二個客戶端，它將繼續並在第一個客戶端之前完成。所以你所說的可能不是我所面臨的問題。 – Lalith 2011-04-19 02:57:52

頁面大小和內存使用情況是可配置的 - 檢查redis.conf中的註釋。第二個客戶端完成並不一定排除該情況 - 低內存條件和併發的組合可能變得相當複雜，特別是如果涉及超時和自動重試。例如，每次出現錯誤時是否可以重置所有以前的鍵？ – 2011-04-19 04:37:28

因爲我在NodeJs中做了很多set（Key value），這是異步完成的，所以很多套接字連接同時打開。 NodeJs套接字寫入緩衝區可能會被重載，並且GC可能會來操作節點進程。

PS：我改變了redis內存的配置，Tom建議，但它仍然執行相同的操作。

來源

2011-04-20 22:03:24 Lalith

Redis性能問題？

回答

相關問題