nabeの雑記帳

[7934037.757829] Node 0 DMA: 43*4kB (UME) 14*8kB (UME) 12*16kB (UE) 13*32kB (UME) 2*64kB (UE) 7*128kB (UME) 4*256kB (UME) 3*512kB (UME) 0*1024kB 0*2048kB 0*4096kB = 4476kB
[7934037.762116] Node 0 DMA32: 258*4kB (UME) 252*8kB (UME) 576*16kB (UME) 325*32kB (UME) 105*64kB (UME) 20*128kB (UME) 8*256kB (UE) 3*512kB (UME) 5*1024kB (UME) 0*2048kB 1*4096kB (M) = 44744kB

どれくらいのサイズの連続したメモリをいくつ確保できるかという表示ですが、一番大きいもので「DMA側が512kBを3つ」「DMA32側が4096kBを1つ」ということで、メモリの断片化してますし、そもそも両方合わせて48MBぐらいしか空きメモリがない。

OOM Killerが発生して当然の状況と言えます。

なぜApacheが死んだのか

OOM Killerが発動したのは、sys.fcgiというFastCGI（Apacheの子）プロセスなのですが、なぜかApache自体が死亡しておりました。daemon.logを見ますと、こんな感じ。

systemd[1]: apache2.service: A process of this unit has been killed by the OOM killer.
systemd[1]: apache2.service: Failed with result 'oom-kill'.
systemd[1]: apache2.service: Consumed 1h 21min 18.835s CPU time.

Apacheの子プロセスがOOM Killerされたので、systemdが善きに計らってApache自体を終了させた模様。……やめてくれー（苦笑）

子プロセスが死んでもApacheを生かす

メモリ食いつぶしcgiを作って実験してみたのですが、通常のcgiなら問題なくFastCGIのときだけこの問題が起きるようです。systemdの設定を変更して、Apacheを巻き添えにしないよう変更します。

# Debianの場合, rootでの作業
cd /etc/systemd/system
mkdir apache2.service.d
vi apache2.service.d/oom.conf
systemctl daemon-reload

# oom.confの中身
[Service]
OOMPolicy=continue

/etc/system/systemd/apache2.service.d/oom.conf がきちんと読み込まれてるか、設定を確認してください。

systemctl cat apache2

この状態でメモリ食いつぶしfcgiを実行してみましたが、無事(?)にfcgiだけプロセスkillされました。

その他の対策

Swap領域を3.7GBから10GBに増強。
sys.fcgiで不要になったメモリを開放することが難しかったので、メモリ使用量（/proc/[pid]/statusのVmHWM）が一定量を超えたら、処理終了後に自動でプロセスを終了するようにした。
mod_fcgidの設定を変更して、一定時間使われないプロセスはすべて終了するようにした。
```
FcgidMinProcessesPerClass	0
FcgidProcessLifeTime		600
FcgidIdleScanInterval		120
```

スワップは実RAMの倍（この場合2GB）という定説を昔読んだ気がしますが、「未開放メモリ→スワップアウト」というケースを考えると、多いに越したことはないかもしれません。

本当はApache側でメモリ制限を実施できたら楽なのですが、mod_fcgidの子プロセスには RLimitMem とか効かないんですよね……。

参考サイト

OOM Killer発動時にサーバーを再起動する方法

コメント（0件）

2022/05/20(金)Dell S150 に Software RAID で Ubuntu 22.04 をインストール

Linux戯言::技術

Dell PowerEdgeサーバに乗っているなんちゃってRAIDコントーラーS150を使用した状態で、Ubuntu Desktop 22.04をインストールしたメモ。

S150とは

よくあるBIOSでRAID化するだけの、実質ソフトウェアRAIDです。S150はLinuxのRAIDに対応しており、BIOSからLinuxで作成したRAID情報を参照できるようです。

つまりRAID化した状態でLinuxをインストールすることができれば、そのRAID化されたディスクから起動することも可能です。

Ubuntu Desktop 22.04のインストール

ミラーリング（RAID1）に設定する場合。

BIOSの設定からSATAのモードを「AHCI」から「RAID」に切り替えます。
Ubuntu Desktop 22.04をインストールイメージから起動します。
インストールではなく「Ubuntuを試用する」を選択します。
Terminalを開き、mdadmをインストールします。
```
sudo apt-get install mdadm
```
ディスク全体でRAIDを構築します。
```
sudo mdadm --create md0 --level=1 --raid-disk=2 /dev/sda /dev/sdb
```
/dev/md127 として認識されます。
この状態で、Ubuntuをインストールします。インストール先はディスク全体を削除してインストール（自動選択でmd127）です。md127に2つのパーティションが作られます。
「grub-install /dev/sda の実行に失敗しました」というメッセージが出たら再起動せずにウィンドウを閉じます。
/targetにRAIDディスクの/（md127p2）がマウントされていますので、ターミナルで以下の操作をします。
```
sudo su
cd /target
mount --bind /dev dev
mount --bind /sys sys
mount --bind /proc proc
cp /etc/resolve.conf etc/
chroot .
mount /boot/efi
apt install mdadm
grub-install
```
これにより /boot/efi に必要なファイルが配置されますが、EFIブートメニューへの登録には失敗します。

EFIブートメニューに項目を登録します。

efibootmgr -c -d /dev/md127 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'

あとはターミナルを抜けて普通に再起動すれば、RAID状態のディスクからUbuntuが起動します。

メモ

# EFIメニュー登録状態の確認
efibootmgr -v
# EFIメニューの項目削除
efibootmgr -B -b 0001
# Software RAIDの状態確認
cat /proc/mdstat

# /etc/defult/grub
GRUB_RECORDFAIL_TIMEOUT=3
GRUB_DISABLE_SUBMENU=y

カーネルだけ更新

v5.17.9の場合。

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-headers-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-headers-5.17.9-051709_5.17.9-051709.202205180947_all.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-image-unsigned-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-modules-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-modules-iwlwifi-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb

dpgk -i *.deb

コメント（0件）