您好,登錄后才能下訂單哦!
Redis持久化過程一直是影響redis性能的常見因素,如何監控持久化以及如何優化持久化過程呢?下面我們就一起來看看吧。
fork的監控及優化
不管是使用哪種持久化,RDB持久化或AOF重寫,主進程都會fork出一個子進程,在子進程里完成rdb文件的生成或aof的重寫。fork操作對于操作系統來說屬于比較重的操作。fork階段,redis會阻塞一段時間。阻塞時間和redis數據占用的內存大小成正比關系,每1G內存fork耗時在20毫秒。
如想知道fork階段的阻塞時間,可以使用info stats命令,查看latest_fork_usec選項的值,單位是微秒。記住是微秒,不是毫秒。
# redis-cli info stats | grep latest latest_fork_usec:323
優化fork的方法:
控制redis占用的內存大小。若占用內存過大的話,可以將應用拆分開,在多個服務器上部署,分攤redis的內存占用。
適當降低fork的操作頻率。
內存的監控
RDB持久化的日志如下:
…… 21692:C 15 May 2020 14:17:06.935 * DB saved on disk 21692:C 15 May 2020 14:17:06.936 * RDB: 2 MB of memory used by copy-on-write ……
可以看到RDB持久化過程消耗了2M內存。
AOF持久化日志如下:
…… 15786:C 23 May 2020 07:39:59.145 * AOF rewrite: 2MB of memory used by copy-on-write 10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite terminated with success 10679:M 23 May 2020 07:39:59.201 * Residual parent diff successfully flushed to the rewritten AOF (0.02 MB) 10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite finished successfully
可以看到,aof重寫占用的內存為2MB+0.02MB=2.02MB
如想監控持久化過程中內存占用情況,可以編寫shell腳本,統計出redis日志里相關信息。
硬盤的監控
Redis持久化過程會對硬盤造成壓力,因為持久化后,內存的數據會保存到硬盤中。
linux系統監控硬盤的命令有sar、iostat等,如發現硬盤io壓力超過閥值,再根據redis的日志對比下持久化的時間,看看是不是由于redis持久化造成的壓力。
優化方法這里提兩點:
使用性能好的磁盤,機械硬盤肯定比不了固態硬盤。
如果是單機上配置了好幾個redis實例,可以分別寫入不同的磁盤里,減輕磁盤的寫入壓力。
單機多實例部署
因為redis是單線程架構,如果一個服務器上只部署一個redis實例,那么對于多核cpu來說是一種浪費。所以,通常會在一個服務器上部署多個redis應用,比如開啟三個redis服務,端口號分別為6379,6380,6381。6379用來做緩存服務,6380用來做消息隊列,6381用來做標簽及推薦系統。
這樣確實可以充分利用cpu,但會容易產生問題。如果多個實例同時在進行持久化,那么對于cpu、內存及影片的壓力是非常大的。好的做法是將他們隔離開來,同一時間只有一個實例在進行持久化。
實現該效果的偽代碼如下:
while (true) { $redisObj = [6379,6380,……]; foreach ($redisObj as $obj) { // 該實例是否構成重寫的要求 if (rewriteConf($ojb)) { // 該實例進行持久化 } } }
foreach用來遍歷每一個redis實例,然后對該實例是否達到重寫的條件做判斷,滿足就開始進行重寫。這樣就可以將多redis實例持久化進行隔離。
以上就是Redis持久化過程的監控及優化的詳細內容,更多請關注億速云其它相關文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。