首批通过分布式安全可靠测评，为关键业务系统打造
划线反馈
observer.log 中 dump tenant 介绍
更新时间：2024-01-22 01:56
分享
适用版本：V2.1.x、V2.2.x、V3.1.x、V3.2.x内容类型：TechNote
本文介绍通过 observer.log 中 dump tenant 查看租户层资源信息的方法。
通过查看 observer.log 中 dump tenant 可以查看租户层资源信息，方法如下。
[admin@hostname ~]$ cd /home/admin/oceanbase/log
[admin@hostname log]$ grep 'dump tenant.*tenant={id:1002' observer.log| sed "s/,/\n/g"
示例输出
[2020-12-16 15:29:24.640442] INFO [SERVER.OMT] ob_multi_tenant.cpp:806 [31771][3104][Y0-0000000000000000] [lt=24] [dc=0] dump tenant info(tenant={id:1002
compat_mode:0
unit_min_cpu:"3.000000000000000000e+00"
unit_max_cpu:"3.000000000000000000e+00"
slice:"0.000000000000000000e+00"
slice_remain:"0.000000000000000000e+00"
token_cnt:12
ass_token_cnt:12
lq_tokens:3
used_lq_tokens:0
stopped:false
idle_us:1709164
recv_hp_rpc_cnt:2
recv_np_rpc_cnt:2
recv_lp_rpc_cnt:0
recv_mysql_cnt:314
recv_task_cnt:11
recv_large_req_cnt:0
tt_large_quries:12
actives:12
workers:12
nesting workers:7
lq waiting workers:0
req_queue:total_size=0 queue[0]=0 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=0 queue[5]=0
large queued:0
multi_level_queue:total_size=0 queue[0]=0 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=0 queue[5]=0 queue[6]=0 queue[7]=0
recv_level_rpc_cnt:cnt[0]=0 cnt[1]=0 cnt[2]=0 cnt[3]=0 cnt[4]=0 cnt[5]=0 cnt[6]=0 cnt[7]=0 })
字段含义
各项字段含义如下所示。
| 字段 | 含义 |
|---|---|
| id | 租户 ID。 |
| unit_min_cpu | 保证为租户提供的最小 CPU 核数。 |
| unit_max_cpu | 限制租户最大 CPU 核数上限。 |
| slice | 无意义。 |
| slice_remain | 无意义。 |
| token_cnt | 调度器分配的 token 数，一个 token 会转换为一个工作线程。 |
| ass_token_cnt | 租户当前确认的 token 数（根据 token_cnt 确定，一般两者相等）。 |
| lq_tokens | Large Query token 个数，根据 token_cnt 乘以大请求比例设置。 |
| used_lq_tokens | 当前持有 LQ Token 的 Worker 数。 |
| stopped | 租户 unit 是否正在删除。 |
| idle_us | 一轮日志 dump（10 秒）中工作线程空闲的总时间和。 只统计等待队列的时间。 |
| recv_hp_rpc_cntrecv_np_rpc_cntrecv_lp_rpc_cnt | 租户累计收到不同级别的 rpc 请求数，其中 hp 表示 Highnp， Normallp 表示 Low。 |
| recv_mysql_cnt | 租户累计收到的 MySQL 请求数。 |
| recv_task_cnt | 租户累计收到的内部任务数。 |
| recv_large_req_cnt | 租户累计预判的大请求数，只会递增，不会清零。实际是重试的时候递增的。 |
| tt_large_quries | 租户累计处理的大请求数, 只会递增，不会清零。实际是打点 check 的时候递增的。 |
| actives | 活跃工作线程数，一般和 workers 相等。 actives 与 workers 的差表示租户工作线程缓存带工作线程的大请求缓存。 |
| workers | 租户持有的工作线程数，实际就是 workers 列表的大小。 |
| lq waiting workers | 处于等待调度的工作线程。 |
| req_queue | 不同优先级的工作队列，数字越小优先级越高。 |
| large queued | 当前预判出的大请求个数。 |
其中，需要关注以下字段：
一般来说一个租户的
token_cnt、ass_token_cnt、actives和workers四个值都应该相等。检查
req_queue字段 total_size 大于10000 的日志（表示业务租户）看是否堆积。检查线程库存（trending）：
库存线程是指一个 observer 进程允许分配给所有租户的线程数，减掉已经分配给所有租户的线程总量。
observer 进程允许分配的线程总数：可通过
cpu_count * workers_per_cput_quota计算。已经分配给所有租户的线程总量：用各个租户的
actives的和来计算，注意需要排除掉虚拟租户。
有关大查询的字段：
tt_large_quries字段表示 10s 内处理了多少个大查询 。lq waiting workers字段表示有多少个线程因为大查询被挂起。
此外，对于请求队列，可以通过 v$sql_audit 视图查询排队时间。
obclient> SELECT round(request_time/100000), count(*) FROM v$sql_audit WHERE tenant_id = 1039 GROUP BY 1;
