redis超时排查

现象:服务起不来, log显示在初始化时从redis加载数据失败,程序自动退出

1. 问题确认

先查看服务连接的那台redis的slowlog 看看是不是读取数据超时

指令格式为 redis-cli.exe -p xxxx sloglog get num
-p表示指定端口,缺省值为6379
num缺省值为10

[root@slave1(101) ~]# /homed/redis/bin/redis-cli.exe -p 8888 sloglog get
...
7) 1) (integer) 186509
   2) (integer) 1557194683
   3) (integer) 80199888      #耗时ms
   4) (integer) 2
   5) "fd=162,peerip=192.168.2.113,peerport=48740,SrvTypeID=41612"
   6) 1) "processHValsCommand"
      2) "dtvs_column_program"
...

从redis日志查到失败的这条获取指令耗时 80199888ms, 就是80s,远大于程序设置的40s等待时间. 确认是redis读取数据超时导致.

2.问题排查

先确认数据大小, 是否是海量数据导致

[root@slave1(101) ~]# /homed/redis/bin/redis-cli.exe -p 8888 hlen dtvs_column_program
[redisFormatCommandArgv] send ipanel protocol msg(39 bits):
("*2\r\n$4\r\nhlen\r\n$19\r\ndtvs_column_program\r\n")
[redisBufferRead] read ipanel protocol msg(10 bytes):
(":1669675\r\n")
(integer) 1669675

发现数据量是百万级不算多, 并且返回长度的时候有将近一秒钟的卡顿,

再确认服务器cpu和内存情况

[root@slave1(101) ~]# top
top - 10:32:59 up 225 days, 23:06,  1 user,  load average: 0.09, 0.28, 0.32
Tasks: 244 total,   2 running, 241 sleeping,   0 stopped,   1 zombie
Cpu(s):  9.6%us,  2.8%sy,  0.0%ni, 82.9%id,  4.5%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8010180k total,  6642364k used,  1367816k free,    41836k buffers
Swap:  8388600k total,  8321800k used,    66800k free,   143812k cached
#
#
[root@slave1(101) ~]# free -m 
             total       used       free     shared    buffers     cached
Mem:          7822       6487       1335          0         45        135
-/+ buffers/cache:       6306       1516
Swap:         8191       8126         65

发现服务器swap消耗很大, 由此怀疑是倒swap导致
Linux (以及其他一些操作系统) 可以把内存页存储在硬盘上,反之也能将存储在硬盘上的内存页再加载进内存,这种机制使得内存能够得到更有效的利用。
如果内存页被系统移到了swap文件里,而这个内存页中的数据恰好又被redis用到了(例如要访问某个存储在内存页中的key),系统就会暂停redis进程直到把需要的页数据重新加载进内存。这个操作因为牵涉到随机I/O,所以很慢,会导致无法预料的延迟。
所以更具redis进程的pid查询下redis进程的内存布局

[root@slave2(102) /home/redis/bin]# ps aux | grep redis
root      2946  1.5 11.1 27960492 896488 ?     Ssl  Mar17 1161:55 ./redis-server.exe slave pub8888Slave2 /homed/redis/bin/../config/redis-pub8888.conf
root      2952  0.5  0.0  51180  3372 ?        Ssl  Mar17 405:20 ./redis-sentinel.exe /homed/redis/bin/../config/sentinel-pub8887.conf
[root@slave2(102) /homed/redis/bin]# cd /proc/2946/
[root@slave2(102) /proc/2946]# ls
attr       cgroup      coredump_filter  environ  fdinfo  loginuid  mountinfo   net        oom_score      personality  schedstat  stack  status   wchan
autogroup  clear_refs  cpuset           exe      io      maps      mounts      numa_maps  oom_score_adj  root         sessionid  stat   syscall
auxv       cmdline     cwd              fd       limits  mem       mountstats  oom_adj    pagemap        sched        smaps      statm  task

在这里你会发现一个名为smaps 的文件,它描述了redis进程的内存布局 (假定你使用的是Linux 2.6.16或者更新的版本)。这个文件包括了很多进程所使用内存的细节信息,其中有一项叫做Swap的正是我们所关心的。不过仅看这一项是不够的,因为smaps文件包括有redis进程的多个不同的的内存映射区域的使用情况(进程的内存布局远不是线性排列那么简单)。
从我们对所有进程的内存交换情况感兴趣以来,我们首先要做的事情是使用grep命令显示进程的smaps文件

[root@slave2(102) /proc/2946]# cat smaps | grep 'Swap:'
Swap:                  0 kB
Swap:                  0 kB
Swap:                  4 kB
Swap:                  4 kB
Swap:            4459156 kB
Swap:                  0 kB
Swap:                 52 kB
Swap:                  0 kB
Swap:                  0 kB
Swap:            1649036 kB
Swap:                 24 kB
Swap:                  0 kB
Swap:               6388 kB
Swap:                 24 kB
Swap:                496 kB
Swap:                  0 kB

假如所有的数据显示为0kb或者某些数据偶尔显示为4kb,表示当前一切正常。实际上我们的例子是一个真实的运行着Redis并每秒为数百的用户提供服务,会显示更多的交换页。为了研究是否存在一个严重的问题,我们改变命令打印出分配的内存尺寸

[root@slave2(102) /proc/2946]# cat smaps | egrep '^(Swap|Size)'
Size:               1200 kB
Swap:                  0 kB
Size:                 36 kB
Swap:                  0 kB
Size:                156 kB
Swap:                 52 kB
Size:                132 kB
Swap:                 24 kB
Size:               3628 kB
Swap:                496 kB
Size:                128 kB
Swap:                  0 kB
Swap:                  4 kB
Size:           18264064 kB
Swap:            4459172 kB
Size:                  4 kB
Swap:                  0 kB
Size:                680 kB
Swap:                  0 kB
Size:            7847936 kB
Swap:            1649572 kB
Size:                132 kB
Swap:                 24 kB
Size:              65404 kB
Swap:                  0 kB
Size:              24576 kB
Swap:               6392 kB
Size:                564 kB
Swap:                  0 kB
Size:                412 kB
Swap:                  0 kB

在输出信息中,你能看到有好些个较大的内存分配18264064kb(有4459172kb的交换),因此可能会产生任何的问题

假如进程的内存有相当部分花在了swap上,那么你的延迟可能就与swap有关。假如redis出现这种情况那么可以用 vmstat 命令来验证一下猜测:

[root@slave2(102) /proc/2946]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1 8388600 1317960   7160  25988   10    4   822   332    0    0 21  8 64  7  0
 2  1 8388600 1317580   6460  25944    0    0  3384     0 34749 101745 21  6 55 18  0
 1  2 8388600 1318936   5384  26900    0    0  5684    36 35252 102194 21  7 53 20  0
 2  1 8388600 1316876   5792  28580   32    4  5860    52 35057 101769 20  6 53 20  0
 3  1 8388600 1322728   4128  23092    0    0  3288   296 35850 102399 20  8 51 21  0
 2  1 8388600 1324216   3896  21892    0    0  3132     4 35183 102094 20  6 55 19  0
 0  1 8388600 1324712   3872  21332    0    0  2792     0 35290 102133 20  7 54 19  0
 3  1 8388600 1324340   4036  21496    0    0  6096    12 35086 101848 20  7 51 22  0
 2  1 8388600 1327812   4032  18312    0    0  2220    56 35640 101922 21  6 53 20  0
 3  1 8388600 1331160   3632  15652    0    0  1828   132 35217 101961 21  6 52 21  0
 3  3 8388600 1331904   5148  14708   64    8  3056    52 35154 101981 20  8 44 28  0
 2  1 8388600 1324960   5756  20332    0    0 10296     4 35298 102324 20  6 55 19  0
 3  1 8388600 1325828   4596  20056    0    0  3248    16 34736 101586 20  7 54 19  0
 2  1 8388600 1326572   4208  19752   64    8  4360    72 35382 102168 20  7 52 21  0
 3  1 8388600 1329424   3668  20096    0    0  4808   464 35802 102230 20  7 50 23  0
 6  3 8388592 1323704   3968  25592   32    8 10420   264 36074 102460 21  7 46 26  0
 3  1 8388600 1323580   3572  25472    0    8  5828   168 35500 102488 21  7 49 23  0
 6  2 8388600 1320976   6528  26600   32    4  7836   184 35348 102614 22  6 46 26  0
 7  2 8388600 1321100   7432  24652   32    4  4148    40 35001 101978 20  7 53 20  0
 1  1 8388600 1326432   7280  19184    0    0  2616  1196 35605 102327 20  7 54 19  0
 0  2 8388600 1327912   5856  20424   32    4  5208   104 35453 102292 21  6 55 19  0
 4  1 8388600 1326904   5504  20324    0    0  3412    80 35506 102265 21  6 52 21  0

输出中我们最感兴趣的两行是si 和 so,这两行分别统计了从swap文件恢复到内存的数量和swap到文件的内存数量。如果在这两行发现了非0值那么就说明系统正在进行swap。
同时,可以用iostat命令来查看系统的全局I/O行为。

[root@slave2(102) /proc/2946]# iostat -xk 1
Linux 2.6.32-279.el6.x86_64 (slave2)    2019年05月07日  _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.70    0.00    7.59    7.32    0.00   64.39

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdf              10.35    51.54    8.10   22.02   172.65   294.28    31.00     0.09    2.96   3.28   9.88
sda              12.76    47.86   11.90    3.05   555.81   203.65   101.57     0.03    1.97   4.04   6.04
sdc              13.64    47.69   12.78    2.96   568.34   202.61    97.97     0.02    1.47   3.93   6.19
sdb              13.31    47.59   12.54    2.92   566.86   202.04    99.47     0.01    0.93   3.66   5.66
sde              13.13    47.58   12.45    2.93   565.38   202.06    99.76     0.02    1.00   3.88   5.97
sdd              52.61    46.87   28.04    3.20   794.41   200.30    63.68     0.10    3.18   2.53   7.92

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21.52    0.00    6.58   31.65    0.00   40.25

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdf               0.00    32.00    5.00    7.00    24.00   156.00    30.00     0.13   10.92   3.42   4.10
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc             439.00  1679.00  118.00   56.00  2452.00  6940.00   107.95     2.24   12.87   5.61  97.70
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sde               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd               0.00     0.00   20.00    0.00  2048.00     0.00   204.80     0.11    5.55   0.80   1.60

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.26    0.00    6.92   31.54    0.00   41.28

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdf               0.00     0.00    3.00    0.00    12.00     0.00     8.00     0.01    5.00   5.00   1.50
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc             548.00     0.00  133.00    0.00  2948.00     0.00    44.33     1.15    8.69   7.42  98.70
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sde               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd               0.00     1.00   20.00    4.00  2048.00    20.00   172.33     0.57   23.88   4.00   9.60

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.67    0.00    6.20   28.17    0.00   44.96

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdf               0.00    76.00    1.00    5.00     4.00   324.00   109.33     0.13   21.50   6.50   3.90
sda               0.00     0.00    0.00    1.00     0.00     4.00     8.00     0.00    3.00   3.00   0.30
sdc             476.00     0.00  143.00    0.00  2656.00     0.00    37.15     1.28    8.85   6.83  97.70
sdb               0.00     0.00    0.00    1.00     0.00     4.00     8.00     0.00    3.00   3.00   0.30
sde               0.00     1.00    0.00   23.00     0.00    96.00     8.35     0.15    6.48   4.91  11.30
sdd               0.00     0.00   32.00    0.00  2096.00     0.00   131.00     0.64   20.12   2.72   8.70

发现sdc的负载经常在90%以上, 同时再看了下服务的内存情况,发现swap已经耗完了.

[root@slave2(102) /proc/2946]# free -m
             total       used       free     shared    buffers     cached
Mem:          7822       6532       1289          0          6         46
-/+ buffers/cache:       6479       1343
Swap:         8191       8191          0

于是查一下哪个进程在占用磁盘io

方法 iotop -oP
命令的含义:只显示有I/O行为的进程

Total DISK READ: 8.82 M/s | Total DISK WRITE: 22.09 K/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                                                                      
   58 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [kswapd0]
29732 be/4 root        4.87 M/s    0.00 B/s  0.00 %  1.94 % ./filebeat
 1148 be/4 root        7.36 K/s    7.36 K/s  0.00 %  1.44 % [kjournald]
28869 be/4 root        7.36 K/s    0.00 B/s  0.00 %  0.45 % top
 2946 be/4 root       18.41 K/s   11.05 K/s  0.00 %  0.19 % ./redis-server.exe slave pub8888Slave2 /homed/redis/bin/../config/redis-pub8888.conf
13034 be/4 root        0.00 B/s    7.36 K/s  0.00 %  0.03 % java -Dproc_journalnode -Xmx24000m -Djava.net.preferIPv4Stack=true -Dhadoop.log.dir=/wo~FA -Dhadoop.security.logger=INFO,RFAS org.apache.hadoop.hdfs.qjournal.server.JournalNode

发现有个和swap相关的[kswapd0]基本占用了所有io

$ pidstat -d 1
命令的含义:展示I/O统计,每秒更新一次

[root@slave2(102) /proc/2946]# pidstat -d 1
Linux 2.6.32-279.el6.x86_64 (slave2)    2019年05月07日  _x86_64_        (4 CPU)

14时20分31秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分32秒        58      0.00    461.54      0.00  kswapd0
14时20分32秒       576      7.69      0.00      0.00  flush-8:80
14时20分32秒      2278      0.00      3.85      0.00  zabbix_agentd
14时20分32秒      2946     23.08     19.23      0.00  redis-server.ex
14时20分32秒      2952      0.00      3.85      0.00  redis-sentinel.
14时20分32秒      2973      0.00      3.85      0.00  redis-server.ex
14时20分32秒     13034    973.08    138.46      0.00  java
14时20分32秒     20972   2092.31    580.77      0.00  java

14时20分32秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分33秒        58      0.00     28.00      0.00  kswapd0
14时20分33秒      2946      0.00     12.00      0.00  redis-server.ex
14时20分33秒      3033      0.00      4.00      0.00  redis-sentinel.
14时20分33秒     20972   2048.00      0.00      0.00  java
14时20分33秒     28869      8.00      0.00      0.00  top

14时20分33秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分34秒        58      0.00    572.00      0.00  kswapd0
14时20分34秒      2946      0.00      4.00      0.00  redis-server.ex
14时20分34秒      2952      0.00      4.00      0.00  redis-sentinel.
14时20分34秒      3054      0.00      4.00      0.00  redis-server.ex
14时20分34秒      3081      0.00      4.00      0.00  redis-server.ex
14时20分34秒     13034      8.00    160.00      0.00  java
14时20分34秒     20972   2304.00    176.00      0.00  java

14时20分34秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分35秒        58      0.00    196.00      0.00  kswapd0
14时20分35秒      1148      0.00      4.00      0.00  kjournald
14时20分35秒      1151      0.00     20.00      0.00  jbd2/sdf8-8
14时20分35秒      1581    172.00      0.00      0.00  rpcbind
14时20分35秒      2354     96.00      0.00      0.00  master
14时20分35秒      2946      0.00      4.00      0.00  redis-server.ex
14时20分35秒      3000      0.00      4.00      0.00  redis-server.ex
14时20分35秒      3087      0.00      4.00      0.00  redis-sentinel.
14时20分35秒      9780    232.00      0.00      0.00  pickup
14时20分35秒     20972   2076.00      0.00      0.00  java

14时20分35秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分36秒        58      0.00   4952.00      0.00  kswapd0
14时20分36秒       481      0.00     16.00      0.00  kjournald
14时20分36秒      1161      0.00     16.00      0.00  jbd2/sdb1-8
14时20分36秒      1992    128.00      0.00      0.00  snmpd
14时20分36秒      2946      0.00      4.00      0.00  redis-server.ex
14时20分36秒      2952      0.00      4.00      0.00  redis-sentinel.
14时20分36秒      2979      0.00      4.00      0.00  redis-sentinel.
14时20分36秒     20972    504.00   4356.00      0.00  java
14时20分36秒     28869      8.00      0.00      0.00  top
14时20分36秒     29732   2840.00      0.00      0.00  filebeat

14时20分36秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14时20分37秒        58      0.00    472.00      0.00  kswapd0
14时20分37秒      1166      0.00     36.00      0.00  jbd2/sde1-8
14时20分37秒      1176      0.00     16.00      0.00  jbd2/sda1-8
14时20分37秒      2946      0.00      4.00      0.00  redis-server.ex
14时20分37秒     13034    104.00     20.00      0.00  java
14时20分37秒     20972   7152.00    616.00      0.00  java

发现除了kswapd0以外还有一个java进程在读io
再回到sdc所在的目录看看

root@slave2(102) /proc/2946]# df -h
文件系统              容量  已用  可用 已用%% 挂载点
/dev/sdf5              30G   20G  8.9G  69% /
tmpfs                 3.9G     0  3.9G   0% /dev/shm
/dev/sdf1             485M   37M  423M   8% /boot
/dev/sdf6              30G  3.4G   25G  12% /home
/dev/sdf2              40G  9.0G   29G  24% /usr
/dev/sdf3              40G  999M   37G   3% /var
/dev/sdf8             404G  319G   65G  84% /work
/dev/sdd1             1.8T  869G  873G  50% /data5
/dev/sdb1             1.9T  896G  875G  51% /data2
/dev/sde1             1.9T  893G  878G  51% /data4
/dev/sdc1             1.9T  889G  881G  51% /data3
/dev/sda1             1.9T  889G  881G  51% /data1
[root@slave2(102) /proc/2946]# cd /data3/
[root@slave2(102) /data3]# ll
总用量 28
-rw-r--r--. 1 root root    10 5月   7 14:24 disk_test.txt
-rw-rw-r--. 1 root root    20 9月  15 2017 zb_disk_check.txt
drwxr-xr-x. 3 root root  4096 2月  18 2014 hadoopdata
drwx------. 2 root root 16384 2月  15 2014 lost+found

发现有一个disk_test.txt的文件一直都在刷新. 由此怀疑是其他同事在做磁盘测试导致

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342