free
-m
total
used
free
shared
buffers
cached
Mem:
1002
769
232
0
62
421
-/+
buffers/cache:
286
715
Swap:
1153
0
1153
第一部分Mem行:
total
内存总数:
1002M
used
已经使用的内存数:
769M
free
空闲的内存数:
232M
shared
当前已经废弃不用，总是0
buffers
Buffer
缓存内存数:
62M
cached
Page
缓存内存数:421M
关系：total(1002M)
=
used(769M)
+
free(232M)
第二部分(-/+
buffers/cache):
(-buffers/cache)
used内存数：286M
(指的第一部分Mem行中的used
-
buffers
-
cached)
(+buffers/cache)
free内存数:
715M
(指的第一部分Mem行中的free
+
buffers
+
cached)
可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。
第三部分是指交换分区,
我想不讲大家都明白
我想大家看了上面,还是很晕第一部分(Mem)与第二部分(-/+
buffers/cache)的结果中有关used和free为什么这么奇怪
其实我们可以从二个方面来解释
对 *** 作系统来讲是Mem的参数buffers/cached
都是属于被使用,所以它认为free只有232
对应用程序来讲是(-/+
buffers/cach)buffers/cached
是等同可用的，因为buffer/cached是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。
所以,以应用来看看,以(-/+
buffers/cache)的free和used为主所以我们看这个就好了另外告诉大家一些常识Linux为了提高磁盘和内存存取效率,
Linux做了很多精心的设计,
除了对dentry进行缓存(用于VFS,加速文件路
径名到inode的转换),
还采取了两种主要Cache方式：Buffer
Cache和Page
Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache能有效缩短了
I/O系统调用(比如read,write,getdents)的时间。
记住内存是拿来用的,不是拿来看的不象windows,
无论你的真实物理内存有多少,他都要拿硬盘交换文件来读这也就是windows为什么常常提示虚拟空间不足的原因你们想想,多无聊,在内存还有大部分
的时候,拿出一部分硬盘空间来充当内存硬盘怎么会快过内存所以我们看linux,只要不用swap的交换空间,就不用担心自己的内存太少如果常常
swap用很多,可能你就要考虑加物理内存了这也是linux看内存是否够用的标准哦
1、首先是对于CPU的说明
服务器CPU性能参数主要信息可以通过查看 /proc/cpuinfo 获得。具体查看指令及效果如下：
显示这台服务器上有2个物理CPU
显示这台服务器的物理核数为16个
显示运行模式为64位
显示为Intel(R) Xeon(R) Gold 6226R CPU @ 290GHz
命令：
显示此服务器的线程数为64
top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。下面详细介绍它的使用方法。top是一个动态显示过程,即可以通过用户按键来不断刷新当前状态如果在前台执行该命令,它将独占前台,直到用户终止该程序为止比较准确的说,top命令提供了实时的对系统处理器的状态监视它将显示系统中CPU最“敏感”的任务列表该命令可以按CPU使用内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定
1．命令格式：
top [参数]
2．命令功能：
显示当前系统正在执行的进程的相关信息，包括进程ID、内存占用率、CPU占用率等
3．命令参数：
-b 批处理
-c 显示完整的治命令
-I 忽略失效过程
-s 保密模式
-S 累积模式
-i<时间> 设置间隔时间
-u<用户名> 指定用户名
-p<进程号> 指定进程
-n<次数> 循环显示的次数
4．使用实例：
实例1：通过 Top 命令显示进程信息
命令：
统计信息区：
前五行是当前系统情况整体的统计信息区。下面我们看每一行信息的具体意义。
第一行，任务队列信息，同 uptime 命令的执行结果，具体参数说明情况如下：
10:38:58 — 当前系统时间
up 39 days, 19:47 — 系统已经运行了39天19小时47分钟（在这期间系统没有重启过的吆！）
1 users — 当前有1个用户登录系统
load average: 000, 000, 000 — load average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。
load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
第二行，Tasks — 任务（进程），具体信息说明如下：
系统现在共有769个进程，其中处于运行中的有1个，463个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。
第三行，cpu状态信息，具体属性说明如下：
00%us — 用户空间占用CPU的百分比。
00% sy — 内核空间占用CPU的百分比。
00% ni — 改变过优先级的进程占用CPU的百分比
1000% id — 空闲CPU百分比
00% wa — IO等待占用CPU的百分比
00% hi — 硬中断（Hardware IRQ）占用CPU的百分比
00% si — 软中断（Software Interrupts）占用CPU的百分比
备注：在这里CPU的使用比率和windows概念不同，需要理解linux系统用户空间和内核空间的相关知识！
第四行,内存状态，具体信息如下：
65600012k total — 物理内存总量
1785256k used — 使用中的内存总量
62385920k free — 空闲内存总量
1428836k buffers — 缓存的内存量
第五行，swap交换分区信息，具体信息说明如下：
2097148k total — 交换区总量
918340k used — 使用的交换区总量
1178808k free — 空闲交换区总量
备注：
第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。
对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。
第六行，空行。
第七行以下：各进程（任务）的状态监控，项目列信息说明如下：
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级，正值表示低优先级
VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR — 共享内存大小，单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计，单位1/100秒
COMMAND — 进程名称（命令名/命令行）
或者通过 free 命令显示系统内存的使用情况，包括物理内存、交换内存(swap)和内核缓冲区内存。
命令：
显示我当前的服务器的物理内存是62G，其中交换内存是2个G，一共剩余是60G的
三、查看Linux内核当前的系统版本号
命令：
显示的当前的服务器Linux内核是Ubuntu系统，版本号是18046
最近在解决探针获取Ruby应用服务器的内存使用的情况，将解决的思路总结一下，希望对此感兴趣的伙伴一起探讨。
先对比应用服务器： Puma 和 Passenger ，下面对比这2个服务器内存统计，
单进程模式：直接获取进程id: Processpid
cluster模式：以启动2个worker进程为例:
从上面截图可以看到，Puma启动后会出现3个进程：1个master进程和2个worker进程。
内存的使用情况(见 RSS 列):
而对于探针来说，一个探针实例是伴随进程一起启动的，也就说一个探针只能识别自己所在的进程id，那如何获取应用服务器使用的内存？我们用其中1个woker进程所在的进程组[ PGID ]看一下:(为啥不是父进程, 见下文Passenger)
这3个进程都在相同的进程组里，而且进程组号为master的进程id，那我们就可以用这个信息获取应用服务器的所使用的内存:
4累加进程组内进程内存和即为应用服务器使用内存:
启动Passenger后的Process信息：
对Passenger架构感兴趣的请移步到 这儿
查看一下worker所在进程组和父进程:
通过PPID可以看出
Passenger core —> Passenger AppPreloader —> Passenger RubyApp
三者为爷-父-子关系，当服务器请求量增大时 AppPreloader 会产生新的进程来响应请求,从而新的 RubyApp 进程的 PPID 即为 AppPreloader 的 PID ，这样看来就可以将同一个 PPID 的进程加起来得到应用服务器的内存？
由于Passenger会根据服务器的负载量动态调整进程数，当服务器请求量较小时，Passenger会kill多余的进程，会出现下面的情况：
AppPreloader 也被Passenger杀掉了。原 RubyApp 进程的 PPID 变成了1。这时如果服务器的请求量增大，应用服务器进程会成为这样：
Passenger core 产生新的 AppPreloader 进程，并且 AppPreloader 产生新的 RubyApp 进程，这时如果只用 PPID 统计应用服务器内存就会不准确，所以要统计Passenger的使用的内存还得通过累加在同一个进程组( PGID )的所有进程使用的内存和得到。
由于 Unicorn 和 Rainbows 都与Puma的cluster模式[master+worker模式]类似，内存统计的方式可以参考上文的Puma。
由于 Thin 启动多个server后没有类似的特点，上面方法不适用于Thin，有好方法的伙伴们可以告知:smile:
在解决探针统计应用服务器的内存问题上，摸索出了上面的一条路子，如果小伙伴们有其他更好的方式，可以一起探讨一下。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）