須藤 様
有本です。
ご回答いただきましてありがとうございます。
DROP TABLEの動作仕様に関してもご解説ありがたく存じます。
仕様としてはデータベースを指定してなんらかのMroongaに関する動作が行われ
た段階で該当データベースに対して .mrn 系のファイルが生成される
と認識致しましたが合っておりますでしょうか。
> が、たしかに、Mroongaを使っているテーブルが存在しないときは
> 必要ないので作らないようにしました。
弊環境にご配慮くださいまして感謝いたします。
> ちなみに、SELECT mroonga_command('status')をすると.mrnファイ
> ルはできるので気をつけてください。
承知いたしました。
今後の実施時は気を付けたいと存じます。
> ところで、このときにできる.mrnファイルでメモリーを圧迫すると
> いうのはよほどたくさんデータベースが存在するんですか？それと
> ももともとメモリーがカツカツなシステムなんですか？
サーバの物理メモリは16GBでデータベース数が約400ほど存在しますが
バックアップ用途のためglobal bufferの類のものは控えめに設定し
OS上でのメモリused値としては2～3GB程度で運用をしておりました。
後だしで恐縮なのですが、
もともとMariaDB 10.1の環境で利用していた際はこの現象は発生していなかった
のですがこの度10.5にアップグレードした後にこの現象が発生したため調査して
おりました。(mroongaやgroonga-libsを最新版に変更もメモリ利用増）
以前はMroongaエンジンのテーブルが存在するデータベースでしか.mrn系のファ
イルがなかったと記憶していたので今回嫌疑をかけてしまったのですが記憶違
い＆見当違いでしたら大変申し訳ありません。
特殊な例だとは認識しておりますので仕様的にどうしてもリソースが必要に
なってくる場合はスケールアップまたはスケールアウトもしくは
搭載データベース数を削減させる方向で解決を図る所存ではございます。
以上、何卒よろしくお願いいたします。
>
> 須藤です。
>
> MySQL/MariaDBは存在しないテーブルをDROP TABLEすると登録され
> ているすべてのストレージエンジンに対して指定されたテーブルを
> 削除してとお願いに回るのですが、Mroongaにそれがまわってきた
> ときは.mrnファイルを作るようになっています。これらはMroonga
> 内の各種操作すべてに必要になるファイルです。
>
> が、たしかに、Mroongaを使っているテーブルが存在しないときは
> 必要ないので作らないようにしました。
>
> ちなみに、SELECT mroonga_command('status')をすると.mrnファイ
> ルはできるので気をつけてください。
>
> ところで、このときにできる.mrnファイルでメモリーを圧迫すると
> いうのはよほどたくさんデータベースが存在するんですか？それと
> ももともとメモリーがカツカツなシステムなんですか？
>