18. ClustrixDB 管理CPU资源

作为一个分布式MPP数据库，ClustrixDB能够利用多个节点和核心来比单节点数据库更快地处理查询。有两个可调进程可以促进这一点。

Clustrix选择了一组默认参数来控制那些提供最常见工作负载的进程。根据您的特定工作负载、集群规范和应用程序的延迟需求，您可能希望调优其中一些变量。

Fair Scheduler

ClustrixDB公平调度器可以确保长时间运行的查询不独占CPU资源。它通过优先查询返回少行之前的查询返回的行数更大。这有助于平衡工作负载在节点和集群尤其有用,混合长期在线分析处理(OLAP)和短期的联机事务处理(OLTP)。公平调度器将优先考虑任何查询读取100(默认)或更少的行之前,任何正在运行的查询处理超过100行。全局变量gtm_schedule_til_batch_rows用于控制阈值的行。

如果没有公平调度程序，长时间运行的查询可能会占用CPU资源，并为较小的查询带来不必要的延迟。例如，如果一个较短的查询被分配给一个已经在执行长时间运行的查询的cpu核心，那么这个较短的查询将会经历意外的延迟。公平调度程序通过平衡长时间运行和短时间运行的查询之间的资源来解决这个问题。与长时间运行的查询相比，短时间运行的查询具有更高的查询延迟。

全局变量

以下全局变量控制公平调度程序。这些变量在会话中不可用。

Name	Description	Default Value
gtm_schedule_til	是否开启fair scheduler	true
gtm_schedule_til_batch_rows	在重新调度之前要处理的行。	100

检查fair scheduler程序的影响

当查询正在运行时，您可以看到系统中fair scheduler程序的影响。在查询完成后，query.log将包含关于CPU等待的统计信息。

query.log

log中的cpu_wait和cpu_waittime_ns统计信息显示查询何时在等待CPU资源，这可能是由于公平调度程序取消了优先级。一旦查询完成，就会被记录到query.log中。

例如，您可以看到公平调度程序对这个查询进行了45,752次反优先级处理，总共花费了21,975,562,278纳秒(21秒)。

2017-03-01 16:49:01.530435 UTC ip-10-10-10-101 clxnode: INSTR SLOW SID:297145363 db=production user=production@10.10.10.254  
ac=Y xid=58c4dbf59b223826 sql="UPDATE event_activities SET is_processed = true where batch_id = '1488386700'" [Ok: 91275 rows updated] 
time 9303.1ms; reads: 91276; inserts: 0; deletes: 0; updates: 182550; counts: 91275; rows_read: 182550; forwards: 365101; broadcasts: 0;
rows_output: 2; semaphore_matches: 0; fragment_executions: 365102; runtime_ns: 22744490156; cpu_waits: 45752; cpu_waittime_ns: 21975562278;
bm_fixes: 592280; bm_loads: 0; bm_waittime_ns: 0; lockman_waits: 1; lockman_waittime_ms: 6844; trxstate_waits: 0; trxstate_waittime_ms: 0;
wal_perm_waittime_ms: 0; bm_perm_waittime_ms: 0; sigmas: 0; sigma_fallbacks: 0; row_count: 91275; found_rows: -1; insert_id: 0; fanout: no;
attempts: 1

system.transactions

这个system.transactions表显示了同一查询在运行时的信息:

sql> select xid, cpu, cpu_waits, cpu_waittime_ns from transactions where xid = ;

+---------------------+------+-----------+-----------------+

| xid                 | cpu  | cpu_waits | cpu_waittime_ns |

+---------------------+------+-----------+-----------------+

|  |     |          |                |

|  |     |      |      |

|  |     |          |                |

|  |     |          |                |

|  |     |          |                |

|  |     |          |                |

|  |     |          |                |

|  |     |          |                |

+---------------------+------+-----------+-----------------+

 rows in set (0.00 sec)

Fanout

Fanout是在每个节点的多个cpu上同时运行查询片段的过程。这允许扩展并行性，并缩短ALTER TABLE和大型OLAP查询的执行时间。

ClustrixDB能够使用多个cpu进行查询处理和ALTER TABLE之类的操作,这个过程叫做 Fanout。

当ClustrixDB执行一个查询时，它被分割成片段以供执行。然后将这些片段传递给各个cpu执行。根据查询类型和复杂性，每个片段可以有多个执行阶段。

Fanout是在每个节点的多个cpu上同时运行查询片段的过程。这允许扩展并行性，并缩短ALTER TABLE和大型OLAP查询的执行时间。

有关查询执行和碎片的详细信息可以在ClustrixDB评估模型的文档中找到。

控制Fanout的变量

Fanout由以下变量控制和配置。默认值适用于大多数工作负载。

Name	Description	Default Value
Fanout Variables
query_fanout	Enables query fanout. This takes precedence over all other fanout variables.	True
query_fanout_insert_select	If enabled, INSERT INTO ... SELECT FROM ... queries will use Fanout. This takes precedence over query_fanout_all_writes.	True
query_fanout_all_writes	Enable fanout for INSERT, UPDATE, and DELETE queries. Order of writes is not guaranteed.	False
query_fanout_min_rows	Only queries expected to read more than this many rows will fan out.	5000
Related Variables
gtm_schedule_til	Enable the Completely Fair Scheduler.	True
sigma_skiplist	Enable skiplist containers for aggregates and sorting.	False

禁用Fanout

这将完全禁用Fanout，每个查询只使用一个CPU。这将影响性能，只有在Clustrix支持建议的情况下才应该更改此设置。

sql> SET query_fanout = FALSE;

表切片的最佳Fanout准则

要使用Fanout提供完全的并行性，请确保查询的表示具有足够的片。预期将从扇出中受益的大型表应该被分割到集群许可的CPU内核总数中。Under-slicing减少并行性。例如，如果一个节点上有三个表示片段，那么Fanout最多只能在该节点的三个cpu上运行三个查询片段。

Fanout警告

临时表不提供Fanout。临时表只包含一个片，并且只驻留在一个节点上。