Vertica资源池

vertica资源管理请参考之前的博文：vertica资源管理

vertica任务的执行过程：

• 在初始节点创建全局执行计划，如果资源需求超过可用资源，就拒绝
• 向执行节点分配全局执行计划
• 在执行节点创建本地执行计划，判断需要的资源
• 执行节点判断资源是否足够，然后执行查询或者查询排队（可能会因等待超时被拒绝）
• 执行节点启动执行引擎，管理运行时资源
• 处理结果并发送到初始节点聚合

vertica使用资源池进行以下工作：

• 资源分配和调度
• 并发控制
• 动态资源管理

资源池参数

参数	默认值	描述
executionparallelism	AUTO	每个任务执行并行度（线程数），缺省为CPU核数
cpuaffinityset	none	运行的CPU核集合，缺省为所有CPU
cpuaffinitymode	ANY	cpu粘连模式，缺省为ANY
memorysize	0%	保留的专用内存，为0表示可以从GENERAL借的内存大小没有限制
maxmemorysize	NONE	允许从general使用的最大内存，缺省不限制
plannedconcurrency	AUTO	默认为核心数量
priority	0	任务排队优先级，取值-100到100
queuetimeout	300	任务排队超时，会被拒绝。NONE表示永不超时
runtimeprioritythreshold	2	任务以高优先级开始执行的时间，单位为s
runtimepriority	medium	达到阈值后的运行优先级别
runtimecap	none	任务执行时长阈值，执行超时强制进入指定级联资源池，或被中断
cascadeto		任务执行时间超过runtimecap后的目标资源池名称
maxconcurrency	none	最大并发任务数，缺省不限制

资源分配和调度

CPU分配

• executionparallelism：每个任务执行的线程数
• cpuaffinity*：高优先级任务可以独占特定的CPU

内存分配

• memorysize：独占的内存。就算空闲，别的资源也不能使用。
• maxmemorysize：允许使用的最大内存。申请内存超出该值后任务会被立即拒绝。资源池已用内存达到该值后，后续任务会排队。
• 任务内存预算：query_budget=maxmemorysize/plannedconcurrency
  预算的含义：规划的时候为任务预留，多退少补。但如果资源池剩余内存不够下一个任务的预算，该任务会被排队。

排队和优先级

• 资源（内存和CPU）不满足任务的请求，任务就会被排队
• 优先级priority高的队列，会优先申请到内存

并发控制

直接限制：最大并发数maxconcurrency

资源池中正在执行的任务数达到maxconcurrency后，后续的任务排队

间接限制：资源不足

• 资源池已用总内存达到maxmemorysize后，后续任务排队
• 可以粗略的认为：资源池并行任务执行数<=plannedconcurrency

动态资源管理

运行时动态调整

• 任何任务都会按最高优先级执行runtimeprioritythreshold时长，然后再按runtimepriority优先级执行
• 任务执行时间超过runtimecap后，会被中断执行，或者进入指定级联资源池

资源池级联

任务执行时间超过runtimecap后，会被移动到cascadeto指定的资源池继续执行（如果新资源池有足够资源）或重新排队

常见并发场景优化方法

并发（混合负载）优化是个统筹优化问题，应先设置目标和评价方法

基本原则

• 应用层要求通过连接池等技术控制并发请求，数据库上的并发请求通常不宜比CPU核数高太多，因为每个连接（哪怕是空闲的）都要消耗一个线程
• 业务用户一定要有自己的资源池，杜绝用缺省general pool，否则系统过载时，dbadmin的管理任务也得排队
• 用profile来评估查询的内存需求，通常让query_budget刚刚满足需求即可，这样可以同时执行更多的任务

特定应用的性能要求高

• 给它高优先级(priority)以便更快抢到资源
• 运行优先级(runtimepriority)为high
• 甚至独占CPU(cpuaffinity*)和内存(memorysize)

特定应用并发/吞吐量要求高

• 尽量用mergejoin/groupbypipe替代hashjoin、groupbyhash，尽管单个查询hashjoin/grouphash可能会更快，但它消耗更多的CPU和内存，不利于并发
• 降低高并发时的上下文切换导致的竞争。高并发场景(尤其是小查询）应适当降低执行并行度(executionparallelism)，以避免过高的context switch和系统调用CPU开销
• 给较多的并发数(maxconcurrency)和最大内存(maxmemorysize)

实在无法对负载进行直接区分，但需要更高的吞吐能力

• 采用资源池级联，让长时间任务在跟低并发的资源池排队，避免“入口”资源池排队，给新进来的小任务执行机会

系统视图

系统表	描述
RESOURCE_POOLS	所有资源池的参数，包括内建资源池
RESOURCE_REJECTIONS	资源请求拒绝情况和拒绝原因
RESOURCE_ACQUISITIONS	通过的每个查询资源请求信息
RESOURCE_POOL_STATUS	所有资源池的当前状态，包括内存使用情况、正在执行的并发查询数
RESOURCE_QUEUES	当前等待队列中的查询，保持资源池和优先级信息
USERS	用户关联的资源池信息