Debian/Ubuntu ランダムディスク拡張

Debian/Ubuntu ランダムディスク拡張

debian 12(BookWorm)でmysql 8.0.34を実行します。

ディスクが着実に消費されているように見えますが、ディスクに入ったりディスクを検索したりすると、何もスペースを取らないようですが、ディスクがいっぱいになると、再び正常にリセットされるランダムな問題が発生します。全体のプロセスは約45分かかります。

Debian 12 を新規インストールすると、オペレーティングシステムにインストールされた唯一のサービスは mysql です。

最後の2つの画像は、約1秒で100%ディスク消費から44%に戻りました。

なぜこれが起こるのか、説明やデバッグの提案をしてくれてありがとう。

ここに画像の説明を入力してください。

lsof +L1 実行

コマンドPIDユーザーFDタイプデバイスサイズ/クローズNLINKノード名

mysqld 886068 mysql 521u REG 254,1 194824503296 0 29360306 /tmp/#29360306 (削除済み)

イルカに尋ねるべきですか?

ベストアンサー1

lsof +L1 実行

COMMAND      PID       USER   FD   TYPE DEVICE     SIZE/OFF NLINK     NODE NAME    
mysqld    886068      mysql  521u   REG  254,1 194824503296     0 29360306 /tmp/#29360306 (deleted)

これは開いている間に削除された一時ファイルであり、mysqldコマンドを実行するとサイズは約194 Gのようですlsof +L1

ファイルに含まれている内容を確認するには、/proc/<PID number>/fd/<FD number>プロセスがまだ存在し、開いている間はそのファイルにアクセスできます。したがって、この場合、たとえば、次のように試すことができます。

sudo file -L /proc/886068/fd/521

実際にどのタイプのファイルなのか調べてください。

MySQLデータベースを停止して再起動できますか?停止すると、mysqldファイルは「解放」され、ファイルシステムは自動的にそのファイルをクリーンアップします。あるいは、ほとんど無限の出力を生成する愚かなクエリを実行した可能性があるデータベースセッションを見つけることができる場合は、そのセッションを強制的に終了させることができ、mysqldそのセッションに関連する一時ファイルを閉じることがあります。

インターネットからMySQLサーバーにアクセスできる場合は、一部の侵入者やマルウェアがデータベースを悪用してデータベース内の一部のデータを「隠す」ことがあります。

一時ファイルのMySQL 8.0.xドキュメントから:

mysqld が終了すると、MySQL は一時ファイルを削除する準備をします。これをサポートするプラットフォーム(Unixなど)は、ファイルを開いた後にリンクを解除してこれを行います。欠点は、名前がディレクトリリストに表示されず、一時ファイルディレクトリを含むファイルシステムを満たす大容量一時ファイルを表示できないことです。 (この場合、lsof +L1mysqldに関連する大容量ファイルを識別するのに役立ちます。)

MySQLは、ソート(ORDER BYまたはGROUP BY)時に通常1つまたは2つの一時ファイルを使用します。必要な最大ディスク容量は次の式で決まります。

(整列された内容の長さ + sizeof(行ポインタ)) * 一致する行数 * 2

行ポインタのサイズは通常4バイトですが、非常に大きなテーブルの場合は将来大きくなる可能性があります。

特定のステートメントの場合、MySQLは隠されず、名前が#sqlで始まる一時SQLテーブルを生成します。

一部の SELECT クエリは、中間結果を保持するための一時 SQL テーブルを作成します。

したがって、システムはかなり大きな結果セットを含むいくつかのクエリを頻繁に実行し、中間結果またはソートのために大きな一時ファイルを生成する必要があるようです。

特定のクエリが頻繁に繰り返され、結果のソート要件に基づいて中間ファイルが生成される場合は、データベースがそのテーブルに効率的に事前アクセスできるようにするインデックスを追加することを検討する必要があります。頻繁に繰り返されるクエリに必要な方法でソートします。これもあなたに重要クエリのパフォーマンスが向上しました。

もちろん、実際のクエリを調べてアプリケーションがよりスマートな方法で実装できる愚かなクエリを生成していることがわかった場合、バグレポート(クエリを改善するための提案ができる場合)は、そのクエリを使用するすべての人に役立ちます。関連アプリ。

(私は実際にはDBAではありませんが、職場でDBAと何年も話し合った結果、適切な索引付けが不足しており、愚かな方法で何かを検索するアプリケーション生成クエリがデータベースのパフォーマンスの低下に関連する2つの最も一般的な問題であることがわかりました。重要ではないかもしれませんが、データ量が本番規模で増加すると、非効率性が明らかになります。

おすすめ記事