過負荷状態でスワップ空間に到達するとマシンが停止する

過負荷状態でスワップ空間に到達するとマシンが停止する

私のコンピュータが何度もクラッシュしました。また、メモリをすべて埋めるプログラムを実行しても再現が可能です。システムがスワップファイルへの書き込みを開始するとすぐに、システムがハングして再起動する必要があります。

ログには、競合が発生する前に、次の便利なログ情報は表示されません。

Mar 23 19:12:01 classen systemd[1]: Starting Cleanup of Temporary Directories...
Mar 23 19:12:01 classen systemd[1]: Started Cleanup of Temporary Directories.
Mar 23 19:12:08 classen wpa_supplicant[757]: wlp3s0: WPA: Group rekeying completed with ...
-- Reboot --
Mar 23 19:17:03 classen systemd-journald[380]: Runtime journal (/run/log/journal/) is 8.0M, max 796.6M, 788.6M free.

実際、私はこの問題をどのように解決するのかわかりません。誰かが似たようなものを見て、正しい方向に私を指すことを願っています。奇妙なことに、しばらく作業した後、私のシステムはある程度スワップを実行できました(少なくともtopスワップスペースの一部が使用されたことを示します)。ストップは、スワップファイルの負荷が厳しい場合にのみ発生します。


これは私の設定です。

$ lsblk

NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                       8:0    0 238.5G  0 disk  
├─sda1                    8:1    0   512M  0 part  /boot
└─sda2                    8:2    0   238G  0 part  
  └─MyStorage           254:0    0   238G  0 crypt 
    ├─MyStorage-swapvol 254:1    0    16G  0 lvm   [SWAP]
    └─MyStorage-rootvol 254:2    0   222G  0 lvm   /
sdb                       8:16   0 931.5G  0 disk  
└─sdb1                    8:17   0 931.5G  0 part  
sr0                      11:0    1  1024M  0 rom   

関連部品/etc/fstab:

/dev/mapper/MyStorage-rootvol   /    btrfs   rw,noatime,ssd,autodefrag,compress=lzo,space_cache      0 0
/dev/mapper/MyStorage-swapvol none   swap    defaults        0 0

UUID=63A7-3F81          /boot        vfat    rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro    0 2

$ swapon --summary

Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   16777212    0   -1

私は4.4.5カーネルでArch Linuxを実行しています。

$ uname -a
Linux classen 4.4.5-1-ARCH #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 x86_64 GNU/Linux

接続/etc/mkinitcpio.conf:

HOOKS="base udev autodetect modconf block encrypt lvm2 resume filesystems keyboard fsck"

ベストアンサー1

いくつかの実験では、巨大なスワップパーティション(16 GB)で使用すると、実際にクラッシュが発生することがわかります。

OtheusとCasのコメントありがとうございます。直感が正確でした。私はその効果を過小評価した。おそらく、以前使用していたコンピュータのスワップ領域がメモリに比べて小さくなったため、メモリを大量に消費するプロセスが最終的に終了した可能性があります。

いくつかの安全対策は、システムの最大スワップスペースを減らします。また、単一プロセスのメモリ不足を防ぐために、プロセス固有の制限を定義しました。

# limit memory usage to 10G per process
ulimit -Sv 10000000

このようなツールはvmstat 1問題を分析するのに役立ちます。

おすすめ記事