1.OceanBaseデータベースのテナントワーカースレッドのスレッド名は何ですか？
OceanBaseデータベースはマルチテナントをサポートしており、各テナントには一意のIDが割り当てられています。テナントIDはテナント作成時に割り当てられます。各テナントのワーカースレッドは独立しており、IDが1001のテナントのワーカースレッド名はTNT_L0_1001となります。その内訳は以下の通りです：
TNT：テナントスレッドを表します。
L0：ネストレベルが0のリクエストを処理するスレッドを表します。
1001：テナントID。
他のテナントも同様です。
2.OceanBaseデータベースはどのようにワーカースレッド数を割り当てるのでしょうか？
OceanBaseデータベースは起動後に必要なスレッドを作成し、その後関連する構成パラメータやテナント仕様を調整しない限り、スレッド数は基本的に変更されません。特定のobserver上でのテナントのワーカースレッド数は、テナントのUnit仕様によって決定されます。
3.OceanBaseデータベースのマルチテナントアーキテクチャでは、CPUリソースの効果的な分離はどのように実現されているのでしょうか？
OceanBaseデータベースの現在公開されているバージョンでは、OceanBaseデータベースは主にアクティブなスレッド数（実際にCPUリソースを消費するスレッド）を制御することでCPU消費を管理しています。OceanBaseデータベースはテナント作成時にテナントリソースプールを指定し、リソースプールで定義されたCPU仕様によってテナントレベルのCPU使用を制限することで、テナント間のCPU使用の分離を実現しています。OceanBaseデータベースの最新バージョンでは、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に設定されている場合、このテナントは最大で16 * 2 = 32個のアクティブなSQLスレッドを持つことができます。アクティブスレッド数の制御は、OceanBaseデータベースのユーザーモードスレッドスケジューラーによって実現されています。
6. 大規模クエリのCPUリソース割り当て原則とは何ですか？OLAPとOLTPが同時に存在する場合、CPUリソースの競合が発生する可能性はありますか？
OceanBaseデータベースを使用する際、パラメータlarge_query_thresholdを設定することで、実行時間が一定のしきい値を超えるクエリ操作を大規模クエリとして定義できます。システム内で大規模クエリと小規模クエリが同時に実行されている場合、OceanBaseデータベースは一部のCPUリソースを大規模クエリに割り当て、パラメータlarge_query_worker_percentage(デフォルト値は30%)を設定することで、大規模クエリが使用できる最大テナントアクティブワーカースレッド数を制限します。OceanBaseデータベースは、大規模クエリが使用できるテナントアクティブワーカースレッド数を制限することで、大規模クエリが使用できる最大CPUリソースを制約し、システムに十分なCPUリソースが残り、OLTP(例えば、取引型の小規模トランザクション)負荷を実行できるようにします。このようにして、応答時間に敏感な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を直接実行し、スレッドスタックを問題のobstack.trcにダイレクトします。
[root@hostname /]#obstack -p ${pid of observer} > obstack.trc