[2023/6/1 のメンテナンスでMariaDBが10.4から10.6へバージョンアップされましたので記事の内容が古くなっています]
WordPressの執筆ですごく遅くなったり速かったりと安定しない感じがしていたので、記録をとって調べてみました。
続編はこちら→「続：CORESERVER(コアサーバー) V2のMariaDBが遅いっぽいので調べてみた」
契約サーバはAMD EPYC 7502の64コア、メモリ1TB、オールSSDで、データベースは MariaDB 10.4.20 です。CORESERVER（コアサーバー）
V2 CORE-Xプランでのリソース制限はCPU 300%(公式サイトの表現)、メモリ6GBですが今回はあまり関係ないかな。
記録結果
折れ線グラフ（目盛りは左）はテーブルをtruncateしてinsertを100回実行する処理時間を記録したもの。20回実施しての最大、平均、中央値をプロット。棒グラフ（目盛りは右）は同時刻での接続スレッド数と実行スレッド数で、Global status のThreads_connected と Threads_running を拾っている。ちなみに左の目盛は対数になっているので等間隔ではありません。
見ての通り接続数が多いと遅いです。深夜少なければ20ミリ秒(以降ms)以内では終わる処理(計測では20回分なので20倍の処理時間)で、1,000〜5,000msはちょっとなぁという感じ。20ms x 20=400ms の処理が 5,000ms x 20=100,000ms=100s ですよ！？
メモリ、バッファー関係の確認
バッファー関連の数値は潤沢に割当てられていました。公開は省略。
ちなみにinnodb_buffer_pool_sizeは128 GBytesでした。
コネクション関係の確認
Global variablesのmax_connectionsが1,800の設定でこれは良いとして、innodb_thread_concurrencyが32となっていました。ここが怪しいです。
(2021/10/27時点の契約サーバの設定となります)
innodb_thread_concurrencyについて、色々ぐぐりましたよ。
- 同時に実行されるスレッド数を制限するためのもの
- あふれたスレッドはinnodb_thread_sleep_delayの時間待機させられる
- innodb_thread_sleep_delayは動的に変化する（はじめはちょい待ちとかそんな感じで最大innodb_adaptive_max_sleep_delay(150ms)の値まで
- デフォルトはゼロで実行スレッド数に制限はなし
- MariaDB 10.4 では現役のパラメータ
- MariaDB 10.5 で非推奨となり無視され、10.6で削除された
さて、あらためてグラフをみると、スレッド数32近辺を堺にして極端に遅くなっているようにも見える。。。。
検証
innodb_thread_concurrency以外が同じ条件でmysqlslapを使ってローカル環境のMariaDB 10.4で検証してみました。
# mysqlslap \ --no-defaults \ --concurrency=50 \ --iterations=10 \ --engine=innodb \ --auto-generate-sql \ --auto-generate-sql-add-autoincrement \ --auto-generate-sql-load-type=mixed \ --auto-generate-sql-write-number=1000 \ --number-of-queries=100000 \ --host=localhost --port=3306 --user=root --password=xxxxx
innodb_thread_concurrency = 0
Running for engine innodb Average number of seconds to run all queries: 16.126 seconds Minimum number of seconds to run all queries: 15.187 seconds Maximum number of seconds to run all queries: 17.318 seconds Number of clients running queries: 50 Average number of queries per client: 2000
innodb_thread_concurrency = 20
Running for engine innodb Average number of seconds to run all queries: 23.017 seconds Minimum number of seconds to run all queries: 18.461 seconds Maximum number of seconds to run all queries: 30.127 seconds Number of clients running queries: 50 Average number of queries per client: 2000
50クライアントのテストなので、20に制限すると遅くなる。かつ、最小と最大の開きがありばらついている（と想定される）
制限なしの状況では安定した処理結果となっている。（実行マシンに余裕がある）
最後に
CPUやメモリはユーザごとの割当てがあり、PHP実行などは制限がかかるのですが、DBについてはユーザプロセスではないのでCPU制限かからないということもあり、サーバーを安定稼働させるためにも設定しているのだとは思います。
1サーバにどのくらいのユーザを収容して、どのくらいのアクセスを見込んでいるのかなどは戦略なので、いろいろあるとは思うが、全体のリソースに余裕があるのなら緩和してもらいたいなぁと思ったり。ダメ元で要望出してみようかなぁ。余裕あるんじゃないかなぁ。
ブレ幅が大きいのが嫌なので、あまりにもひどくなるようだと、他のレンサバも考えないとならないかも。
おまけ：さくらスタンダード
MySQL 5.7.32、innodb_thread_concurrencyは0で設定されていました。
常時20〜30接続くらいで、処理時間は200ms〜300msで、安定して遅いです。でも極端に遅くなることはなかった。
コメント