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