我不知道如何确切地找到哪个进程正在使用交换空间的直接答案，但是，这个链接可能会有帮助。另一个好例子在这里

另外，使用像htop这样的好工具来查看哪些进程使用了大量内存，以及总体上使用了多少交换空间。

您可以使用Procpath(作者在这里)，以简化从/proc/$PID/status解析vmswwap。

$ procpath record -f stat,cmdline,status -r 1 -d db.sqlite
$ sqlite3 -column db.sqlite \
  'SELECT status_name, status_vmswap FROM record ORDER BY status_vmswap DESC LIMIT 5'
Web Content  192136       
okular       186872       
thunderbird  183692       
Web Content  143404       
MainThread   86300

您还可以像这样绘制感兴趣的进程的vmswwap。在这里，我正在记录Firefox进程树，同时打开几十个选项卡，并启动一个占用大量内存的应用程序，试图导致它进行交换(这对Firefox来说并不令人信服，但您的情况可能不同)。

$ procpath record -f stat,cmdline,status -i 1 -d db2.sqlite \
  '$..children[?(@.stat.pid == 6029)]'
# interrupt by Ctrl+C
$ procpath plot -d db2.sqlite -q cpu --custom-value-expr status_vmswap \
  --title "CPU usage, % vs Swap, kB"

运行top，然后按OpEnter。现在进程应该根据它们的交换使用情况进行排序。

这是一个更新，因为我原来的答案没有提供一个确切的答案，在评论中指出的问题。从htop常见问题:

It is not possible to get the exact size of used swap space of a process. Top fakes this information by making SWAP = VIRT - RES, but that is not a good metric, because other stuff such as video memory counts on VIRT as well (for example: top says my X process is using 81M of swap, but it also reports my system as a whole is using only 2M of swap. Therefore, I will not add a similar Swap column to htop because I don't know a reliable way to get this information (actually, I don't think it's possible to get an exact number, because of shared pages).

我不知道如何确切地找到哪个进程正在使用交换空间的直接答案，但是，这个链接可能会有帮助。另一个好例子在这里

另外，使用像htop这样的好工具来查看哪些进程使用了大量内存，以及总体上使用了多少交换空间。

我在网上改编了一个不同的脚本来写这句长单句:

 { date;for f in /proc/[0-9]*/status; do 
   awk '{k[$1]=$2} END { if (k["VmSwap:"]) print k["Pid:"],k["Name:"],k["VmSwap:"];}' $f 2>/dev/null; 
   done | sort -n ; }

然后我将其扔进cronjob并将输出重定向到日志文件。这里的信息与在smaps文件中积累Swap:条目相同，但如果你想确定，你可以使用:

{ date;for m in /proc/*/smaps;do 
  awk '/^Swap/ {s+=$2} END { if (s) print FILENAME,s }' $m 2>/dev/null;
  done | tr -dc ' [0-9]\n' |sort -k 1n; }

这个版本的输出有两列:pid，交换量。在上面的版本中，tr删除非数值组件。在这两种情况下，输出都是按照pid数值排序的。

top命令还包含一个字段，用于显示进程的页面错误数量。页面错误最多的进程是交换次数最多的进程。 对于长时间运行的守护进程，可能会在开始时产生大量的页面错误，并且这个数字在以后不会增加。所以我们需要观察页面故障是否在增加。