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 | 用户关联的资源池信息 |
