web-dev-qa-db-ja.com

Linux：どのプロセスがすべてのRAMを使用しているのか調べますか？

実際に尋ねる前に、明確にするために：はい、私はディスクキャッシュについて知っています、そして、いいえ、それは私の場合ではありません:)申し訳ありません、この前文:)について

私はCentOS 5を使用しています。システム内のすべてのアプリケーションは頻繁にスワップしており、システムは非常に低速です。 free -mを実行すると、次のようになります。

             total       used       free     shared    buffers     cached
Mem:          3952       3929         22          0          1         18
-/+ buffers/cache:       3909         42
Swap:        16383         46      16337

だから、私は実際に使用するには42メガバイトしかありません！私が理解している限りでは、-/+ buffers/cacheは実際にはディスクキャッシュを数えないので、私は確かに42 Mbしか持っていませんね。私は間違っているかもしれないと思ったので、私はディスクキャッシュをオフにしようとしました、そしてそれは効果がありませんでした - 絵は同じままだった。

それで、私はだれが私のRAMをすべて使っているかを調べることにしました、そして私はそれのためにtopを使いました。しかし、どうやらそれは私のRAMを使用しているプロセスがないことを報告しています。私のトップにある唯一のプロセスはMySQLですが、それは0.1％のRAMと400MBのスワップを使用しています。私が他のサービスやアプリケーションを実行しようとしたときの同じ画像 - すべてがスワップに入る、topはMEMが使われていないことを示します（どのプロセスでも最大0.1％）。

top - 15:09:00 up  2:09,  2 users,  load average: 0.02, 0.16, 0.11
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4046868k total,  4001368k used,    45500k free,      748k buffers
Swap: 16777208k total,    68840k used, 16708368k free,    16632k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
 3214 ntp       15   0 23412 5044 3916 S  0.0  0.1   0:00.00  17m ntpd
 2319 root       5 -10 12648 4460 3184 S  0.0  0.1   0:00.00 8188 iscsid
 2168 root      RT   0 22120 3692 2848 S  0.0  0.1   0:00.00  17m multipathd
 5113 mysql     18   0  474m 2356  856 S  0.0  0.1   0:00.11 472m mysqld
 4106 root      34  19  251m 1944 1360 S  0.0  0.0   0:00.11 249m yum-updatesd
 4109 root      15   0 90152 1904 1772 S  0.0  0.0   0:00.18  86m sshd
 5175 root      15   0 90156 1896 1772 S  0.0  0.0   0:00.02  86m sshd

再起動は役に立ちません、そして、彼らは非常に遅いです、私は通常このマシン（4コア、4GbのRAM、）を期待していないでしょRAID1）。

それで、これで - これはRAMを使用しているディスクキャッシュではないと確信しています。

だから、最後に、問題は、誰かがどのプロセスが実際にメモリを実際に非常に頻繁に使用しているかを見つける方法を何か考えがあるのであれば - です。

linuxmemoryperformance
115
Timur

Linuxでは、topプロセスで<キーを押すと、出力表示のソートが左に移動します。デフォルトでは%CPUでソートされているので、キーを4回押すとVIRTでソートされます。これはあなたの答えを与えてくれます。

これを行う別の方法は、次のとおりです。

ps -e -o pid,vsz,comm= | sort -n -k 2

あなたとプロセスの仮想サイズでソートされた出力を表示します。

これがロングバージョンです：

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
105
Karlson

プロセスのメモリをメガバイトとプロセスパスで表示します。

ps aux  | awk '{print $6/1024 " MB\t\t" $11}'  | sort -n
62
notnull

サーバー上の単なるメモでも同じ症状を示していますが、それでもメモリの枯渇を示しています。最終的に見つかったのは、32 GBのRAMのボックスからのsysctl.confで、12000に構成された巨大ページを持つDBのセットアップでした。このボックスには2 GBのRAMしかありません。それはすべての空きRAMを巨大ページに割り当てていました（それらのうちのわずか960）。いずれにしても使用されていないため、巨大ページを10に設定すると、すべてのメモリが解放されます。

HugePages_設定を探すための/ proc/meminfoの簡単なチェックは、少なくとも1つの予期しないメモリホッグをトラブルシューティングするための良いスタートになります。

14
Death Rider

私の場合、問題は、サーバーがvmw_balloonモジュールを有効にしたVMware仮想サーバーであることでした。

$ lsmod | grep vmw_balloon
vmw_balloon            20480  0
vmw_vmci               65536  2 vmw_vsock_vmci_transport,vmw_balloon

ランニング：

$ vmware-toolbox-cmd stat balloon
5189 MB

そのため、実際には約5 GBのメモリがホストによって回収されました。したがって、私のVMに "公式に" 8 GBの容量があるにもかかわらず、実際にははるかに少なくなりました。

$ free
              total        used        free      shared  buff/cache   available
Mem:        8174716     5609592       53200       27480     2511924     2458432
Swap:       8386556        6740     8379816
3
Mitar

Psコマンドを使用して、プロセスに関する詳細情報を入手することもできます。

ps aux | less
2
Atul

次のような内容のshow-memory-usage.shというスクリプトを作成します。

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '
1
Felipe

this と Pythonプロセスで使用されている総メモリを参照してください。 - スタックオーバーフロー 、それが私の答えです。私は今、特定のプロセス（python）カウントツールを手に入れました。

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

私のプロセスリストを添付してください。

$ ps aux  | grep python
root       943  0.0  0.1  53252  9524 ?        Ss   Aug19  52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root       950  0.6  0.4 299680 34220 ?        Sl   Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root      3803  0.2  0.4 315692 36576 ?        S    12:43   0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny    23325  0.0  0.1  47460  9076 pts/0    S+   17:40   0:00 python
jonny    24651  0.0  0.0  13076   924 pts/4    S+   18:06   0:00 grep python

参照

1
Chu-Saing Lai

Hyper-V上のubuntuサーバーDISTRIB RELEASE = 18.04では、ほとんどのメモリが使用されましたが、すべてのプロセスは正常でした。 （snapdおよびunattended-upgrパッケージを削除したことは認めましたが、メモリの95％はまだ使用されていました。）

答えは、Hyper-Vには動的メモリがあるため、メインシステムで使用するためにメモリを使用し、ubuntuが使用済みとしてフラグを立てたということです。

それが誰かを助けることを願っています。

0
Vodyanikov Andrew Anatolevich

これはまたプロセスIDを取り、使用されたMBでソートし、（プロセスを作成した）コマンドの概要を示します。

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n

0
prosti