ロードバランシングは、パフォーマンスチューニングの過程でよく注目される情報であり、クラスタ内の物理マシンのロードバランシングと業務トラフィックのロードバランシングの2つの側面が含まれます。良好なロードバランシング状態は、ソフトウェアおよびハードウェア環境を十分に活用し、パフォーマンスを最適な状態にすることができます。ストレステストの過程では、クラスタ内部の各OBServerのリソース使用率、すなわちCPU、I/O、Loadなどのパラメータに注意を払う必要があります。本記事では主に、クラスタのデプロイメントやリソースの分布などの観点から簡潔に説明します。
クラスタのデプロイ
クラスタのデプロイについては、場所、遅延、帯域幅などの情報を収集する必要があります。
場所
場所情報は非常に重要です。一部の重要な情報、例えば：IDC、デプロイ方式はSQLルーティング転送、トランザクションモデル、パフォーマンスに影響します。以下の点が含まれます：
デプロイ方式：同一都市内の3リージョン、2リージョン3センター、3リージョン5センター、またはその他のデプロイ方式。
OBProxyなどのミドルウェアの場所：クライアント側にデプロイするか、Observerとハイブリッドで配置するか？異なるデプロイ方式は、パフォーマンスに一定の影響を与えます。
アプリケーションサーバーおよびその他のミドルウェアの場所。
クラスタの各ゾーンがどのリージョンに属し、リージョンがどの都市にあるか、またIDC構成に関するSQL文は以下のとおりです：
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_ZONES;
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| ZONE | CREATE_TIME | MODIFY_TIME | STATUS | IDC | REGION | TYPE |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| zone1 | 2024-07-10 14:19:05.573991 | 2024-07-10 14:19:05.573991 | ACTIVE | | default_region | ReadWrite |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
1 row in set
遅延
遅延情報を通じて、単一のSQLのRTが予想どおりかどうかを評価できます。クラスタ全体の具体的な遅延情報は以下のとおりです：
リージョン間の遅延；
ゾーン間の遅延；
OBProxyからOBServerへの遅延；
クライアントからOBProxyへの遅延。
帯域幅
以下のコンポーネントの帯域幅を確認する必要があります：
OBProxyが配置されるマシンのNIC帯域幅。
アプリケーションサーバーのNIC帯域幅。
OBServerのNICおよびディスクI/O帯域幅。
これらの情報は、ping、tsar、ethtool xxx、ifconfigなどのコマンドを実行して取得できます。以下の説明では、同一都市内の3リージョン、3レプリカFFFデプロイを例に説明します。
リソースの分布
テナントのリソース分布を理解し、今後のパフォーマンス診断に備えます。
テナントの基本情報
primary、localityなどを含みます。関連するSQLは以下のとおりです：
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANTS LIMIT 1\G
*************************** 1. row ***************************
TENANT_ID: 1
TENANT_NAME: sys
TENANT_TYPE: SYS
CREATE_TIME: 2024-07-10 14:19:05.397680
MODIFY_TIME: 2024-07-10 14:19:05.397680
PRIMARY_ZONE: RANDOM
LOCALITY: FULL{1}@zone1
PREVIOUS_LOCALITY: NULL
COMPATIBILITY_MODE: MYSQL
STATUS: NORMAL
IN_RECYCLEBIN: NO
LOCKED: NO
TENANT_ROLE: PRIMARY
SWITCHOVER_STATUS: NORMAL
SWITCHOVER_EPOCH: 0
SYNC_SCN: NULL
REPLAYABLE_SCN: NULL
READABLE_SCN: NULL
RECOVERY_UNTIL_SCN: NULL
LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
UNIT_NUM: 1
COMPATIBLE: 4.3.2.0
MAX_LS_ID: 1
RESTORE_DATA_MODE: NULL
1 row in set
リソース割り当て情報
関連するSQLは以下のとおりです：
obclient [oceanbase]> SELECT * FROM oceanbase.gv$ob_units LIMIT 1\G
*************************** 1. row ***************************
SVR_IP: 172.xx.xx.xx
SVR_PORT: 2882
UNIT_ID: 1
TENANT_ID: 1
ZONE: zone1
ZONE_TYPE: ReadWrite
REGION: default_region
MAX_CPU: 4
MIN_CPU: 4
MEMORY_SIZE: 5368709120
MAX_IOPS: 9223372036854775807
MIN_IOPS: 9223372036854775807
IOPS_WEIGHT: 4
LOG_DISK_SIZE: 17448304640
LOG_DISK_IN_USE: 2311121885
DATA_DISK_IN_USE: 88608768
STATUS: NORMAL
CREATE_TIME: 2024-07-10 14:18:25.157169
1 row in set
スタンドアロンユーザーのパーティション総数とリーダーの分布
obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1002 GROUP BY svr_ip;
+---------------+----------+
| svr_ip | count(1) |
+---------------+----------+
| 10.10.10.1 | 1 |
| 10.10.10.2 | 1 |
| 10.10.10.3 | 1 |
+---------------+----------+
3 rows in set
obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1001 and role=1 GROUP BY svr_ip;
+---------------+----------+
| svr_ip | count(1) |
+---------------+----------+
| 10.10.10.1 | 5 |
+---------------+----------+
1 row in set
その他
アプリケーションサーバーからOBServerへのリクエストが送信されるまでの間に経由するすべてのコンポーネントは、私たちが注目すべき重点です。いずれかの部分がボトルネックとなると、パフォーマンスに大きな影響を与える可能性があります。以下の点に注意が必要です：
物理リソース：中間リンクの各コンポーネントのリソースがボトルネックに達していないかどうか。例えば、JVMメモリ、アプリケーションサーバーおよびOBProxyのCPU使用率、ソフトウェア割り込みなどです。
リクエストルーティング：OBProxyがSQLリクエストを正しくルーティングできているかどうか、また無秩序な転送が発生していないかどうか。
接続プール：長時間接続と短時間接続の数、SocketTimeout設定。
フロー均衡：各OBServer上で処理されるSQL数に深刻な不均衡が生じていないかどうか。