Redis 運維實際經驗紀錄之一

ref: http://blog.nosqlfan.com/html/324.html?ref=rediszt

這是某人的一個實際運維經驗，很不錯的！

[@more@]

本文轉自一米六二部落格（nice name），是將Redis用在較大型資料上的一個運維例項，作者為yahoo!中國的後端工程師，其收集整理的在亦在網上廣為流傳。

原文連結：

Redis 改版的專案上線有兩個月了，記錄一下Redis 相關的經驗，也給大家一個參照:

我們的Redis Server是一主一從，使用R710的機器，8核心，24G記憶體。 每天約插入200萬左右的資料，現在庫裡有3000萬條紀錄，佔用了9G的記憶體。由於現在每天記憶體增長太快，擔心很快會無法負載，因此寫了指令碼每天將過期資料刪除。

現在執行中的問題:

1、Redis執行基本穩定，從沒有自己中斷過服務，php指令碼去set的話大概1秒鐘能設定1萬條小資料，並沒有官方給出的資料高。但是修改配置後大重啟服務時大概需要1到2分鐘才能完全將硬碟中的資料載入到記憶體中去，在載入完之前，Redis不能提供服務。

2、Redis的預設配置中，每60秒如果紀錄更改數達到1萬條就需要dump到硬碟中去，但實際上由於超過了這個數，我們的Redis幾乎不停地 在dump資料到硬碟上。dump資料到硬碟時，我估計為了達到一個原子的效應，避免資料丟失，Redis是先把資料dump到一個臨時檔案，然後重新命名 為你在配置檔案設定的資料檔名。而前面說到，載入資料要1到2分鐘，dump資料應該也在1分鐘左右吧。dump出來的檔案差不多1到2個G。這樣，服 務器幾乎一直保持著每分鐘寫一個2G的檔案的這種IO的負載。磁碟基本不閒著。

3、還是在dump中，除開磁碟不閒著以外，CPU也一路飆升:Redis是fork一個子程式來dump資料到硬碟，原有程式佔用30%+的CPU，而dump資料的子程式單獨享用了一個CPU核心，cpu佔用100%。

4、 Redis在dump資料的時候，是fork子程式，這樣產生一個問題:Redis本向佔用了9G的記憶體，在dump資料時又fork一個程式，子程式繼 承了記憶體分配，也佔用了9G的記憶體…。Redis一下子佔用了18G的記憶體了。（NoSQLFan：由於fork呼叫的記憶體會採用作業系統的COW機制， 所以記憶體不會馬上加倍，只有在最壞的情況下，也就是在dump的時候主程式中的資料完全被修改了才COPY出兩倍的記憶體來。）

發現這些問題後，我修改了Redis的配置檔案，設定為30分鐘內只要有一次寫修改就dump資料，這樣系統負載大幅減輕了。

處於設想中的想法:

主Redis並不dump資料，不管寫多少次都不dump到硬碟，或是這個dump的時間非常長。從Redis則主要承擔合理地dump資料到硬碟以起備份作用。主Redis啟動時先從從Redis中scp或是ftp download資料回來。有待後續驗證。