datauku notebookのメモリ使用について

Satoshi_NES

DSS13.5.4（カスタムインストールの13.3.2からバージョンアップ）を使用しています。

Pythonコードをテストするためにnotebookを使用していたのですが、notebookのメモリ使用量が7.4GByte付近になると処理が停滞（一見フリーズしているように見える）ため、install.iniに以下の設定を行いました。

backend.xmx = 32g　（もとは8g）

jek.xmx=20g　（sン機追加）

上記設定にり２０G付近までメモリを使用する処理でも処理が停滞せず動作するようになったのですが、上限をこえるとカーネルが落ちるようになりました。

元々の状態と動作が変わっていますが、これは想定通りの動作なのでしょうか？上記以外に何か追加の設定が必要なのでしょうか？

停滞するのはそれはそれでよくないので、必ずしも元と同じ状態にしたいわけではないのですが、動き変わってしまっているので気になっています。

Operating system used: ubunts 22.0.4LTS

Tsuyoshi

＞元々の状態と動作が変わっていますが、これは想定通りの動作なのでしょうか？上記以外に何か追加の設定が必要なのでしょうか？

想定通りの動作であると考えられます。以下ドキュメントに記載のようにjek.xmxのデフォルト値は2Gとなります。
https://doc.dataiku.com/dss/latest/operations/memory.html#the-jek

Pythonで大量なメモリーを消費する処理を実行した場合、以下のドキュメントに記載のように実行基盤（Java）のプロセスでGCが頻発し、フリーズしたような状態になっていたと考えられます。
https://blog.dataiku.com/how-dataiku-sandboxes-java-to-avoid-heaps-of-garbage

jek.xmxを20gに変更して、ヒープサイズが大きくなったことにより、元々は何とか小刻みにGCしようとしてフリーズしていた挙動から、ヒープ上限を超過した瞬間にOutOfMemoryExceptionが発生する挙動に変わったものと推測されます。

ただ、以下のリンクにも記載のように、JEKにあまり大きな値を設定することは推奨していないため、根本的な対応としては、Pythonコードの実装を変えることができれば、その方が望ましいとは思います。
WARN_JVM_CONFIG_KERNEL_XMX_OVER_THRESHOLD

実現したい処理内容によっては、コードの変更が難しい可能性もあるとは思いますが、ご質問いただいた内容に関する見解としては上記のようになりますので、まずは回答させていただきます。

Tsuyoshi

ちなみに、お問合せをいただいた事象（メモリー使用量の増大）について、扱うデータサイズが大きいことが原因である場合、以下のような対応方法が考えられますので、こちらも参考にしていただけますと幸いです。

案１：Pythonコード側で可能な対応としては、例えば以下のリンクに記載のようにDataFrameのチャンクサイズを絞って逐次処理するなどの案が考えられます。
https://community.dataiku.com/discussion/comment/44716/#Comment_44716

案２：Pythonコード、扱うデータ自体を変えることが難しいような場合、Dataikuサーバのメモリーを利用するのではなく、以下ドキュメントに記載のようにKubernetesやSparkと連携して、外部リソース側で分散処理させる案も考えられます。
https://knowledge.dataiku.com/latest/data-preparation/pipelines/concept-pipeline-optimization.html#recipe-engine-checks
https://knowledge.dataiku.com/latest/cloud-quotas-compute/reference-leveraging-elastic-ai.html

Satoshi_NES

回答ありがとうございます。

ツール側の都合もあり、一旦は十分なメモリを割りてることでの対処とし、ツール側のおおよその動作も確認しました。リソース分散に関してはツール側とも相談してみることといたします。