十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
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持久化过程的监控及优化的详细内容,更多请关注创新互联其它相关文章!