mysql8が、OSの残りメモリをどんどん奪っていく現象が発生していたので、ググって調べてみると、日本語ページでは、table_definition_cache を 400に設定するという解決策が見付かった。

もう少し調べていくと、以下のページに辿りついた。バージョンは5.6についてだった。

https://bugs.mysql.com/bug.php?id=68980 Bug #68980 MySQL 5.6 memory usage too high

https://bugs.mysql.com/bug.php?id=68287 Bug #68287 High Memory Usage with MySQL 5.6.12 GA in “Development Machine” mode

performance_schema が ON になっていると table_definition_cache の設定値に関連したメモリを消費することになるという理解で良いんだろうか？

対策としては、performance_schema を OFF にするか、table_definition_cache の値を影響が問題ないレベルの値に下げることが必要らしい。

上のリンク先ではバグとして起票されているけど、mysql8でも同様の動作なのかな？ performance_schema ON の時に受ける恩恵により判断したいところ。

https://dev.mysql.com/doc/refman/5.6/ja/performance-schema.html MySQL パフォーマンススキーマは低レベルで MySQL サーバーの実行をモニタリングするための機能です。

パフォーマンススキーマをOFFにしても良さそうなんだけど、performance_schema の設定を変更するには、my.cnf に設定して再起動が必要だが、table_definition_cache は、ダイナミックに変更可能なので、最初の一手としては、table_definition_cache の値を問題がない値に様子を観ながら下げるという対応が妥当に思う。 最小値の400まで下げても改善しなければ、performance_schema を OFF にするしかないということか。

https://dev.mysql.com/doc/refman/5.6/ja/performance-schema-startup-configuration.html サーバー起動時に設定されていない (または −1 に設定されている) 自動サイズ設定される各パラメータについて、パフォーマンススキーマは、次のシステム変数の値に基づいてその値を設定する方法を判断します。それらは、MySQL サーバーをどのように構成しているかに関する「ヒント」とみなされます。 * max_connections * open_files_limit * table_definition_cache * table_open_cache

パフォーマンススキーマの設定値は、サーバー起動時に設定されるので、table_definition_cache を動的に変更しても、パフォーマンススキーマの動作には影響しなさそうだった。 確認は次回再起動後に行なう予定

追記 2023-02-07

上記対応は、決定的な解決はしませんでした。

続きエントリを書きました。 mysqlがどんどんメモリを食ってOOM Killerに殺される