1.OceanBaseデータベースのテナントワーカースレッドのスレッド名は何ですか？
OceanBaseデータベースはマルチテナントをサポートしており、各テナントには一意のIDが割り当てられます。このテナントIDはテナント作成時に割り当てられます。各テナントのワーカースレッドは独立しており、IDが1001のテナントのワーカースレッド名はTNT_L0_1001となります。ここで、各部分の意味は以下の通りです：
TNT：テナントスレッドを示します。
L0：ネストレベルが0のリクエストを処理するスレッドを示します。
1001：テナントIDを示します。
他のテナントも同様の形式で表されます。
2.OceanBaseデータベースはどのようにワーカースレッドの数を割り当てるのですか？
OceanBaseデータベースは起動後、必要なスレッドをすべて作成します。その後、関連するパラメータやテナント仕様を調整しない限り、スレッド数は基本的に変更されません。特定のobserver上でのテナントのワーカースレッド数は、そのテナントのUnit仕様によって決定されます。
3.OceanBaseデータベースのマルチテナントアーキテクチャでは、CPUリソースの効果的な分離はどのように実現されていますか？
OceanBaseデータベースの現在リリースされているバージョンでは、CPU消費量は主にアクティブスレッド数（実際にCPUリソースを消費するスレッド）の制御によって管理されています。OceanBaseデータベースはテナント作成時にテナントリソースプールを指定し、リソースプールで定義されたCPU仕様によってテナントレベルでのCPU使用を制限することで、テナント間のCPU使用の分離を実現しています。OceanBaseデータベースの最新バージョンでは、カーネルにおいてcgroupのサポートが追加され、CPUの効果的な制御と制限が可能になりました。ただし、これはOSレベルでの設定と連携して有効になります。
4.OceanBaseデータベースのWorkerスレッド数はどのように読み取るのですか？OceanBaseデータベースは負荷が高い場合、動的に新しいスレッドを起動して負荷を処理しますか？
observer.logファイル内で、キーワードdump tenant infoを含むログセグメントには、現在のWorkerスレッドの値とその上限値が記述されています。具体的には以下のようになります：
token_count = テナントに割り当てられた cpu_count (>min_cpu&&<max_cpu) *cpu_quota_concurrency
OceanBaseデータベースは負荷が高い場合、動的に新しいスレッドを割り当てて負荷を処理します。例えば、あるシナリオにおいて、OceanBaseデータベースが稼働しているマシン上のテナントT1がunit_min_cpu = 2、unit_max_cpu=8で構成されているにもかかわらず、そのマシンのCPUリソースにオーバーコミットが設定されている場合を考えます。T1に実際に割り当てられるCPU数が5個であれば、token_count = 5*cpu_quota_concurrencyとなります。
5.OceanBaseデータベースは、テナントのアクティブスレッド数とスレッド総数をどのように制御していますか？
OceanBaseデータベースは、テナントのcpu_count * cpu_quota_concurrencyに基づいてアクティブスレッド数を計算し、これらのスレッドはテナント作成時に一度に作成されます。例えば、スレッドAがアクティブスレッドであるとき、大規模なクエリの実行によりスレッドが一時停止した場合、アクティブスレッド数は1つ減少します。補完として、そのテナントは追加のアクティブスレッドを1つ作成します。ただし、テナントが作成できるスレッドの総数には上限があり、その総数はcpu_count* workers_per_cpu_quotaに制限されます。テナントのスレッド数が上限に達すると、新しいスレッドの作成は失敗し、スレッドAは一時停止せず、アクティブスレッド数は常に一定に保たれます。例えば、あるテナントが16個のCPUを割り当てられ、クラスタのcpu_quota_concurrencyが2に設定されている場合、そのテナントが持つアクティブなSQLスレッドの最大数は16 * 2 = 32個となります。アクティブスレッド数の制御は、OceanBaseデータベースのユーザー空間スレッドスケジューラーによって実装されています。
6. 大規模クエリのCPUリソース割り当てポリシーとは何ですか？OLAPとOLTPが同時に存在する場合、CPUリソースの競合が発生することはありますか？
OceanBaseデータベースでは、パラメータlarge_query_thresholdを設定することで、実行時間が一定のしきい値を超えるクエリ操作を大規模クエリと定義できます。システム内で大規模クエリと小規模クエリが同時に実行されている場合、OceanBaseデータベースは一部のCPUリソースを大規模クエリに割り当てます。また、パラメータlarge_query_worker_percentage（デフォルト値は30%）を設定することで、大規模クエリが使用できるテナントのアクティブワーカースレッド数を制限します。OceanBaseデータベースは、大規模クエリが使用できるテナントのアクティブワーカースレッド数を制限することで、大規模クエリが使用できるCPUリソースを最大限に抑え、システムがOLTP（例：取引型の小規模トランザクション）負荷を実行するための十分なCPUリソースを確保します。このようにして、応答時間に敏感なOLTP負荷が十分なCPUリソースを確保し、迅速に実行されることを保証します。なお、OceanBaseデータベースは大規模クエリとOLTPのリソース割り当てを実現できますが、large_query_thresholdパラメータも合理的な範囲に設定する必要があり、過大な値に設定すべきではありません。そうでない場合、大規模クエリがシステムのCPUリソースを奪い合い、OLTPの応答が遅くなったり、キューが積み上がったりする問題を引き起こす可能性があります。
7. OBServerノードでCPU使用率が高すぎる、またはOBServerノードがフリーズする場合の分析方法は何ですか？
OBServerノードのCPU負荷が80%～90%以上に達し、全体的なパフォーマンスが低下したり、フリーズしたりしている場合は、OBStackツール（V2.2.3x ハイエンド版、V2.2.7x、およびV3.xバージョンは独立してインストール可能）を取得します。以下のコマンドを実行して、obstackを直接実行し、スレッドスタックを問題のobstack.trcに転送します。
[root@hostname /]#obstack -p ${pid of observer} > obstack.trc