夏休みに入ったことだし、めっちゃ久々の技術メモ（…タイトルがなろう系っぽいなぁ…）。
ちょっと前に、客先サーバで「開発サーバのアプリが起動しないから調べろ」って連絡があって延々とつきあわされて、結局客側で設定したパラメータがあほちんだった件。
といっても、こっちも中々原因に辿り着けなかったので、今後のためにもメモ。
事の発端
システム更改によるvMotion後、ESXi筐体のCPUを正しく認識させるために仮想マシンの上げ落としを実行。
直後にメモリ食い尽くし現象が発生して、客のアプリが起動できなくなった。
原因
犯人は客側のアプリ構築チーム（当時）
sysctl.confで、hugepagesがアホな数字（物理メモリのXX倍）になってた…
どうやら本番環境（開発の数倍のスペック）と同じパラメータ仕込んでだらしい…
（そして仕込むだけ仕込んでおいて、sysctl -pも再起動もしてなかったから、数年経過後に発覚…）
やったこと
topとpsで動いてるプロセスとメモリをバカ食いしてるプロセスがないか確認。
しかし、何やってもバカ食いプロセスが見つからない。
「仮想マシンだからメモリ増やしてみたらいんじゃね？」って倍にしてみたけど、それでも増やしただけメモリを食い尽くして全然解消されない。
んで、あれこれググってみた結果「あれ？もしかしてhugepageおかしくね？」ってなったので、hugepageの状態を確認することに。
叩いたのが以下のコマンド。
#物理メモリの状態確認
cat /etc/meminfo
#sysctl.conf上の設定値確認
cat /etc/sysctl.conf
#実機の状態の確認
sysctl -a | grep hugepage
そしたら…sysctl.confに設定されてたvm.nr_hugepagesの値が…恐ろしい数値に…
そりゃ物理メモリ食い尽くされるし、仮想マシンのメモリを倍に増やしたって追いつくわけないよ…
本番環境側の設定値と比較してみたら、案の定本番用の値が開発用に入ってた事が判明したので、本番側の物理とhugepagesの割合を確認した上で、開発側も同程度の割合でsysctl.confの記述修正して、再起動。
無事にアプリのプロセスが起動することを確認できた…はいいんだけど、どこのどいつだ、本番のパラメータを開発環境に入れたアホは…
おまけ：hugepagesの計算
vm.nr_hugepagesの値（ページ数）×2MiB＝hugepageが確保する物理メモリの数値
上記で計算した結果、vm.nr_hugepagesが物理メモリよりも遥かに大きな値で設定されていた場合、値を下げるか、メモリをhugepagesで確保するよりも大きな値に増設する。
ちなみに、sysctl.confがどんなに大きな値を設定していても物理メモリ以上には確保できないので、sysctl -a | grep hugepage の値は物理メモリよりは大きくならない。