linux查看进程所占内存 proc pid status-linux-操作系统-壹聚教程网linux查看进程所占内存 proc pid status
下面我们来一起看在linux中查看进程所占内存的文章内容，这里最常我们使用了cat命令来查看指定进程ID的，然后其它信息有top之类的，大家可进入参考。
命令：cat /proc/9744/status&& //9744为进程id
Name: gedit /*进程的程序名*/
State: S (sleeping) /*进程的状态信息*/
Tgid: 9744 /*线程组号*/
Pid: 9744 /*进程pid*/
PPid: 7672 /*父进程的pid*/
TracerPid: 0 /*跟踪进程的pid*/
Uid: 1000&&& 1000&&& 1000&&& 1000 /*uid euid suid fsuid*/
Gid: 1000&&& 1000&&& 1000&&& 1000 /*gid egid sgid fsgid*/
FDSize: 256 /*文件描述符的最大个数，file-&fds*/
Grou: 0 4 20 24 25 29 30 44 46 107 109 115 124 1000 /*启动该进程的用户所属的组的id*/
VmPeak: 60184 kB /*进程地址空间的大小*/
VmSize: 60180 kB /*进程虚拟地址空间的大小reserved_vm：进程在预留或特殊的内存间的物理页*/
VmLck: 0 kB /*进程已经锁住的物理内存的大小.锁住的物理内存不能交换到硬盘*/
VmHWM: 18020 kB /*文件内存映射和匿名内存映射的大小*/
VmRSS: 18020 kB /*应用程序正在使用的物理内存的大小，就是用ps命令的参数rss的值 (rss)*/
VmData: 12240 kB /*程序数据段的大小（所占虚拟内存的大小），存放初始化了的数据*/
VmStk: 84 kB /*进程在用户态的栈的大小*/
VmExe: 576 kB /*程序所拥有的可执行虚拟内存的大小,代码段,不包括任务使用的库 */
VmLib: 21072 kB /*被映像到任务的虚拟内存空间的库的大小*/
VmPTE: 56 kB /*该进程的所有页表的大小*/
Threads: 1 /*共享使用该信号描述符的任务的个数*/
SigQ: 0/8183 /*待处理信号的个数/目前最大可以处理的信号的个数*/
SigPnd: 0000 /*屏蔽位，存储了该线程的待处理信号*/
ShdPnd: 0000 /*屏蔽位，存储了该线程组的待处理信号*/
SigBlk: 0000 /*存放被阻塞的信号*/
SigIgn: 1000 /*存放被忽略的信号*/
SigCgt: 0000 /*存放被俘获到的信号*/
CapInh: 0000 /*能被当前进程执行的程序的继承的能力*/
CapPrm: 0000 /*进程能够使用的能力，可以包含CapEff中没有的能力，这些能力是被进程自己临时放弃的*/
CapEff: 0000 /*是CapPrm的一个子集，进程放弃没有必要的能力有利于提高安全性*/
Cpus_allowed: 01 /*可以执行该进程的CPU掩码集*/
Mems_allowed: 1 /**/
voluntary_ctxt_switches: 1241 /*进程主动切换的次数*/
nonvoluntary_ctxt_switches: 717 /*进程被动切换的次数*/
附另一文章
&top -b -n 1 |grep opera|awk '{print &cpu:&$9&%&,&mem:&$10&%&}'
&&& cpu:0.0% mem:26.4%
RSS-------------进程实际占用物理内存大小；
VSZ--------------任务虚拟地址空间的大小
3./proc/pid/status
[root@localhost ~]# cat /proc/self/status
State: R (running)
SleepAVG: 88%
Tgid: 5783
PPid: 5742
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups: 0 1 2 3 4 6 10
VmSize: 6588 kB
VmLck: 0 kB
VmRSS: 400 kB
VmData: 144 kB
VmStk: 2040 kB
VmExe: 14 kB
VmLib: 1250 kB
Brk: 088df000 kB
StaStk: bfe03270 kB
Threads: 1
SigPnd: 0000
ShdPnd: 0000
SigBlk: 0000
SigIgn: 0000
SigCgt: 0000
CapInh: 0000
CapPrm: fffffeff
CapEff: fffffeff
Name 应用程序或命令的名字
State 任务的状态，运行/睡眠/僵死/
SleepAVG 任务的平均等待时间(以nanosecond为单位)，交互式任务因为休眠次数多、时间长，它们的 sleep_avg
也会相应地更大一些，所以计算出来的优先级也会相应高一些。
Tgid 线程组号
Pid 任务ID
Ppid 父进程ID
TracerPid 接收跟踪该进程信息的进程的ID号
Uid Uid euid suid fsuid
Gid Gid egid sgid fsgid
FDSize 文件描述符的最大个数，file-&fds
VmSize(KB) 任务虚拟地址空间的大小
(total_vm-reserved_vm)，其中total_vm为进程的地址空间的大小，reserved_vm：进程在预留或特殊的内存间的物理页
VmLck(KB) 任务已经锁住的物理内存的大小。锁住的物理内存不能交换到硬盘 (locked_vm)
VmRSS(KB) 应用程序正在使用的物理内存的大小，就是用ps命令的参数rss的值 (rss)
VmData(KB) 程序数据段的大小（所占虚拟内存的大小），存放初始化了的数据；
(total_vm-shared_vm-stack_vm)
VmStk(KB) 任务在用户态的栈的大小 (stack_vm)
VmExe(KB) 程序所拥有的可执行虚拟内存的大小，代码段，不包括任务使用的库 (end_code-start_code)
VmLib(KB) 被映像到任务的虚拟内存空间的库的大小 (exec_lib)
VmPTE 该进程的所有页表的大小，单位：kb
Threads 共享使用该信号描述符的任务的个数，在POSIX多线程序应用程序中，线程组中的所有线程使用同一个信号描述符。
SigQ 待处理信号的个数
SigPnd 屏蔽位，存储了该线程的待处理信号
ShdPnd 屏蔽位，存储了该线程组的待处理信号
SigBlk 存放被阻塞的信号
SigIgn 存放被忽略的信号
SigCgt 存放被俘获到的信号
CapInh Inheritable，能被当前进程执行的程序的继承的能力
Permitted，进程能够使用的能力，可以包含CapEff中没有的能力，这些能力是被进程自己临时放弃的，CapEff是CapPrm的一个子集，进程放弃没有必要的能力有利于提高安全性
CapEff Effective，进程的有效能力
可以看出该应用程序的正文段(1KB)很小，说明代码很少，是依靠库（1251KB）来执行。栈（138KB）适中，说明 没有太多许多嵌套函数或特别多的临时变量。VmLck为0说明进程没有锁住任何页。VmRSS表示当前进程使用的物理内存为2956KB。当进程开始使用 已经申请的但还没有用的内存时，VmRSS的值开始增大，但是VmSize保持不变。
[root@localhost 1]# cat /proc/4668/status
Name: gam_server
State: S (sleeping)
SleepAVG: 88%
Tgid: 31999
Pid: 31999
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups: 0 1 2 3 4 6 10
VmSize: 2136 kB
VmLck: 0 kB
VmRSS: 920 kB
VmData: 148 kB
VmStk: 88 kB
VmExe: 44 kB
VmLib: 1820 kB
VmPTE: 20 kB
Threads: 1
SigQ: 1/2047
SigPnd: 0000
ShdPnd: 0000
SigBlk: 0000
SigIgn: 1006
SigCgt: 0800
CapInh: 0000
CapPrm: fffffeff
CapEff: fffffeff
[root@localhost 31999]#4 /proc//statm
包含了所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
[root@localhost ~]# cat /proc/self/statm
654 57 44 0 0 334 0
以下是我自己的理解：
从上面可以看出VmRSS才是我们最关心的内存大小，即
正在使用的物理内存的大小；
而VmSize是进程所拥有的虚拟空间的大小；
&当进程开始使用 已经申请的但还没有用的内存时，
VmRSS的值开始增大，但是VmSize保持不变。&
我们之所以看到许多内存的值的大小超过了内存的总的大小
是因为这里显示的都是虚拟内存的大小，而不是实际的占用的大小；
这是其它的地方的解释
From cat /proc/4743/statm
001 883 18 0
1. size :- total program size (611450 X
= 2445800kB = 2388M)
2. resident :- resident set size (185001 X
= 740004kB = 722M)
3. share :- shared pages (883 X 4096 = 3532)
4. trs :- text (code) (18 X
= 72kB = VmExe )
5. drs :- data/stack
6. lrs :- library (593431 X
= 2373724kB = VmData +VmStk)
7. dt :- dirty pages
从这里可以看出第一项是进程的可执行的大小，X4就等于VmSize
而第二项的值X4就等于VmRSS
上一页： &&&&&下一页：相关内容Linux下如何查看高CPU占用率线程
下如何查看高CPU占用率线程
在 Linux 下 top 工具可以显示 cpu 的平均利用率(user,nice,system,idle,iowait,irq,softirq,etc.)，可以显示每个 cpu 的利用率。但是无法显示每个线程的 cpu 利用率情况，
这时就可能出现这种情况，总的 cpu 利用率中 user 或 system 很高，但是用进程的 cpu 占用率进行排序时，没有进程的 user 或 system 与之对应。
可以用下面的命令将 cpu 占用率高的线程找出来:
$ ps H -eo user,pid,ppid,tid,time,%cpu,cmd &sort=%cpu
这个命令首先指定参数&H'，显示线程相关的信息，格式输出中包含:user,pid,ppid,tid,time,%cpu,cmd，然后再用%cpu字段进行排序。这样就可以找到占用处理器的线程了。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'到底多少线程算是线程数太多？ - ImportNew
我写了一个服务，并为每个请求分配一个线程来处理，我这样做的原因是因为基本上每个请求都是一次数据库的查询操作。我使用了一个线程池的库来减少线程的创建和销毁。
我的问题是：像这样的I/O多线程，什么才是一个好的临界点？我知道这需要一个粗略的估计值，但这个值应该是几百呢还是几千？
非常感谢你们所有的回答，看起来我需要去测试找出线程数上限，问题是：我怎么知道线程数已经到达了上限？我究竟该如何去测量？
有的人可能会说，两个线程就算是太多的线程了。我不是特别同意这种看法。
我的建议是：测试，而不是猜想。我建议把线程数设置为可配置的，并初始化为100个线程，然后运行你的软件并对它进行监控。
如果线程的使用峰值才为3，那说明100个线程就是太多了。如果一天中的大部分时间都保持在100个线程，那就将线程的数量提高到200，然后再监视其运行情况。
你确实可以让你的代码自动监控线程的使用，并在下次启动的时候自动修改配置选项，但没必要这么做。
我不支持经常变动你的线程池，而是尽可能的使用某一个值，你可能会问一个线程池合适的临界点是什么，现假定你的线程池可以限制线程池的最大线程数（这是一件非常好的事情）。
我写过线程池和数据库连接池，他们拥有以下最基本的特征（我认为这些对系统的性能来说是必要的）：
最小活动线程数
最大线程数
多久关闭一个未被使用的线程
第一条是为了确保线程池的最低性能标准（这些线程是一直可以被使用的）。第二条是为了限制活动线程的资源使用。第三条是在一定的时间内将线程数返回到基准的设置，以减少资源的使用。
你需要去平衡线程未被完全使用（情况A）和没有足够的工作线程（情况B）的情况。
A通常指内存的使用（栈等等），因为一个不工作的线程不会占用太多的CPU资源。B通常会延迟处理到达请求，直到有可以使用的线程。
这就是为什么要去测算，正如你遇到的这种情况，绝大部分线程需要等待数据库的响应才能运行。这就有两个主要因素影响线程的数量：
第一个因素是数据库的有效连接数。这是一个硬性的限制，除非你能通过数据库管理系统增加数据库的连接数。在这里，我假设你的数据库管理系统能够承担的数据库连接数是无限制的。（虽然，理想情况下，你也应该测量一下）
其次，线程数量应该依赖于你系统的历史运行情况。最小的线程数你应该设置为在历史最低的线程数的基础上加上A%和一个绝对的最小数值（例如，让它也可被配置，就像A一样）5。
线程池的最大数应该设置为在历史最大线程数的基础上加上B%。
你也应该监控你系统运行情况的变化，如果因为某些原因，在某一个非常重要的时刻，你的线程池使用率达到100%（这将影响你客户端的性能），这就应该增加你线程池所允许的最大线程的数量，使其再增加B%。
对于“我究竟如何去测试”的回答：
你应该明确测算当前运行（例如，等待数据库调用的返回）负载下的最大线程数量。然后增加一个安全因子，如10%（强调一下，很多人貌似把我举得例子当做了固定的建议）
此外，在生产环境下，这点也应该是需要去调节的。在刚开始的时候先估计一个值是没问题的，但是，你永远也无法预料生产环境下会产生什么情况（这就是为什么要把所有的这些都设置为运行时可配置的原因）。这就能应付各种客户端调用时所出现的不可预期的情况。
原文链接：
- 译文链接： [ 转载请保留原文出处、译者和译文链接。]
关于作者：
很不错的使用方式,学习到了
关于ImportNew
ImportNew 专注于 Java 技术分享。于日 11:11正式上线。是的，这是一个很特别的时刻 :)
ImportNew 由两个 Java 关键字 import 和 new 组成，意指：Java 开发者学习新知识的网站。 import 可认为是学习和吸收， new 则可认为是新知识、新技术圈子和新朋友……
新浪微博：
推荐微信号
反馈建议：@
广告与商务合作QQ：
– 好的话题、有启发的回复、值得信赖的圈子
– 写了文章？看干货？去头条！
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 活跃 & 专业的翻译小组
– 国内外的精选博客文章
– UI,网页，交互和用户体验
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
& 2016 ImportNew