linux下查看swap分区被哪些进程占用实现脚本

相信很多的系统管理员可能都遇见过这样的情况，用登录一台服务器，使用free命令查看内存，却发现swap分区被占用。那么到底是什么进程占用了这部分swap分区呢？

从2.6.16版本的kernel开始，我们可以使用proc文件系统中的smaps来查找这个问题。下边是一个列出所有进程占用swap分区情况的列表。可以通过简单修改就可以用于统计在/proc/$PID/smaps查出。以下是脚本：


代码如下:

for i in `cd /proc;ls |grep "^[0-9]"|awk ' $0 >100'` ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps ;done |sort -k2nr

赞 (0)

相关推荐

  • linux添加和增大交换分区（swap）的方法

    1) 添加或扩大交换分区#dd if=/dev/zero of=/home/swap bs=512 count=1024000bs 是扇区大小 bs=512 指大小为512B count为扇区数量表示创建一个大小为512M 的文件 /home/swap 用空值填充.of位置可以自己调整.2) 创建交换分区/sbin/mkswap swapfile 3) 激活该交换分区/sbin/swapon swapfile4) 查询目前系统中生效的交换分区情况/sbin/swapon -s5) 设置开机自己挂

  • 详解Linux系统中的tempfs与/dev/shm

    tmpfs 是 Linux/Unix 系统上的一种基于内存的文件系统,即 tmpfs 使用内存或 swap 分区来存储文件. Linux 内核中的 VM 子系统负责在后台管理虚拟内存资源 Virtual Memory,即 RAM 和 swap 资源,透明地将 RAM 页移动到交换分区或从交换分区到 RAM 页,tmpfs 文件系统需要 VM 子系统的页面来存储文件.tmpfs 自己并不知道这些页面是在交换分区还是在 RAM 中:做这种决定是 VM 子系统的工作.tmpfs 文件系统所知道的就是它

  • linux vps服务器进程kswapd0与events/0消耗大量CPU的问题

    linux vps服务器进程kswapd0与events/0消耗大量CPU的问题

    今天下午网站宕了两次机,发工单给阿里云,发现原因是服务器的CPU 100%了. 重启服务器后,使用 top 命令看看是哪些进程消耗那么大的 CPU 使用.盯了有好十几分钟,主要消耗 CPU 的进程有两个,一个是 mysql,另一个是 apache.下面的图可以看到,mysql 占用了很大部分的 CPU 使用.apache 单个进程虽然占得不多,但有不少个 apache 进程同时存在,也消耗了不少 CPU 的使用. 当然,这些不足以让服务器的 CPU 直接跑满挂掉,后来发现了两个大家伙: 当 my

  • linux下查看swap分区被哪些进程占用实现脚本

    相信很多的系统管理员可能都遇见过这样的情况,用登录一台服务器,使用free命令查看内存,却发现swap分区被占用.那么到底是什么进程占用了这部分swap分区呢? 从2.6.16版本的kernel开始,我们可以使用proc文件系统中的smaps来查找这个问题.下边是一个列出所有进程占用swap分区情况的列表.可以通过简单修改就可以用于统计在/proc/$PID/smaps查出.以下是脚本: 复制代码 代码如下: for i in `cd /proc;ls |grep "^[0-9]"|a

  • Linux下查看端口占用进程号，程序名的方法

    linux下查看端口占用情况: 1. 查看哪个进程占用了819端口: case9-sghfofo:/usr/local/cnbj/tomcat-bj/bin # lsof -i:859 运行后的结果: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME java 24907 root 31u IPv4 248905027 TCP *:859 (LISTEN) 由以上我们知道了859端口被进程号为24907的进程占用了, 是个java进程. 2. 查看进程

  • Linux下查看进程打开的文件句柄数和如何修改方法

    修改文件句柄数在Linux下,我们使用ulimit -n 命令可以看到单个进程能够打开的最大文件句柄数量(socket连接也算在里面).系统默认值1024. 对于一般的应用来说(象Apache.系统进程)1024完全足够使用.但是如何象squid.mysql.java等单进程处理大量请求的应用来说就有 点捉襟见肘了.如果单个进程打开的文件句柄数量超过了系统定义的值,就会提到"too many files open"的错误提示.如何知道当前进程打开了多少个文件句柄呢?下面一段小脚本可以帮

  • linux下查看系统进程占用的句柄数方法

    ---查看系统默认的最大文件句柄数,系统默认是1024 # ulimit -n 1024 ----查看当前进程打开了多少句柄数 # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more 131 24204 57 24244 57 24231 ........ 其中第一列是打开的句柄数,第二列是进程ID. 可以根据ID号来查看进程名. # ps aef|grep 24204 nginx 24204 24162 99 16:15 ? 00:24:25

  • linux下查看内存条数及每根内存大小的实现方法(推荐)

    在linux系统中,查看内存条个数,及每根内存的大小,可以使用dmidecode命令. 如下: #dmidecode | grep -A16 "Memory Device$" 输出结果: Memory Device #存储设备 Array Handle: 0x1000 #阵列处理 Error Information Handle: Not Provided #错误信息的处理:不提供 Total Width: 72 bits #总宽度: 72位 Data Width: 64 bits #

  • Linux下挂载硬盘分区的几种方法

    Linux下挂载硬盘分区的几种方法 1.使用Autofs自动挂载分区 2.修改/etc/fstab 3.编写shell脚本,开机自动运行mount命令 方法一.使用Autofs  1.Autofs的特点:Autofs与Mount/Umount的不同之处在于,它是一种看守程序(deamon).如果它检测到用户正试图访问一个尚未挂接的文件系统,它就会自动检测该文件系 统,如果该文件系统存在,那么Autofs会自动将其挂接.另一方面,如果它检测到某个已挂接的文件系统在一段时间内没有被使用,那么Auto

  • linux下查看so或可执行程序的依赖库

    linux下查看so或可执行程序的依赖库

    在linux下查看so或可执行程序的依赖库 Linux下可执行程序包括可执行程序exe和so, 两者文件都是ELF打头的. objdump -x libxxxxx.so | grep NEEDED objdump -x 可执行程序名 | grep NEEDED 或 arm-hisiv300-linux-objdump -x 可执行程序 | grep NEEDED arm-hisiv300-linux-readelf -a 可执行程序 | grep NEEDED linux之如何查看哪些进程在使用

  • 在Linux中查看所有正在运行的进程的方法

    可以使用ps命令.它能显示当前运行中进程的相关信息,包括进程的PID.Linux和UNIX都支持ps命令,显示所有运行中进程的相关信息. ps命令能提供一份当前进程的快照.如果想状态可以自动刷新,可以使用top命令. ps命令 输入下面的ps命令,显示所有运行中的进程: # ps aux | less 其中, -A:显示所有进程 a:显示终端中包括其它用户的所有进程 x:显示无控制终端的进程 任务:查看系统中的每个进程. # ps -A # ps -e 任务:查看非root运行的进程 # ps

  • Linux下查看CPU型号,内存大小,硬盘空间的命令(详解)

    1 查看CPU 1.1 查看CPU个数 # cat /proc/cpuinfo | grep "physical id" | uniq | wc -l 2 **uniq命令:删除重复行;wc –l命令:统计行数** 1.2 查看CPU核数 # cat /proc/cpuinfo | grep "cpu cores" | uniq cpu cores : 4 1.3 查看CPU型号 # cat /proc/cpuinfo | grep 'model name' |un

  • Linux下查看.so和可执行文件是否debug编译的方法(必看)

    今天同事问我,如何判断一个.so是否是debug编译的. 我记得以前自己是用file来查看一个.so,根据是否包含"not stripped"来判断该.so是否是debug编译的,于是就没做实验就回答. 然而,stripped/not stripped并不是debug/release编译的判断标准. 我对debug和release的.so运行file后,得出几乎相同的输出, 都是not stripped. 所以我算是误导同事了. 根据<Computers Systems - A

随机推荐