GaussDB(DWS)的CPU资源隔离管控介绍
CPU资源管控概述
在不同的业务场景中，对数据库的系统资源（CPU资源、内存资源、IO资源和存储资源）进行合理的分配，保证执行查询时有充足的系统资源，确保查询性能，可以维持业务稳定性。
GaussDB(DWS)的资源管理功能支持用户根据自身业务将资源按需划分成不同的资源池，不同资源池之间资源互相隔离。再通过关联数据库用户将其关联至不同的资源池，用户SQL查询时将根据“用户-资源池”的关联关系将查询转至资源池中执行。通过指定资源池上可并行运行的查询数、单查询内存上限以及资源池可使用的内存和CPU资源，从而实现对不同业务之间的资源限制和隔离，满足数据库混合负载需求。
GaussDB(DWS)主要利用cgroup（control group，控制组）进行CPU资源管控，涉及CPU、cpuacct、cpuset子系统。CPU共享配额管控基于CPU子系统的cpu.shares实现，该配置方法的好处是：OS CPU没有占满的情况下，不触发CPU管控；CPU专属限额管控基于cpuset实现；cpuacct子系统主要用于CPU资源使用的监控。
在DWS管理控制台使用资源管理配置功能创建资源池时，根据业务需要对CPU资源管理的“共享配额”和“专属配额”进行配置。
共享配额
共享配额：关联在当前资源池的用户在执行作业时可以使用的CPU时间比例。
共享配额有两层含义：
- 共享：CPU是所有控制组共享的，其他控制组能够使用空闲的CPU资源。
- 配额：业务繁忙、CPU满负载情况下，控制组之间按照配额比例进行CPU抢占。
共享配额基于cpu.shares实现，只有在CPU满负载情况下生效，因此在CPU空闲情况下并不能保证控制组能够抢占到配额比例的CPU资源。CPU空闲并不能理解为没有CPU资源争抢，控制组内任务可以任意使用CPU。虽然CPU平均使用率可能不高，但是某个特定时刻还是可能存在CPU资源争抢的。
例如：10个CPU上运行10个作业，每个CPU上运行1个作业，这种情况下各作业在任意时刻请求CPU都可以瞬间得到响应，作业之间没有任何CPU资源的争抢；但假如10个CPU上运行20个作业，因为作业不会一直占用CPU，在某些时间可能等待IO、网络等，因此CPU使用率可能并不高，此时CPU资源看似空闲，但是在某个时刻可能出现2~N作业同时请求一个CPU的情况出现，即会导致CPU资源争抢，影响作业性能。
专属限额
专属限额：限定资源池中数据库用户在执行作业时可使用的最大CPU核数占总核数的百分比。
- 专属：CPU是某个控制组专属的，其他控制组不能使用空闲的CPU资源。
- 限额：只能使用限额配置的CPU资源，其他控制组空闲的CPU资源，也不能抢占。
专属限额基于cpuset.cpu实现，通过合理的限额设置可以实现控制组之间CPU资源的绝对隔离，各控制组间任务互不影响。但因为CPU的绝对隔离，因此在控制组空闲时就会导致CPU资源的极大浪费，因此限额设置不能太大。从作业性能来看并不是限额越大越好。
例如：10个作业运行在10个CPU上，CPU平均使用率5%左右；10个作业运行在5个CPU上，CPU平均使用率10%左右。通过上面共享配额的分析可知：虽然10个作业运行在5个CPU上CPU使用率很低，看似空闲，但是相对10个作业运行在10个CPU上还是存在某种程度的CPU资源争抢，因此10个作业运行在10个CPU上性能要好于运行在5个CPU上。但也不是越多越好，10个作业运行在20个CPU上，在任意一个时刻，总会至少10个CPU是空闲的，因此理论上10个作业运行在20个CPU上并不会比运行在10个CPU上性能更好。对于并发为N的控制组，分配cpus小于N的情况下，CPU越多作业性能越好；但是当分配CPUS大于N的情况下，性能就不会有任何提升了。
CPU资源管理应用场景
CPU共享配额和专属限额的管控方式各有优劣，共享配额能够实现CPU资源的充分利用，但是各控制组之间资源隔离不彻底，可能影响查询性能；专属限额的管控方式可以实现CPU资源的绝对隔离，但是在CPU资源空闲时会造成CPU资源的浪费。相对专属限额来说，共享配额拥有更高的CPU使用率和更高的整体作业吞吐量；相对共享配额来说，专属限额CPU隔离彻底，更满足性能敏感用户的使用诉求。
数据库系统中运行多种类型作业出现CPU争抢时，可根据不同场景，选择不同的CPU资源管控方式：
