Redis伺服器高cpu調試策略

最近，我們注意到由 redis 引起的生產環境中的 CPU 峰值，如下所示：

為了解決這個問題，我每天大約重新啟動兩次 redis 伺服器 :( 這顯然遠非理想。我想找出根本原因。

到目前為止，我已經研究過以下一些事情：

1. 查看 redis 日誌文件中的任何異常情況。以下似乎是可疑的：

2. 研究 nginx 訪問日誌，看看我們是否遇到異常高的流量。答案是不。

3. New Relic 透露該問題始於 11 月 21 日，16 日`（大約一個月前），但當時沒有發布任何程式碼。

以下是有關我們設置的一些詳細資訊：

Redis 伺服器： Redis server v=2.8.17 sha=00000000:0 malloc=jemalloc-3.6.0 bits=64 build=64a9cf396cbcc4c7

PHP： 5.3.27使用 fpm

Redis配置：

daemonize yes
pidfile /var/run/redis/redis.pid
port 6379
timeout 0
tcp-keepalive 0
loglevel notice
logfile /var/log/redis/redis.log
syslog-enabled yes
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error no
rdbcompression yes
rdbchecksum yes
dbfilename redis.rdb
dir /var/lib/redis/
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
maxmemory 15GB
appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-max-len 128
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
include /etc/redis/conf.d/local.conf

框架：帶有 Cm_Cache_Backend_Redis 的 Magento 1.7.2

如果給出上述資訊，請告訴我是否可以採取任何措施來減輕 CPU 的高使用率。

非常重要的更新：

您的伺服器可能已被黑客入侵。導致 CPU 使用率高的不是 redis，而是一個名為 yam 的單獨命令（看看你的 htop 的最右邊，我第一次錯過了它）。yam 命令用於眾所周知的 redis 漏洞利用，通常會導致 CPU 使用率過高。您需要仔細檢查以確保您的伺服器是安全的。

如果您想了解有關該漏洞以及如何保護自己的更多資訊，可以參考以下文章和連結：

• https://gist.github.com/lokielse/d4e62ae1bb2d5da50ec04aadccc6edf1（一個範例女士黑客腳本，在評論中您可以看到原始版本下載山藥的位置）
• https://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.zkreading.com/article/879816.html&prev=search _利用它）
• https://translate.google.com/translate?hl=en&sl=zh-CN&u=http://blog.csdn.net/u012573259/article/details/51803447&prev=search（另一個中文文章更關注下一步和清潔向上）
• http://antirez.com/news/96一篇關於 redis 安全性的自以為是的部落格文章，描述了可能是進入 OP 伺服器的來源的入侵手段
• https://www.riskbasedsecurity.com/2016/07/redis-over-6000-installations-compromised/（概述有多少伺服器受到redis安全性差的影響）
• https://news.ycombinator.com/item?id=13053647（一個報告黑客攻擊比特幣風格的執行緒）

---

這是我關於 magento/redis 的清單，呃，性能問題：

1. 確保您使用的是新版本的 redis，例如 3.2，如果在 CentOS 上，我個人更喜歡 IUS 儲存庫中的 redis32u。
2. 檢查你的redis數據庫的大小，它應該在 中/var/lib/redis，並確保它相對較小。
3. 驗證您是否有足夠的記憶體用於 redis。您已經指定了maxmemory15GB 的大小，這對於 magento 來說實在是太過分了。我通常使用更接近256mb. 如果您使用 redis 那麼多（！！！！！！），您的 magento 堆棧中可能還有其他問題。
4. 確保在 syscntl 中設置了 vm overcommit 設置。 https://redis.io/topics/admin（有關您需要的更多詳細資訊，請參閱此連結）
5. 確保您有足夠的打開文件限制來處理與 redis 的連接數。

一般來說，日誌文件並不可疑，因為您的 redis 保存設置告訴 redis 如果有 > 10000 次寫入每分鐘保存一次，如果寫入次數 > 10 則每五分鐘保存一次，如果寫入次數 > 1 則每 15 分鐘保存一次寫。所以它本質上是每分鐘將資訊持久化回磁碟，這不應該是那麼繁重。

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