メモリを大量に消費し、「ps」などのプログラムでは表示されないコンテンツを見つけてください。

メモリを大量に消費し、「ps」などのプログラムでは表示されないコンテンツを見つけてください。

仮想マシンにメモリの問題があります。実行しようとしている操作の1つがメモリ不足エラーのためにクラッシュします。

しかし、クラッシュが発生したとき、システムはまだメモリ不足でした。これが私が行方不明のプロセスであるか実際のバグであるかはわかりません(これはhyper-vにあり、新しいカーネル拡張によってLinuxホストのメモリが膨らんでいるため、実際のカーネルである可能性が高いです)。ワーム)。

durr@sqlbox:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          3.1G       2.6G       541M        88K       7.4M        39M
-/+ buffers/cache:       2.5G       588M
Swap:         1.0G       6.2M       1.0G

Freeはキャッシュされただけではなく、実際に生きているように見えるものが2.6Gのメモリを占めていると言います。

しかし、仮想サイズでソートされたPS出力を見ることは興味深いものではありません。

durr@sqlbox:~$ ps -e ax -o pid,vsz,comm | sort --numeric-sort --key=2
[ ... snip ... ]
  PID    VSZ COMMAND
   96      0 rcuob/23
   97      0 rcuob/24
   98      0 rcuob/25
   99      0 rcuob/26
 1124   4368 acpid
59863  10016 ps
 1031  15668 upstart-file-br
 1047  15820 getty
 1050  15820 getty
 1055  15820 getty
 1056  15820 getty
 1058  15820 getty
 1167  15820 getty
 1023  15920 upstart-socket-
 1076  19140 atd
 1099  19188 irqbalance
  428  19476 upstart-udev-br
59864  21860 sort
59267  22644 bash
59234  22664 bash
59280  22808 bash
 1075  23656 cron
59261  26928 screen
59279  27380 htop
59262  28472 screen
    1  33776 init
  749  39240 dbus-daemon
  816  43452 systemd-logind
  432  51348 systemd-udevd
 1090  61364 sshd
  871 255844 rsyslogd
59184 269028 sshd
59233 269028 sshd

したがって、最大のメモリを占めるのはsshd…269Kを使用しているということですか?私の記憶はどこに行きましたか?

/proc/meminfoプログラムの概要:

durr@sqlbox:~$ cat /proc/meminfo
MemTotal:        3266904 kB
MemFree:          554228 kB
Buffers:            7596 kB
Cached:            41104 kB
SwapCached:         3032 kB
Active:            32552 kB
Inactive:          34292 kB
Active(anon):      13224 kB
Inactive(anon):     5008 kB
Active(file):      19328 kB
Inactive(file):    29284 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1044476 kB
SwapFree:        1038084 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         15656 kB
Mapped:             9196 kB
Shmem:                88 kB
Slab:              33488 kB
SReclaimable:      14532 kB
SUnreclaim:        18956 kB
KernelStack:        2352 kB
PageTables:         2748 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2677928 kB
Committed_AS:      56148 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       34360 kB
VmallocChunk:   34359695660 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       44456 kB
DirectMap2M:     3491840 kB

どうやらメモリをたくさん占める何かがあるようですがVmalloc、関連があるかはよくわかりません。

ベストアンサー1

プログラムが共有メモリを使用していて、それをクリーンアップしない可能性があります。

Linuxには共有メモリの3つのバリエーションがあります。

1.)POSIX共有メモリ(glibcで実装されたメモリ)は、擬似ファイルシステムのファイルを介しtmpfsてアクセスでき、通常はシステムによってまたはマウントされます。決定する最善の方法は、シェル(より移植性の高い)または(Linuxに最適)に入力することです。/dev/shm/run/run/shm/run/lockmount | grep -E '^tmpfs'grep -E '^tmpfs' /proc/mounts

プロセスはunlink()共有mmap()メモリから「ed」ファイルを呼び出して、ファイル名でファイルにアクセスできないようにレンダリングできます(たとえば、アクセスを続行するには以前に割り当てられたファイルハンドルが必要です)。ただし、unlink()edファイルは通常、そのファイルを所有するすべてのプロセスが終了すると削除されますopen()。プログラムが終了しても、そのファイルへのハンドルをまだ保持している他のプロセスがある可能性があります。

2.)SysV IPC共有メモリは疑似ファイルシステムを介して表示されませんが、tmpfsLinux/proc/sysvipc/shmシステムコール(ハッカーの場合のみ)、libcラッパー、または最近はipcs -m -p -[tclu]こ​​のリストのいずれかで一致するプロセスIDを見つける必要があります。次に、プロセスをさらに確認します。

3.) 匿名でマップされた共有メモリ、この場合、メモリはどのファイルでもサポートされず、代わりにプロセスとすべての子プロセス間で最初にメモリが共有されます。私が知る限り、mmap()この匿名でマップされた共有メモリは、それを編集したプロセスが実行されると解放されますexit()。したがって、プログラムが終了し、その子プロセスもすべて終了した場合は、メモリを占有しないでください。

おすすめ記事