[Linux进程内存分析]
1. 常用的组合命令
1.CPU占用最多的前10个进程
ps auxw|head -1;ps auxw|sort -rn -k3|head -10
2.内存消耗最多的前10个进程
ps auxw|head -1;ps auxw|sort -rn -k4|head -10
3.虚拟内存使用最多的前10个进程
ps auxw|head -1;ps auxw|sort -rn -k5|head -10
4.也可以试试 这几个
ps auxw --sort=rss
ps auxw --sort=%cpu
- 参数介绍
- %MEM 进程的内存占用率
- MAJFL is the major page fault count,
- VSZ 进程所使用的虚存的大小
- RSS 进程使用的驻留集大小或者是实际内存的大小(RSS is the “resident set size” meaning physical memory used)
- TTY 与进程关联的终端(tty)
2. 常用的基本命令
2.1 free查看整体内存情况
$ free -m
total used free shared buff/cache available
Mem: 15363 13699 324 2 1339 1333
Swap: 0 0 0
2.2 top 查看进程情况
$ top
top - 14:22:24 up 470 days, 4:54, 3 users, load average: 0.56, 0.51, 0.51
Tasks: 194 total, 2 running, 186 sleeping, 0 stopped, 6 zombie
%Cpu(s): 23.9 us, 3.7 sy, 0.0 ni, 72.2 id, 0.1 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 15732496 total, 316944 free, 14041768 used, 1373784 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1352340 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25010 root 20 0 7025624 6.6g 2364 S 69.4 44.0 2905:36 containerd-shim
23456 root 20 0 5400940 1.3g 11740 S 23.9 8.5 164:17.61 java
28892 root 10 -10 157684 34292 5176 S 1.3 0.2 757:03.02 AliYunDun
894 root 20 0 1148092 34448 1572 S 1.0 0.2 1838:21 containerd
969 root 20 0 938224 67844 3332 S 1.0 0.4 2107:32 dockerd
-
参数介绍
PR:进程的优先级别,越小越优先被执行
VIRT:进程占用的虚拟内存
RES:进程占用的物理内存(实际内存)
SHR:进程使用的共享内存
S:进程的状态。S表示休眠,R表示正在运行,Z表示僵死状态,N表示该进程优先值为负数
%CPU:进程占用CPU的使用率
%MEM:进程使用的物理内存和总内存的百分比
TIME+:该进程启动后占用的总的CPU时间,即占用CPU使用时间的累加值。
COMMAND:进程启动命令名称 -
推荐1: shift + m 则会将结果按照 内存占用情况 进行排序
-
推荐2: 查看某个用户的所有进程情况
[root@web00-and-backend00 ~]# ps aux | head -1; ps aux | grep ^work | sort -rnk 4 | more USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND work 32631 17.1 7.5 5393556 1193396 ? Sl 12:57 18:54 /usr/bin/java - ....
-
注意: 某个进程的实际内存占用较少,但是虚拟内存占用大
$ top -p 23456 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23456 root 20 0 5400940 1.3g 11956 S 0.0 8.6 169:45.82 java
可以看到,RES 只有 1.3G 但是 虚拟内存则达到了 5G
-
导致这种问题的原因是 Java 使用 Glibc 的 Arena 内存池分配了大量的虚拟内存并没有使用。
在glibc分配内存的时候,大内存从从中央分配区分配,小内存则在线程创建时,从缓存区分配。为了解决分配内存的性能的问题,就引入了这个叫做arena的memory pool。而恰好,在64bit系统下面,它的缺省配置为64M。一个进程可以最多有cores8个arena,假如服务器是4核的,那么最多有48=32个arena,也就是32*64 = 2048M内存
-
可以通过 pmap -p {pid} 来确定是否是这个问题,如果看到有大量 64MB 的内存块则表示确定。
-
可以通过设置环境变量来改变arena的数量。
-
查看进程当前的环境变量值: grep MALLOC_ARENA_MAX /proc/$pid/environ
-
例如: export MALLOC_ARENA_MAX=1
默认为 cpu core*8,hadoop推荐把这个值设置为4, 一般建议配置程序cpu核数。
-
当然了,既然是多核的机器,而arena的引进是为了解决多线程内存分配竞争的问题,那么设置为cpu核的数量估计也是一个不错的选择。
-
设置这个值以后最好能对你的程序做一下压力测试,用以看看改变arena的数量是否会对程序的性能有影响。
-
-
也可以考虑使用 tcmalloc ,jemallc
-
-
此外,Java 读取的文件也会被映射为虚拟内存,在虚拟机默认配置下 Java 每个线程栈会占用 1M 的虚拟内存。具体可以查看 为什么linux下多线程程序如此消耗虚拟内存。
而真实占用的物理内存要看
RES
(resident) 列,这一列的值才是真正被映射到物理内存的大小。 -
2.3 htop 增强版本的 top
-
安装 htop 命令
yum -y install htop
-
快速使用
# 查看全部进程 hhop # 查看指定进程 htop -p {pid}
各项分别为:
- PID:进行的标识号
- USER:运行此进程的用户
- PRI:进程的优先级
- NI:进程的优先级别值,默认的为0,可以进行调整
- VIRT:进程占用的虚拟内存值
- RES:进程占用的物理内存值
- SHR:进程占用的共享内存值
- S:进程的运行状况,R表示正在运行、S表示休眠,等待唤醒、Z表示僵死状态
- %CPU:该进程占用的CPU使用率
- %MEM:该进程占用的物理内存和总内存的百分比
- TIME+:该进程启动后占用的总的CPU时间
- COMMAND:进程启动的启动命令名称
-
更多用法
要获得有关命令用法的帮助,只需运行即可。 # htop --help
2.4 ps命令
-
快速查看某个进程的 物理内存 与 虚拟内存占用情况
$ ps -p ${pid} -o rss,vsz RSS VSZ 7152568 17485844
- RSS 为物理内存 ,VSZ 为虚拟内存
-
查看全部进程
# 其中rsz是是实际内存
ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid'
# 其中rsz为实际内存,按内存排序,由大到小
ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep java | sort -nrk5
-
使用ps命令统计
通常,很多用户会使用如下ps命令进行统计
ps aux | awk ‘{mem += $6} END {print mem/1024/1024}’
但是,这里存在一个问题是,free没有专门统计另一项缓存: Slab。所以上述ps命令统计的结果与free展示的结果存在较大出入。
Slab Allocation是Linux 2.2之后引入的一个内存管理机制,专门用于缓存内核的数据对象,可以理解为一个内核专用的对象池,可以提高系统性能并减少内存碎片。(Linux 2.6.23之后,SLUB成为了默认的allocator)。可查看meminfo文件了解slab信息。
cat /proc/meminfo | grep Slab
2.5 pmap
可以根据进程查看进程相关信息占用的内存情况,(进程号可以通过ps查看)如下所示:
$ pmap -d 14596
参考
- https://blog.csdn.net/yiduyangyi/article/details/65635312
- https://www.linuxprobe.com/linux-sort-max-mc.html
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/15256.html