Linux已成为事实上企业级服务器OS的首选,PostgreSQL在Linux上的"装机量"不在少数,在对数据库的性能进行优化和调整时,同时也必须考虑到Linux的优化和调整. 本节简单介绍了Linux性能监控中的两个容易混淆的概念:CPU使用率和平均负载. 日常使用中最为常见的性能监控工是top,下面来看看top的输出: ``` top - 14:20:02 up 2:19, 3 users, load average: 0.00, 0.01, 0.07 Tasks: 126 total, 1 running, 125 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.7 sy, 0.0 ni, 99.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 3873760 total, 288164 free, 87888 used, 3497708 buff/cache KiB Swap: 1048572 total, 970292 free, 78280 used. 2952064 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 193748 3452 2240 S 0.7 0.1 0:05.85 systemd 917 dbus 20 0 32780 1028 704 S 0.7 0.0 0:00.30 dbus-daemon 17 root rt 0 0 0 0 S 0.3 0.0 0:09.25 migration/2 559 root 20 0 0 0 0 S 0.3 0.0 0:17.53 kworker/2:2 912 root 20 0 24204 1020 864 S 0.3 0.0 0:00.36 systemd-logind 915 root 20 0 216908 476 440 S 0.3 0.0 0:00.04 abrt-watch-log .... ``` 输出的第1行 ``` top - 14:20:02 up 2:19, 3 users, load average: 0.00, 0.01, 0.07 ``` 其中load average: 0.00, 0.01, 0.07是过去1分钟/5分钟/15分钟的load average(平均负载). 这个平均负载是什么意思呢?按大神Brendan Gregg的说法,平均负载是指系统可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和CPU使用并没有直接的关系.可运行状态进程包括正在使用CPU或者正在等待CPU的进程,不可中断状态是指正处于内核态不可中断关键流程中的进程,比如硬件设备的I/O响应等,通过top或ps命令看的D状态进程就是这种状态. 输出的第3行 ``` %Cpu(s): 0.2 us, 0.7 sy, 0.0 ni, 99.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st ``` 这是CPU使用率,其中us为用户态使用占比,sy是系统态占比,ni是使用nice加权进程分配的用户态占比,id是空闲占比,wa是等待使用CPU占用,hi是硬中断占比,si是软中断占比,st(steal)是虚拟机使用占比,这些项加起来应为100%. 为了更好理解平均负载和CPU使用率,以高速公路收费站来打个比喻,假设某高速收费站有8个收费口. 1.如果没有车通过,那么收费站的负载为0; 2.如果同时只有4辆车缴费通过,那么负载为4; 3.如果同时有8辆车,那么负载为8; 4.如果有8辆车在缴费,同时每个收费口又有1辆车在等待,那么负载为16,这时候其实收费站已过载; 5.如果有8辆车在缴费,同时每个收费口还有(n-1)\*8(n>3)辆车在等待,那么负载将会是n\*8,这时候收费站已严重过载,会出现严重拥堵; 这是平均负载,下面说说CPU使用率. 1.如果收费口和车主全部使用ETC缴费,那么使用率很高; 2.如果某些收费口使用人工收费,但支持微信或支付宝,车主只需要刷卡就走,准备缴费的时间不长,因此使用率也不低; 3.如果某些收费口使用人工收费,但只能现金收费,那掏钱/找钱这些无用功占比就较高,这样使用率就变得较低. 通过这个比喻可以看出,平均负载和使用率并没有必然的关系,负载高CPU使用率不一定高,CPU使用率高负载并不见得会高. 下面是使用benchmarksql对PG进行压力下使用top的输出: ``` top - 14:51:33 up 2:50, 3 users, load average: 22.34, 9.89, 3.81 Tasks: 153 total, 7 running, 146 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.9 us, 5.2 sy, 0.0 ni, 23.3 id, 47.6 wa, 0.0 hi, 16.0 si, 0.0 st KiB Mem : 3873760 total, 139744 free, 418508 used, 3315508 buff/cache KiB Swap: 1048572 total, 969552 free, 79020 used. 2620448 avail Mem ... top - 14:49:49 up 2:49, 3 users, load average: 14.47, 4.19, 1.48 Tasks: 153 total, 2 running, 151 sleeping, 0 stopped, 0 zombie %Cpu0 : 20.2 us, 23.0 sy, 0.0 ni, 28.7 id, 19.9 wa, 0.0 hi, 8.2 si, 0.0 st %Cpu1 : 13.5 us, 29.2 sy, 0.0 ni, 19.6 id, 28.5 wa, 0.0 hi, 9.3 si, 0.0 st %Cpu2 : 12.9 us, 19.3 sy, 0.0 ni, 16.4 id, 11.1 wa, 0.0 hi, 40.4 si, 0.0 st %Cpu3 : 15.1 us, 25.8 sy, 0.0 ni, 19.7 id, 29.4 wa, 0.0 hi, 10.0 si, 0.0 st KiB Mem : 3873760 total, 133432 free, 435336 used, 3304992 buff/cache KiB Swap: 1048572 total, 970816 free, 77756 used. 2601620 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10337 benchma+ 20 0 4612656 222272 5376 S 42.7 5.7 0:40.99 java 10448 benchma+ 20 0 789004 52556 20408 S 14.0 1.4 0:00.93 postgres 10356 benchma+ 20 0 757376 179348 176640 D 9.7 4.6 0:04.15 postgres 10365 benchma+ 20 0 757384 194680 191904 D 9.3 5.0 0:05.12 postgres 10375 benchma+ 20 0 757452 183908 181172 D 9.3 4.7 0:04.51 postgres 10358 benchma+ 20 0 757340 190880 188144 D 8.7 4.9 0:04.90 postgres 10357 benchma+ 20 0 757448 169860 167092 D 8.3 4.4 0:04.14 postgres 10352 benchma+ 20 0 757388 185012 182236 S 8.0 4.8 0:04.63 postgres 10354 benchma+ 20 0 757376 177416 174676 D 7.7 4.6 0:04.23 postgres 10367 benchma+ 20 0 757356 178524 175796 D 7.3 4.6 0:04.25 postgres ... ``` 可以看出近一分钟的平均负载飙升到14.47,而CPU逻辑内核个数不过4个,已超出系统负荷. 而CPU使用率中的us部分不过30%上下,大部分CPU在idle/wait上. **参考资料** [Linux Load Averages: Solving the Mystery](www.brendangregg.com/blog/2017-08-08/linux-load-averages.html)