买了一下轻量的阿里云服务器,搭建了一个solr的服务,前期更新DB数据1000条数据,发现一会儿CPU就飙慢了,服务直接无法使用。所以更改的策略,把更新的数据降小。服务正常运行。but,不到半天服务又挂了。

通过监控程序

  • 为了让服务正常运行了。写了一个监控脚本,加入到计划任务里去。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash

#监听solr[挂了立即重启]


for((i=1;i<=30;i++));do


solr_pid=$(ps -ef|grep java | grep solr|grep -v grep | awk '{print $2}' )

if [ "$solr_pid" == "" ]; then
    service solr restart
    echo 'solr挂了,已经重启'
fi

sleep 2
done

继续查找问题

  • top
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
top - 16:54:07 up 1 day, 14:32,  5 users,  load average: 1.08, 1.06, 1.05
Tasks:  93 total,   2 running,  88 sleeping,   3 stopped,   0 zombie
%Cpu(s):  3.6 us,  1.7 sy,  0.0 ni, 88.7 id,  6.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1016396 total,    71964 free,   674588 used,   269844 buff/cache
KiB Swap:        0 total,        0 free,        0 used.    60940 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                               
  853 solr      20   0 3273092 411524   4284 S  3.6 40.5   0:54.50 java                                                  
  480 root      20   0  676844  19332   3460 S  0.7  1.9   2:50.50 exe                                                   
 1030 root      20   0  197144   8356   1276 S  0.3  0.8   0:02.70 iotop                                                 
 2736 root      20   0   40752   2720      0 S  0.3  0.3   0:45.05 aliyun-service                                        
13507 root      20   0  384044  17652   1592 S  0.3  1.7   0:35.43 python                                                
18081 root      20   0  157716   1096    404 R  0.3  0.1   0:04.19 top                                                   
    1 root      20   0   45860   3652   1316 S  0.0  0.4   0:18.54 systemd                                               
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.01 kthreadd                                              
    3 root      20   0       0      0      0 S  0.0  0.0   0:03.69 ksoftirqd/0                                           
    5 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kworker/0:0H                                          
    7 root      rt   0       0      0      0 S  0.0  0.0   0:00.00 migration/0                                           
    8 root      20   0       0      0      0 S  0.0  0.0   0:00.00 rcu_bh                                                
    9 root      20   0       0      0      0 S  0.0  0.0   0:11.36 rcu_sched                                             
   10 root      rt   0       0      0      0 S  0.0  0.0   0:00.56 watchdog/0                                            
   12 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kdevtmpfs                                             
   13 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 netns                                                 
   14 root      20   0       0      0      0 S  0.0  0.0   0:00.02 khungtaskd                                            
   15 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 writeback                                             
   16 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kintegrityd                                           
   17 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 bioset                                                
   18 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kblo

可观察到cpu,内存使用正常。但是负载比较高!

  • iostat -x 10
1
2
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     1.60  238.54    0.90 26335.14    10.01   220.06     2.57   10.73   10.77    0.78   0.77  18.38

可观察到读负载比较高。

  • iotop -bod5
1
2
3
 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  877 be/4 solr       1047.79 K/s    0.00 B/s  0.00 %  0.06 % java -server -Xms512m -Xmx512m -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:-OmitStackTraceInFastThrow -verbose:gc -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:/www/server/solr/server/logs/solr_gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M -Dsolr.log.dir=/www/server/solr/server/logs -Djetty.port=8983 -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=UTC+8 -Djetty.home=/www/server/solr/server -Dsolr.solr.home=/www/server/solr/server/solr -Dsolr.install.dir=/www/server/solr -Xss256k -Dsolr.log.muteconsole -XX:OnOutOfMemoryError=/www/server/solr/bin/oom_solr.sh 8983 /www/server/solr/server/logs -jar start.jar --module=http [C2 CompilerThre]

solr读操作很大。

  • 优化读
1
2
3
4
5
6
7
[[email protected] ~]# cat /sys/block/vda/queue/nr_requests 
128
[[email protected] ~]# echo 512 > /sys/block/vda/queue/nr_requests 
-bash: echo: 写错误: 无效的参数


blockdev --setra 16384 /dev/vda

阿里云无法优化IO。

  • blockdev
1
2
3
4
5
在顺序读比较多的场景中,我们可以增大磁盘的预读数据,比如,你可以通过下面两种方法,调整 /dev/sdb 的预读大小。

# 调整内核选项
/sys/block/sdb/queue/read_ahead_kb,默认大小是 128 KB,单位为 KB。
使用 blockdev 工具设置,比如 blockdev --setra 327680 /dev/vda,注意这里的单位是 512B(0.5KB),所以它的数值总是 read_ahead_kb 的两倍。
  • 也可优化solr配置的。