仮想マシンにメモリの問題があります。実行しようとしている操作の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()。したがって、プログラムが終了し、その子プロセスもすべて終了した場合は、メモリを占有しないでください。