web-dev-qa-db-ja.com

パーティション化により、mariadbのCPU使用率が増加します

私はmariadb 10.2を使用していて、以下のような構造のテーブルがあり、現在は15 GBで、特定のアカウント(AccountId1)の各バッチで、毎分数千のレコードを常に挿入しています。

AccountId1 bigint PK,
AccountId2 bigint PK,
ActionType int,
ActionDate timestamp

プロセスリストを見ると、このテーブルで複数の挿入が並んで待機しており、それらは常に一度に1つの挿入を実行していたため、AccountId1のハッシュによってこのテーブルをパーティション分割し、32のパーティションを作成することにしました。

インサートはピーク時の1秒あたり1または2から8に急増しました。問題は、変更後にCPU使用率が15%から40%に急上昇し、挿入プロセスを数時間完全に停止しても、CPUが停止しないことです。

cpu usage before and after partitioning

すべてのパーティションにまたがる可能性があるこのテーブルから選択する場所はいくつかありますが、これらは数時間ごとに実行されるプロセスであり、それほど長くはかかりません。他の頻繁なクエリは常にAccountId1フィールドを使用し、実際にクエリプランを見て単一のパーティションをクエリしています。

SQLがそのテーブルにアクセスしていない場合でも、パーティショニングに関連するオーバーヘッドはありますか?このCPUの増加の理由は何ですか?

注:常時約2000の同時接続がありますが、パーティショニングの前後の接続数は同じでした。

2
Natan

オーバーヘッド

理解する必要があるのは、分割テーブルの物理的な実装です。

たとえば、以前の投稿(Aug 31, 2014実際にサブパーティショニングはどのように機能し、どの物理ファイルが作成されるのですか? )で、パーティションテーブルが次のように表示されました。

C:\>cd \MySQL_5.6.15\data\test

C:\MySQL_5.6.15\data\test>dir nums_comp*
 Volume in drive C is TI10665200H
 Volume Serial Number is A273-2EFF

 Directory of C:\MySQL_5.6.15\data\test

08/31/2014  04:09 PM            98,304 nums_composite#p#p0#sp#p0sp0.ibd
08/31/2014  04:09 PM            98,304 nums_composite#p#p0#sp#p0sp1.ibd
08/31/2014  04:09 PM            98,304 nums_composite#p#p1#sp#p1sp0.ibd
08/31/2014  04:09 PM            98,304 nums_composite#p#p1#sp#p1sp1.ibd
08/31/2014  04:09 PM            98,304 nums_composite#p#p2#sp#p2sp0.ibd
08/31/2014  04:09 PM            98,304 nums_composite#p#p2#sp#p2sp1.ibd
08/31/2014  04:09 PM             8,594 nums_composite.frm
08/31/2014  04:09 PM                96 nums_composite.par
               8 File(s)        598,514 bytes
               0 Dir(s)  686,691,409,920 bytes free

C:\MySQL_5.6.15\data\test>

Feb 16, 2015に別の例があります: MySQL Create Table with Table Partition on Slow on server machine

各パーティションは、個別のテーブルスペースを持つ個別のInnoDBテーブルとして扱われます。

どのようなオーバーヘッドが存在しますか?

これらのことはオーバーヘッドを説明するのに役立ちますが、CPUアクティビティがどこから発生しているのか疑問に思われるはずです???

CPU

開いているファイルハンドルに基づくCPUアクティビティはまだいくつかあります。どうやって ?

オプションinnodb_open_filesは、MySQLインスタンスを介してすべてのInnoDBテーブルに対するオープンファイルハンドルの数を制限します。

監視ソフトウェアでテーブル情報を調べる必要がある場合、クエリを増やすとCPUが増えます。

ディスクにアクセスしないクエリ(SHOW PROCESSLIST;SHOW GLOBAL STATUS;など)がある場合、またはINFORMATION_SCHEMAから読み取る場合は、CPUを増やします。 (2011-08-10からの古いServerFault投稿を参照してください 24日間で10億のmysqlクエリ?何か問題はありますか?

特定のテーブルにアクセスし、16KページをInnoDBバッファーに読み込むか、InnoDBバッファープールのページを古いものとしてマークするために、ファイルハンドルを開いたり閉じたりします。

2
RolandoMySQLDBA