美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”,而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY
这类常见的坑,也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。
php-memcached 的一些坑
· 7 min read
美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”,而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY
这类常见的坑,也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。
一年即将过去,翻了一下博客发现更新频率比月经还来得稀疏,内疚到前列腺都萎缩了。
转入正题,本篇博客主要是分享一个自己日常用的比较多工具 tcpkit, 该工具用途主要是用来抓包和快速的分析数据包。
代码地址: git-hulk/tcpkit
DBA 发现同一组 Redis 从库中有实例 QPS 比较高,对比发现只是其中一个从库偏高而其他从库是正常的,分布如下:
那么问题就是: 「为什么会 QPS 不均匀?」, 由于我们先上 php 业务都是长连接,QPS 不均匀应该是连接数不均带来的。然后让运维大侠统计了一下四个实例的连接数,发现确实请求量跟连接数是成线性正相关的。
作为一个不合格的开发人员多多少少都被 OOM(Out of memory) x 过,只是一般大家对于为什么被选中,可能没太考究。
简单来说之所以会出现 OOM, 就是已分配的虚拟内存大于物理内存和 Swap 分区大小,导致需要内存无法分配。如果 overcommit = 2, 在申请虚拟内存时,如果超过限制的内存比例 + Swap 空间会直接返回失败,只要分配虚拟内存不超过物理内存,也就不会有 OOM。
春节前几天运维大侠说要扩容 Redis 从库但同步一直失败,看日志发现在做 bgsave 的时候一直失败。 日志如下:
[41738] 04 Feb 11:16:39.859 * Full resync requested by slave.
[41738] 04 Feb 11:16:39.859 * Starting BGSAVE for SYNC
[41738] 04 Feb 11:16:39.860 # Can't save in background: fork: Cannot allocate memory
[41738] 04 Feb 11:16:39.860 * Replication failed, can't BGSAVE
从日志可以看到 fork 的时候内存分配失败导致 bgsave 无法成功,那就是可用内存不足?