买了一下轻量的阿里云服务器,搭建了一个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
|
继续查找问题
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,内存使用正常。但是负载比较高！
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
|
可观察到读负载比较高。
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
| [root@izt4nj0p2on0g1i5rjpf0jz ~]# cat /sys/block/vda/queue/nr_requests
128
[root@izt4nj0p2on0g1i5rjpf0jz ~]# echo 512 > /sys/block/vda/queue/nr_requests
-bash: echo: 写错误: 无效的参数
blockdev --setra 16384 /dev/vda
|
阿里云无法优化IO。
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 的两倍。
|
…