OceanBase Sysbenchにおけるパフォーマンス問題の分析

Sysbenchテスト中にOceanBaseデータベースが直面するパフォーマンス問題を徹底的に分析し、ボトルネックの特定、構成の最適化、パフォーマンスチューニングを通じて解決策を提供し、高同時実行環境下でのデータベースの安定性と効率の向上を支援します。また、参考となるパフォーマンス問題の事例もいくつか提示し、ユーザーが直面する可能性のあるパフォーマンス問題の解決を支援します。

Sysbenchの問題を迅速に特定する方法

SysbenchでTPSが想定より低い、変動が大きい、0に低下したり異常終了したりする場合は、まず迅速な問題特定と調査の方法を採用する必要があります。

問題1：SysbenchのTPSが想定より低い

問題の調査手順は以下のとおりです：

1. Sysbenchパラメータを分析します。

   まず、Sysbench実行コマンド内のパラメータを分析します。

   • --rand-type=special を設定しているか、--rand-type パラメータが設定されていない場合は、データ間のロック競合を減らすために --rand-type=uniform に設定できます。

   • テーブルの数やサイズが小さすぎる場合は、データセットを拡大できます。例：tables=100，table_size=1000000。

   • read_write または write_only シナリオの場合、デッドロックが発生していないか確認して検証できます：

     SELECT * FROM oceanbase.cdb_ob_deadlock_event_history ORDER BY create_time DESC LIMIT 10;
     

2. 接続方式を確認します。

   • Primary Zoneが単一ゾーンでOBServerノードに直接接続している場合、接続先がLeaderであることを確認します。
   • Primary ZoneがRandomの場合、テストを行うにはOBProxyに接続する必要があります。

   1. テナント情報を照会します。

      SELECT * FROM oceanbase.dba_ob_tenants;
      

   2. テナントLeaderを照会します。

      SELECT svr_ip, sql_port, count(1) FROM oceanbase.cdb_ob_ls_locations WHERE tenant_id=1 AND role='leader' GROUP BY svr_ip;
      

3. CPU負荷を観察します。

   Sysbenchのパラメータとクライアント接続方式に問題がない場合、CPU使用率を確認してさらに調査を進めることができます。

   • スレッドのCPU使用率を確認します。

     top -H -p pidof observer
     

     各業務スレッドがほぼ1つのコアを使い切っている場合、次にスレッド数がマシンのコア数に近いかどうか確認します。

     • 業務スレッド（例：T1002_L0_G2）の数がマシンのコア数より大幅に少なく、CPU総負荷もマシンの上限に達していない場合、おそらく cpu_count の割り当てが少なすぎるためです。この場合、テナント作成コマンドを確認し、cpu_count が低すぎる設定になっていないか確認できます。
     • CPU総負荷がマシンの上限に近い場合、マシンの性能は限界に達しており、より高い性能を出すには、より高い構成のマシンを使用する必要があります。

   • テナント仕様を確認します。

     show create tenant xxx;
     SELECT * FROM oceanbase.dba_ob_resource_pools;
     SELECT * FROM oceanbase.dba_ob_units;
     

     業務スレッドが1つのコアを使い切っていない場合（例：CPU使用率が20%～50%）、他の部分でボトルネックが発生しています。

     • ネットワークスレッド（例：RpcIO）が1つのコアを使い果たしている場合、ネットワークスレッドの数が少なすぎてネットワーク通信がボトルネックになっている可能性があります。この場合は、スレッド数 net_thread_count を増やす必要があります。
     • すべてのスレッドのCPU利用率が高くない場合、ハードウェア側がボトルネックになっている可能性があります。その場合は、さらに分析を進める必要があります。

4. ハードウェア上の原因を分析します。

   CPU要因を除外した後、残りのハードウェア上の原因は主にディスクとネットワークです。ディスクおよびネットワークの問題の調査手順は以下の通りです。

   1. NICの帯域幅上限を確認し、テスト時にネットワーク帯域幅がボトルネックになっていないか観察します（SysbenchをOBServerマシン上にデプロイしてテストを実行できます）。
   2. ネットワーク遅延（ping）を確認します。遅延が高すぎるとSQL実行が遅くなる可能性があります。
   3. ログディスクの16K書き込み帯域幅上限（FIOテストによる）を確認し、テスト時にディスクI/Oがボトルネックになっていないか観察します（SSDまたはNVMeに交換してテストを実行することもできます）。

   ネットワークI/Oを確認するコマンド：

   sar -n DEV 1
   

   NIC帯域幅上限を確認するコマンド：

   ##(eth0はNIC名)
   ethtool eth0
   

5. その他。

   上記の要因を除外しても、業務テスト時間帯とobserverバックグラウンドタスクの競合など、特殊な状況が存在する可能性があります。

   あるユーザーから、業務テスト中に、2つのデータセットの値が予想を大幅に下回っていることが判明したという報告がありました。様々な設定を確認したものの、明らかな問題は見つかりませんでした。最終的に、そのユーザーが業務テストを実施したのは午前2時であり、この時間帯がOceanBaseデータベースの日次ダンプ・メジャーコンパクションのデフォルトの実行時間であったことが判明しました。そのため、データベースのパフォーマンスが大幅に低下していたのです。

問題現象2：Sysbench TPSが変動または0に低下する

Sysbench TPSが変動または0に低下した場合、以下のような状況が考えられます。

TPSが時折わずかに変動する

• 考えられる原因：OceanBaseデータベースは定期的にダンプ・メジャーコンパクションを実行し、CPUリソースを占有するため、業務スレッドに影響を与えます。cpu_countが多いほど影響は小さくなります。例えば、4c8gのテナントでは、ダンプ時にTPSが80%低下する可能性があります。32c64gのテナントでは、ダンプ時にTPSが10%低下する可能性があります。

• 対処方法：

  1. テナントリソースユニットのmax_cpuを引き上げます。

  2. テナントCPU並列度を引き上げます。

     alter system set cpu_quota_concurrency=4 tenant = xxx;
     

  3. ダンプスレッド数(merge_thread_count)を減らすか、スレッド優先度(compaction_high_thread_score, compaction_mid_thread_score, compaction_low_thread_score)を下げることで、単位時間あたりのダンプコストを削減できますが、時間的な代償が伴います。ダンプ全体のコストは変わりません。

TPSが一時的に0に低下した後、間欠的に回復する

• 考えられる原因：デッドロックが発生し、Sysbenchで--mysql-ignore-errors=1062,1213,6002;が設定されている場合。
• 対処方法：

  1. まず、デッドロックが発生していないか確認します。

     SELECT * FROM oceanbase.cdb_ob_deadlock_event_history ORDER BY create_time DESC LIMIT 10;
     

  2. 確認後、次の操作を実行します。

     1. Sysbenchに--rand-type=uniformパラメータを追加します。
     2. データセットを増やします。例：tables=100，table_size=1000000；（table_sizeのデフォルトは10000です）。

TPSが0に低下した後、回復しない場合

• 考えられる原因：デッドロックが発生し、それが検出されなかったこと、およびタイムアウト時間が長く設定されていたため、TPSが0に落ちた後もエラーが発生せず、終了せず、回復しない。
• 対処方法：

  1. まず、デッドロックが発生していないか確認します。

     SELECT * FROM oceanbase.cdb_ob_deadlock_event_history ORDER BY create_time DESC LIMIT 10;
     

  2. 確認後、次の操作を実行します。

     1. Sysbenchに--rand-type=uniformパラメータを追加します。
     2. データセットを増やします。例：tables=100，table_size=1000000；（table_sizeのデフォルトは10000です）。

TPSが0に低下した後、すぐに回復する場合

• 考えられる原因：Clogが満杯で書き込みできなくなり、TPSが0に落ちたが、その後Clogのスペースが回収され、TPSが回復した。

• 対処方法：テナントのディスク使用量を確認します：

  SELECT tenant_id, svr_ip, svr_port, log_disk_in_use, log_disk_size FROM oceanbase.gv$ob_units;
  

  より大きなディスク容量の割り当てを検討します。

上記の原因を除外しても問題が解決しない場合は、テクニカルサポートにお問い合わせください。

問題現象3：Sysbenchが異常終了またはエラーを報告する場合

TPSが一時的に0に低下した後、間欠的に回復し、時折エラー6002または1213が発生する場合

• 考えられる原因：デッドロックが発生し、データセットが小さすぎるかrand-typeが設定されていないため、デフォルトのSpecialタイプではKeyの比較が集中する可能性があります。長時間終了しないのは、ほとんどのSQLがデッドロック状態にあり、スレッドがSQLの実行終了を待っているためです。
• 対処方法：

  1. まず、デッドロックが発生していないか確認します。

     SELECT * FROM oceanbase.cdb_ob_deadlock_event_history ORDER BY create_time DESC LIMIT 10;
     

  2. 確認後、次の操作を実行します。

     1. Sysbenchに--rand-type=uniformパラメータを追加します。
     2. データセットを増やします。例：tables=100，table_size=1000000；（table_sizeのデフォルトは10000です）。

Sysbenchが異常終了し、エラー1062を報告する場合

• 考えられる原因：1062は主キーまたは一意インデックスの競合です。Sysbenchはランダムにデータを生成するため、主キーの競合が発生する可能性があります。
• 対処方法：Sysbenchにパラメータを追加します：--mysql-ignore-errors=1062

Sysbench異常終了エラー1213

• 考えられる原因：デッドロックが発生し、デッドロックしていたトランザクションの一部がキルされた。
• 対処方法：データセットが非常に大きくても、--rand-type=uniformパラメータを使用していても、デッドロックが発生する可能性があります。そのため、--mysql-ignore-errors=1062,1213パラメータを使用してデッドロックエラーを無視できます。

Sysbench異常終了エラー6002

• 考えられる原因：6002はデッドロックが原因である可能性もありますが、最終的に1213ではなく6002が報告された場合です。
• 対処方法：データセットを増やし、--rand-type=uniformパラメータを追加してロック競合を減らします。Sysbenchパラメータを追加します：--mysql-ignore-errors=1062,1213,6002。

Sysbench異常終了エラー4012

• 考えられる原因：ロック競合が激しいか、デッドロック、または単にOBServerノードのパフォーマンスが低くクライアントの負荷が高すぎてタイムアウトした可能性があります。

• 対処方法：タイムアウト時間（単位：us）を長く設定します：

  set global ob_query_timeout = 50000000000;
  

Sysbench異常終了エラー5930

• 考えられる原因：SQLプリコンパイル機能、つまり--db-ps-mode=autoが有効になっているにもかかわらず、OceanBaseデータベースのプリコンパイルサポートが十分ではないためです。

• 対処方法：

  • テナントパラメータを調整します：alter system set open_cursors=65535;。
  • SQLプリコンパイル機能を無効にしてテストすることもできます：--db-ps-mode=disable;。

Sysbench異常終了およびその他のエラー

• 考えられる原因：OceanBaseデータベースのBUGの可能性があります。
• 対処方法：エラーログを記録し、技術サポートに連絡して調査を依頼してください。

Sysbenchの問題に対する標準的なトラブルシューティングプロセス

問題を迅速に特定できない場合は、完全なチェックプロセスに従って調査してください。このプロセスで理解できない点があれば、後の対応する章やリンク先のドキュメントを参照してください。それでも問題が解決しない場合は、テクニカルサポートに連絡し、調査の支援を依頼してください。

標準的な分析の流れ：

1. ハードウェアリソースを確認します。CPU、メモリ、ディスクリソースが不足していると、パフォーマンスに直接影響し、TPSが0に低下することさえあります。
2. テナント設定を確認します。テナントに割り当てられたリソースが少なすぎると、ハードウェアが十分に活用されません。
3. Sysbenchパラメータを確認します。スレッド数はTPSに直接影響します。データセットが小さすぎるか、データの分布が偏っていると、ロック競合やデッドロックを引き起こす可能性があります。
4. 最後に、OBServerにBUGがないか検討します。

ハードウェアチェック

CPUやメモリなどのハードウェアリソースが不足していると、パフォーマンスは自然と低下します（例：4c8g未満）。ディスクがほぼいっぱいの場合も書き込み速度に影響します。ネットワーク遅延が高すぎる場合も影響があります。

• CPU：lscpu
• メモリ：top、cat /proc/meminfo
• ディスク：df -h
• ネットワーク遅延：ping ip

OceanBaseデプロイメント設定チェック

マシンのハードウェアリソースが十分であるにもかかわらず、OceanBaseデータベースのデプロイ時のパラメータ設定が小さすぎてリソースが十分に活用されていない場合、パフォーマンスが低下することがあります。ほとんどの設定は動的に調整可能ですが、ごく一部はデプロイ時にのみ設定できます。

• SYSテナントに接続し、グローバルビューを確認します。

  SELECT * FROM GV$OB_SERVERS;
  

• ネットワークスレッド数を確認します（この構成パラメータは動的に変更できません）。

  show parameters where name = 'net_thread_count';
  

• デプロイ済みクラスタを確認します。

  obd cluster list
  

• デプロイ済みクラスタの設定を確認します。

  obd cluster edit-config [cluster name]
  

OBServerが稼働しているマシンで、OBServerの起動パラメータを確認します。

ps -ef | grep observer

テナント設定チェック

OBServerノードのリソースに余裕がある場合、テナントのリソースがボトルネックとなっていないかどうかを確認するには、以下のコマンドを使用できます。

• テナントの基本情報を確認します。

  SELECT * FROM oceanbase.dba_ob_tenants;
  

• テナント作成コマンドを確認します。

  show create tenant [tenant name];
  

• テナント対応のリソースプールを確認します（tenant_id を追加してフィルタリング可能）。

  SELECT * FROM oceanbase.dba_ob_resource_pools;
  

• 対応するUnitの設定を確認します。

  SELECT * FROM oceanbase.dba_ob_units;
  

Sysbenchパラメータの確認

SysbenchパラメータはSysbench実行コマンドに含まれており、パラメータ説明と照らし合わせて一つずつ確認できます。

デッドロック問題の特定

• デッドロックレコードを確認します。

  SELECT * FROM oceanbase.cdb_ob_deadlock_event_history ORDER BY create_time DESC LIMIT 10;
  

  ここで role=victim は殺されたトランザクションを表します。

• トランザクション関連SQLを確認します。

  SELECT usec_to_time(REQUEST_TIME), TRACE_ID, TX_ID, QUERY_SQL FROM gv$ob_sql_audit WHERE TX_ID=52635 ORDER BY REQUEST_TIME;
  

  関連するトランザクションが検索されない場合、SQL Audit機能が有効になっていないことを意味します。enable_sql_audit 設定項目がTrueに設定されているか確認できます：

  show parameters where name = 'enable_sql_audit';
  

  クエリ結果がFalseの場合、トランザクション対応のSQLコマンドは表示されません。ログからトランザクションIDをフィルタリングすることで、いくつかの情報を見つけることができる可能性があります。

• SQL対応ログをクエリします。

  トランザクション関連SQLを特定した後、競合したそのSQLのTrace IDを使用して、ログ内を検索します：

  grep '[trace id]' observer.log*
  

  そのSQLのすべてのログが表示されます。通常、最後のログにはクライアントに返されるエラーコードが含まれています：

  sending error packet(err=-4101
  

  最後の commit または begin コマンドのTrace IDを使用して、関連ログを検索することもできます。

  sending error packet(err=-6002
  

  ログが存在しない場合は、ログレベルが間違っているか、ログスロットリングが発生しています。ログレベルを WDIAG に設定し、ログ帯域幅の制限を引き上げる必要があります。

  alter system set syslog_level='WDIAG';
  alter system set syslog_io_bandwidth_limit='2G';
  

  注意

  構成パラメータを変更する前に発生したデッドロック情報は検索できません。

ダンプ・マージ分析

1. 実行時間が5秒を超えるダンプ・マージタスクを確認します。

   SELECT * FROM GV$OB_MERGE_INFO WHERE tenant_id=1002 AND (END_TIME-START_TIME)>5 LIMIT 10;
   

2. 特定のテーブルのマージレコードを確認します。

   SELECT * FROM GV$OB_TABLET_COMPACTION_HISTORY WHERE TABLET_ID IN (SELECT TABLET_ID FROM oceanbase.CDB_OB_TABLE_LOCATIONS WHERE TABLE_NAME = 'sbtest1') ORDER BY START_TIME DESC;
   

3. ダンプを手動でトリガーします。

   alter system minor freeze tenant=xxx;
   

OBServerノードでtop -Hを実行して、MINI_MERGEおよびMINOR_EXEスレッドのオーバーヘッドを観察することもできますが、持続時間は比較的短くなります。

スローSQLクエリ

1. 実行時間が5秒を超えるスローSQLを照会し、すべての情報を出力します。

   SELECT * FROM gv$ob_sql_audit WHERE elapsed_time > 5000000 LIMIT 10;
   

2. キーメッセージをカスタム出力します。

   SELECT SVR_IP, SVR_PORT, SQL_EXEC_ID, TRACE_ID, TENANT_ID, SQL_ID, QUERY_SQL, PLAN_ID, PARTITION_CNT, IS_INNER_SQL, ELAPSED_TIME, EXECUTE_TIME, APPLICATION_WAIT_TIME FROM gv$ob_sql_audit WHERE elapsed_time > 5000000 ORDER BY elapsed_time DESC LIMIT 10;
   

   データが見つからない場合は、SQL Audit機能が有効になっていない可能性があります。

   show parameters where name = 'enable_sql_audit';
   alter system set enable_sql_audit = true;
   

ログ問題のトラブルシューティング

ディスク容量使用状況を確認します。

SELECT tenant_id, svr_ip, svr_port, LOG_DISK_IN_USE, LOG_DISK_SIZE FROM gv$ob_units;

問題再現プロセス

1. まず、以前の sql_audit レコードをクリアできます。

   alter system set enable_sql_audit = false;
   alter system flush sql audit global;
   

2. sql_audit レコードを有効にします。

   alter system set enable_sql_audit = true;
   

3. ログレベルを変更します。

   alter system set syslog_level='WDIAG';
   

4. SQLレコードのしきい値を引き下げて、可能な限り多くのSQLを記録します。

   alter system set trace_log_slow_query_watermark = '10ms';
   

5. システムログの帯域幅制限を引き上げて、レート制限による重要なログの欠落を防ぎます。

   alter system set syslog_io_bandwidth_limit='2G';
   

6. トランザクションのタイムアウトを防ぐには、タイムアウト時間を引き延ばすこともできます。

   set global ob_query_timeout = 50000000000;
   

その後、問題シナリオと同じパラメータを設定して、Sysbenchの実行を開始します。

Sysbenchのパフォーマンス問題事例分析

SysbenchのTPSが0に低下し、時折エラーが発生する問題を例に分析および対処方法を説明します。

問題の現象

OceanBaseデータベースCommunity Edition V4.1.0を使用し、以下のコマンドでSysbenchテストを実行すると、TPSが0に低下し、エラーが発生します。

sysbench --db-driver=mysql --threads=500 --time=300000 --mysql-host=xxxxxxx --mysql-port=2883 --mysql-user='tpcc@t1' --mysql-password='******' --report-interval=2 --tables=100 /usr/share/sysbench/oltp_read_write.lua --db-ps-mode=disable run

マシン構成：

問題の原因と分析

初期判断では、table_sizeが小さすぎ、データ分布がデフォルトでspecialモードになっているため、データが集中し、主キーの競合が激しくなり、最終的にデッドロックが発生し、TPSが0に低下したものと考えられます。

1. まず、テナントのタイムアウト時間を引き延ばしてテストします。

   set global ob_query_timeout = 50000000000;
   set global ob_trx_timeout = 50000000000;
   

2. 早期に再現するため、Tablesを1に設定し、他のパラメータは変更しません。

    sysbench oltp_read_write.lua --mysql-host=[ip] --mysql-port=2881 --mysql-user=root@user --mysql-db=test --table_size=10000 --tables=1 --threads=500 --time=3600 --report-interval=1 --db-ps-mode=disable run
   

3. 発生する現象：TPSが0に落ち込みますが、時折TPSとQPSが0を上回ることがあります。

4. デッドロックビューを確認します。

   SELECT * FROM oceanbase.CDB_OB_DEADLOCK_EVENT_HISTORY ORDER BY create_time DESC LIMIT 10;
   

   最近のデッドロックレコードが確認できます。role=victimは殺されたトランザクションを表し、role=witnessは競合を証明したトランザクションを表します。cycle_size=2は2つのトランザクションのみが互いに競合していることを示し、cycle_size>2は複数のトランザクションが1つのトランザクションと競合していることを示します。ここでは観察しやすいようにcycle_size=2のイベントを選択し、event_idで一連の競合するトランザクションをフィルタリングできます。

   SELECT * FROM oceanbase.CDB_OB_DEADLOCK_EVENT_HISTORY WHERE cycle_size=2 ORDER BY create_time DESC LIMIT 10;
   

   VisitorフィールドにはトランザクションIDが表示されており、そのトランザクションIDから該当トランザクションに関連するすべてのSQLコマンドを見つけることができます。

   SELECT TRACE_ID, TX_ID, QUERY_SQL FROM gv$ob_sql_audit WHERE TX_ID=5042912 ORDER BY REQUEST_TIME;
   SELECT TRACE_ID, TX_ID, QUERY_SQL FROM gv$ob_sql_audit WHERE TX_ID=5042591 ORDER BY REQUEST_TIME;
   

   図から、2つのトランザクションが相互依存している状況が確認できます。すなわち：

   • トランザクション1はid=4978を更新します。
   • トランザクション2はid=5049を更新します。
   • トランザクション1はid=4978を更新します。
   • トランザクション2はid=5049を削除します。

   デッドロックが発生した後、トランザクション64317はロールバックされ、トランザクション64235は正常にコミットされます。トランザクション64317の作成時刻が後であるため、sql_auditを確認し、トランザクションの最初のSQLを見つけて、そのSQLのrequest_timeで判断します。

   SELECT REQUEST_TIME, SVR_IP, SVR_PORT, SQL_EXEC_ID, TRACE_ID, TENANT_ID, TX_ID, SQL_ID, QUERY_SQL, PLAN_ID, PARTITION_CNT, IS_INNER_SQL, ELAPSED_TIME, EXECUTE_TIME, APPLICATION_WAIT_TIME FROM gv$ob_sql_audit WHERE TX_ID=64317 ORDER BY REQUEST_TIME;
   

   トレースIDに基づいてログを確認すると、ロールバックされたトランザクションが見え、エラーコードは6002（ロールバック）、Abortの原因は4101（デッドロック）です。

   終了したトランザクションが競合したそのSQLログを検索すると、最後のログが4101エラーコードを返していることがわかります。しかし、最終的にSysbench側ではデッドロックエラーではなく、6002ロールバックエラーが報告されました。

   [2023-07-11 15:32:40.263794] INFO  [SERVER] send_error_packet (obmp_packet_sender.cpp:317) [28473][T1002_L0_G0][T1002][Y5B690B7C0505-00060030956354CB-0-0] [lt=14] sending error packet(err=-4101, extra_err_info=NULL, lbt()="0x1029cb40 0x832fadc 0x82e32f7 0x5b65d4f 0x5960718 0x595c58f 0x595a25a 0x8075f6c 0x595964c 0x80754ea 0x595665a 0x8075b24 0x1061b777 0x10613e9f 0x7f0215489e25 0x7f0214f48f1d")
   

   トランザクションの最後の「BEGIN」コマンドに対応するログを検索すると（トランザクションがcommitコマンドを明示的に実行しないため、次のトランザクションのbeginコマンドが現在のトランザクションを暗黙的にコミットさせるため、beginが現在のトランザクションの最後のSQLとなる）、6002ロールバックエラーが返されていることがわかります。これにより、Sysbenchがデッドロックが発生したSQLを処理せず、6002エラーを報告したことが判明しました。

   [2023-07-11 15:32:40.305922] INFO  [SERVER] send_error_packet (obmp_packet_sender.cpp:317) [28472][T1002_L0_G0][T1002][Y5B690B7C0505-0006003095136574-0-0] [lt=37] sending error packet(err=-6002, extra_err_info=NULL, lbt()="0x1029cb40 0x832fadc 0x82e32f7 0x5a55e57 0x5960c40 0x595c58f 0x595a25a 0x8075f6c 0x595964c 0x80754ea 0x595665a 0x8075b24 0x1061b777 0x10613e9f 0x7f0215489e25 0x7f0214f48f1d")
   

   ログが検索されない場合、ログのスロットリングが原因である可能性があります。システムログ帯域幅の制限を引き上げることを推奨します：

   alter system set syslog_io_bandwidth_limit='2G';
   

解決策

上記の問題原因の分析に基づき、以下の結論を得ることができます：

• デフォルトのrand-type=specialシナリオでは、Key競合が多すぎるためデッドロックが発生する可能性があり、このシナリオではSysbenchの負荷テストは終了します。
• デフォルトのrand-type=specialシナリオで、tablesとtable_sizeも比較的小さい場合、デッドロックはより頻繁に発生し、多数のトランザクションが停止し、テストスレッドがタイムリーに終了できないため、数分間TPSが0に落ち込む状況が発生します。時折、TPSが0より高くなることもあります。
• デッドロックが発生したトランザクションはロールバックエラーを報告し、エラーコードは6002（1213ではない）である可能性があります。
• ob_query_timeoutの設定が長く、たまたまデッドロック検出機能が有効でない場合、トランザクションは終了できず、SQLはブロックされ続けます。この場合、TPSは長期間0のままで、エラーは報告されません。

これにより、SysbenchのTPSが0に低下し、時折エラーが報告される問題を解決する方法は以下の通りです：

1. まず、データ分布タイプを調整し、--rand-type=uniformを設定することを検討します。
2. データ分布タイプの調整を検討しない場合、データセットを拡大することを推奨します。例：tables=100，table_size=1000000
3. データのランダムタイプとデータセットの調整をどちらも検討しない場合、エラーコードを無視することを試みることができますが、これではデッドロックを回避できません。--mysql-ignore-errors=1062,1213,6002