我的 redis 的 fork 時間很慢，對查詢性能有一點影響。我該怎麼做才能檢查？

我只使用了帶有 RDB 選項的 redis。它使用了 2GB 記憶體。當它分叉時，它用了大約 10 秒來完全保存文件。當我查看 redis.io 網站時，我發現了這個延遲統計：

- Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
- Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
- Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 millisecodns (9 milliseconds per GB).
- Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
- Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
- Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).

我使用專用伺服器 Xeon E3-1240 機器。與上面的這些結果相比，它使用了更多的時間來保存。是因為我所有的鍵都是散列嗎？我應該怎麼做才能減少延遲並減少對主要 Redis 程序查詢的影響？

從 Redis INFO輸出中，fork 時間和保存到磁碟的相關指標是：

rdb_last_bgsave_time_sec:0
latest_fork_usec:545

redis.io註釋討論的是分叉時間，而不是完全持久化文件在磁碟上的時間。

完全保存在磁碟上的時間取決於 CPU 和儲存（磁碟或磁碟）本身的速度。您需要查看vmstat或iostat輸出（假設您使用的是 Linux）。在作者的情況下，它畢竟是 2GB 儲存在磁碟上……密鑰是否是 Hash 無關緊要。然而，散列通常是一個很好的選擇，可以將更多內容放入記憶體中。

保存到磁碟的時間可能有很小的相關性或很大的相關性……這取決於您的 Redis 程序在保存到磁碟過程中受到的影響。

但又一次；請注意，分叉時間通常是實際問題，即使它是毫秒，這也是延遲通常發生的時間，因為它在（簡短）記憶體複製期間阻塞。就像我說的那樣，實際保存到磁碟可能是您需要擔心的事情，也可能根本不需要擔心。它在後台執行緒中執行。

引用自：https://serverfault.com/questions/569376