如何查看哪些进程使用了swap？

swap查看有很多种方法，一一介绍下：

1.free

free -m

就能看出当前系统所使用的swap了。那么如何查看哪些进程使用了swap呢，这样好针对性的做出优化。

2.top

Centos（6.0之前）：

top只能看到swap总使用量

网上很多人说top+f+p能显示出来swap。可是按完f查看的时候，man top里面swap的解释是：

并不是实际的使用swap。而是VIRT-RES得来的。用我蹩脚的英文翻译就是，虚拟内存中所使用过的swap部分

3.Centos（6.0之后）：

man top

这样就明显看出是取出的每个进程的swap，能很方便的查看哪些进程使用了swap。从中也能看到一个信息。那就是读取了/proc/#/status

4.vmstat

vmstat -n 1也能查看到

仍旧无法查看到哪些进程使用了。但是能看到si、so

Memory（内存）：

swpd: 使用虚拟内存大小

free: 可用内存大小

buff: 用作缓冲的内存大小

cache: 用作缓存的内存大小

Swap：

si: 每秒从交换区写到内存的大小

so: 每秒写入交换区的内存大小

5.shell

在Linux内核 2.6.16中引入了一个系统内存接口特性，这个接口位于/proc/$pid/目录下的smaps文件中 ，一看内容发现是进程内存映像信息，比同一目录下的maps文件更详细些。

cat /proc/1/smaps

这里解释下samps里面的内容：

bfdca000-bfddf000 是该虚拟内存段的开始和结束位置

rw-p 内存段的权限，rw是指可读写，p是指私有，如果是s则为共享

bffea000 该虚拟内存段在对应的映射文件中的偏移量

00：00 文件的主设备和次设备号

0 被映射到虚拟内存的文件的索引节点号

[stack] 被映射到虚拟内存的文件名称

Size 是进程使用内存空间，并不一定实际分配了内存(VSS)

Rss是实际分配的内存(不需要缺页中断就可以使用的)

Shared_Clean 和其他进程共享的未改写页面

Shared_Dirty 和其他进程共享的已改写页面

Private_Clean 未改写的私有页面页面

Private_Dirty 已改写的私有页面页面

Swap 存在于交换分区的数据大小(如果物理内存有限，可能存在一部分在主存一部分在交换分区)

Pss是平摊计算后的使用内存(有些内存会和其他进程共享，例如mmap进来的)

服务器上部署了ES5集群，通过zabbix监控发现cpu load呈锯齿状，且ES所在磁盘iops read和cpu load有一样的锯齿，可证明ES周期性的发生大量读磁盘 *** 作。通过分析，ES周期性大量读磁盘是因为QA每10分钟发起搜索业务请求

此外，该机器上有marathon超卖内存的情况存在，当关闭超卖的服务时，iops read及cpu load监控正常

按理说QA监控发起的搜索请求不会变化，ES应该有索引文件缓存。所以首先分析ES索引文件缓存的情况

通过/proc/$pid/smaps可查看进程内存分布及映射情况，如下图所示，size表示通过mmap映射的文件的大小，Rss表示该文件mmap实际内存的大小，Pss表示当某个文件被多个进程同时使用时，平均每个进程占用的内存大小

写个脚本，分析一下文件缓存使用情况：

索引5s96iIBfS6KivdgDrb8u-Q映射文件大小为44.3g，实际占用物理内存838M，对比其他服务器同索引文件缓存使用情况发现，大于该机器占用的物理内存（2.1g 对比 838M）

通过监控ES进程的smaps文件发现当cpu飙升即搜索请求时，文件缓存占用高达2-3G，请求完成一段时间后文件缓存将至700-800M，此时可判定是因为文件缓存被系统踢掉导致频繁发生磁盘io

通过分析源码可知ES使用MMapDirectory打开索引文件，其内部FileProvider调用C库的mmap函数打开文件，所以是由系统托管文件缓存

为何 *** 作系统会踢掉ES文件缓存？猜测是因为marathon超卖导致内存使用过多， *** 作系统需要回收文件缓存，而QA监控又是10分钟请求一次，导致ES无法持有文件缓存

通过调整 *** 作系统内核参数vm.vfs_cache_pressure(100 =>80)来让 *** 作系统尽量少回收文件缓存，调整后相关监控如下

ES节点内存维持较之前提升至少500M

通过监控分析smaps文件能获取各索引文件物理内存占用情况，发生堆外内存异常时可排查是哪些索引文件导致的，即可大致推断是什么业务什么类型的查询

heap内存可以使用jhat、jmap分析使用情况

匿名页缓存可在jvm启动参数加上-XX:NativeMemoryTracking=[off|summary|detail]后，通过jcmd $pid VM.native_memory detail分析

---