linux pmap,linux下的ps和pmap

今天有客户需要对系统进程进行内存跟踪

于是尝试使用了几个linux内存跟踪工具

首先,ps一下看看系统跑着哪些process

[root@oracle10g ~]# ps aux

USER PID %CPU %MEM VSZ RSS

TTY STAT START TIME COMMAND

root 1 0.0 0.0 10348 684

? Ss Sep10 0:01 init

[5] root 2 0.0 0.0 0 0

? S

root 3 0.0 0.0 0 0

? SN Sep10 0:00 [ksoftirqd/0]

。。。。。。。。。。。

root 9438 0.0 0.0 12740 1136

pts/2 T 17:40 0:00 top

喔,不少进程!拿出top进程为例

中,关于内存的是 VSZ 和 RSS 这两个

man ps 看看它们的含义:

rss RSS resident

set size, the non-swapped physical memory that a task has used (in

kiloBytes). (alias rssize, rsz).

vsz VSZ virtual

memory size of the process in KiB (1024-byte units). Device

mappings are currently excluded; this is subject to change. (alias

vsize).

简单一点说,RSS 就是这个process 实际占用的物理内存,VSZ 就是process 的虚拟内存,就是process

现在没有使用但未来可能会分配的内存大小。

其实这里的ps出来的结果,是有点不正确的,如果把所有程序的 RSS 加起来,恐怕比你的实际内存还要大。为什么呢?因为 ps

的结果,RSS 那部分,是包括共享内存的。这里我用pmap来看看。

[root@oracle10g ~]# pmap -d 9438

9438: top

Address Kbytes Mode Offset Device Mapping

0000000000400000 56 r-x-- 0000000000000000 008:00002 top

000000000060e000 4 rw--- 000000000000e000 008:00002 top

000000000060f000 12 rw--- 000000000060f000

000:00000 [ anon ]

00000000055fb000 264 rw--- 00000000055fb000

000:00000 [ anon ]

0000003d33600000 112 r-x-- 0000000000000000 008:00002 ld-2.5.so

0000003d3381b000 4 r---- 000000000001b000 008:00002 ld-2.5.so

0000003d3381c000 4 rw--- 000000000001c000 008:00002 ld-2.5.so

0000003d33a00000 1336 r-x-- 0000000000000000 008:00002 libc-2.5.so

0000003d33b4e000 2044 ----- 000000000014e000 008:00002 libc-2.5.so

0000003d33d4d000 16 r---- 000000000014d000 008:00002 libc-2.5.so

0000003d33d51000 4 rw--- 0000000000151000 008:00002 libc-2.5.so

0000003d33d52000 20 rw--- 0000003d33d52000

000:00000 [ anon ]

0000003d33e00000 52 r-x-- 0000000000000000 008:00002 libproc-3.2.7.so

0000003d33e0d000 2048 ----- 000000000000d000 008:00002 libproc-3.2.7.so

0000003d3400d000 4 rw--- 000000000000d000 008:00002 libproc-3.2.7.so

0000003d3400e000 80 rw--- 0000003d3400e000

000:00000 [ anon ]

0000003d34200000 8 r-x-- 0000000000000000 008:00002 libdl-2.5.so

0000003d34202000 2048 ----- 0000000000002000 008:00002 libdl-2.5.so

0000003d34402000 4 r---- 0000000000002000 008:00002 libdl-2.5.so

0000003d34403000 4 rw--- 0000000000003000 008:00002 libdl-2.5.so

0000003d46c00000 316 r-x-- 0000000000000000 008:00002 libncurses.so.5.5

0000003d46c4f000 2044 ----- 000000000004f000 008:00002 libncurses.so.5.5

0000003d46e4e000 56 rw--- 000000000004e000 008:00002 libncurses.so.5.5

0000003d46e5c000 4 rw--- 0000003d46e5c000

000:00000 [ anon ]

00002aabfbd69000 8 rw--- 00002aabfbd69000

000:00000 [ anon ]

00002aabfbd8e000 12 rw--- 00002aabfbd8e000

000:00000 [ anon ]

00002aabfbd91000 40 r-x-- 0000000000000000 008:00002 libnss_files-2.5.so

00002aabfbd9b000 2044 ----- 000000000000a000 008:00002 libnss_files-2.5.so

00002aabfbf9a000 4 r---- 0000000000009000 008:00002 libnss_files-2.5.so

00002aabfbf9b000 4 rw--- 000000000000a000 008:00002 libnss_files-2.5.so

00007fffbecd1000 84 rw--- 00007ffffffea000

000:00000 [ stack ]

ffffffffff600000 8192 ----- 0000000000000000

000:00000 [ anon ]

mapped:

20932K writeable/private:

564K shared:

0K

linux 会把一些shared libraries 载入到内存中,在pmap的输出中,这些shared libraries

的名字通常是 lib*.so。会被很多process load

到自己的运行环境中。同时ps输出的RSS中,每个process都包含了这个lib*.so,而事实上它只被load

了一次,如果单纯把ps的结果相加,这样就重复计算了。而 pmap 的输出中,writeable/private: 564K

,这个就是top真正占用的物理内存,不包含shared libraries 。在这里,它只有564K,而ps 的RSS

是1136K。

os很多参数和命令都值得深入研究,自己越学越觉得自己的弱小,加油吧!

再加上几个内存命令:

1、top命令

top -d 1 -p pid [,pid ...]//设置为delay 1s,默认是delay 3s

如果想根据内存使用量进行排序,可以shift + m(Sort by memory usage)

1、pmap命令

pmap pid

2、ps命令

ps aux|grep process_name

3、查看/proc/process_id/文件夹下的status文件

任务虚拟地址空间的大小 VmSize

应用程序正在使用的物理内存的大小 VmRSS

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值