1.OBServer 租户工作线程的线程名字是什么？
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 进行有效地控制和限制，但这需要操作系统级别的配置搭配生效。
4.如何读取 OceanBase 数据库 Worker 线程的数量？OceanBase 数据库是否会在负载高的时候动态启动新的线程来执行负载？
在 observer.log 中， 以关键字 dump tenant info 为主的日志片段里会描述现在 Worker 线程的现有值以及最大值。具体如下：
token_count = 分配给该租户的 cpu_count (>min_cpu&&<max_cpu) *cpu_quota_concurrency
OBServer 会在负载高的时候动态分配新的线程来执行负载。例如在一个特定的场景中， 一台装有 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 是个活跃线程，它因为执行大查询被挂起，这时活跃线程就少了一个，作为补充，这个租户会额外再创建一个活跃线程。但是一个租户能创建的线程总数也是有限制的，总数限制为 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 Hang 住的情况？
当发现 OBServer 的 CPU 负载偏高已经达到了 80%- 90% 甚至以上，该台 OBServer 已经发生了整体性能不佳甚至是 Hang 住的情况，那么可以通过 OBStack 工具（V2.2.3x 高配版本、V2.2.7x 以及 V3.x 版本均可独立安装）获取 OBStack 工具。可以执行以下命令直接执行 obstack 获取线程栈定向到问题 obstack.trc 中。
[root@hostname /]#obstack -p ${pid of observer} > obstack.trc