アドベントカレンダー企画4日目！
本日はDataikuを使う過程で個人的にすごく困って
テクニカルサポートに駆け込んだ内容のご紹介です。
Dataikuで重めの処理を実行していると
灰色のバックグラウンドで[DISCONNECTED] と出てしまうことがありました。
しばらく放っておくと元に戻って動くようになります。
サポートの方に診断ファイルを見てもらい、
メモリを使いすぎている処理でバックエンドがクラッシュした、
ということが判明しました。
フリートマネージャーからも、DSSの管理画面からも
メモリの使用状況を確認することはできません。
(ストレージの空き容量はフリートマネージャーから確認できます）
Dataikuの中で確認する方法は無いか探したところ、 新しいプロジェクトでも既存のものでも良いので Pythonのノートブックを作成して、
!top -o %MEMを実行すると現在のメモリ容量を多く使ってる順のプロセスが 確認できます。
↑
を見るとRの処理がかなりメモリを使っているようです。
クラッシュしたときはもっと使用中のメモリがひっ迫していました。
これは正常に動いているときにスクリーンショットを取ったものです。
!kill -9 2801043↑
のように!topしたときに一番左側に出てくるPIDを指定して
プロセスを強制終了させることができます。
2801043は適当なPIDで置き換えてください。
サポートの方に伺ったのですが、
メモリエラーなどで中途半端に中止(abort)した処理は
メモリを使ったまま生き残ってしまう、とのこと😱
DSSを再起動するとプロセスを終了させることもできます。
ですが、再起動させてはならない時などもあるときには
この操作でメモリの解放ができます。
この処理の問題はUSERがすべてdssuser+になっていて
どれが私が実行したものなのか、
他のユーザーが実行しているのか、
判別ができなくて他のユーザーに迷惑をかけてしまう可能性がある点です。
私がメモリエラーを起こしてしまったのはRの処理で
他のユーザーがRを使っていないのを確認していたので
Rを実行している処理でメモリ使用量が多いもの＝私の処理、
と判断してkillしました。
ユーザー名を表示させるなど、ユーザーを特定する方法は無いそうです…
メモリ解放できますが…デメリットもあるので
あくまで最終手段ということでお使いいただければと思います。
ちなみになぜこんなことが頻発してしまっていたのかというと、
cgroupの設定が適切ではなかったから、とのことでした。
仮想マシンをダウングレードしたからなのか、
cgroupの設定を手動で変更したからなのか、
（原因は不明）
全体のメモリ容量を超える量のメモリがcgroupとして設定されていたみたいです。
全体で1GBの容量しかないのに、上限が2GB(cgroup）となっていた、
みたいな状況でした。
寸劇テイストでお送りすると、
Ｒの処理「まだまだメモリ使っていいよね！頑張るね！！」
仮想マシン「いーやーーーー。もう無理。無念…」
～～ここでクラッシュ～～
仮想マシン「しばらく寝たら復活。なんだか前世の記憶があるぞ…？」
Ｒの処理「あ、仮想マシン生き返った！再挑戦しよう！まだ上限までは余裕だし！」
仮想マシン「いや、もう余裕無いってば…その上限、実際の容量超えてるから。ぐっ…またしても無念。」
～～繰り返す～～
プロセスをkillしてその場しのぎをするのも一つの手ですが、
何回もクラッシュしてDisconnectedのような画面が出る場合は
cgroupの設定が正しいか確認してみてください。
cgroupの設定に関するドキュメントはこちらです。
お読みいただきありがとうございました！
アドベントカレンダー企画、まだまだ続きます！
