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またはNVMに交換してテストを実行できます）。

   ネットワーク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タイプではキーの比較が集中します。長時間終了しないのは、ほとんどの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やメモリなどのハードウェアリソースが不足している場合（例：CPU 4コア、メモリ 8GB未満）、パフォーマンスは自然と低下します。ディスクがほぼいっぱいになると書き込み速度にも影響しますし、ネットワーク遅延が高すぎるのも問題です。

• 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監査機能が有効になっていない可能性があります：

   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のイベントを1つ選択します。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;
   

   trace 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 シナリオでは、キー競合が多すぎるためデッドロックが発生し、このシナリオでは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