# 列存小CU多导致的性能慢问题
实际业务场景中，用户会大量使用列存表，但是列存表使用不当会造严重的性能问题，最常见的就是列存小CU过多导致的性能慢问题。
#### 问题现象
1. 系统I/O长期飙升过高，查询偶发性变慢。
2. 查看偶发慢业务慢时的执行计划信息，慢在cstore scan，且扫描数据量不大但扫描CU个数较多。 ![](https://support.huaweicloud.com/trouble-dws/figure/zh-cn_image_0000001537213521.png "点击放大")
   如图，一个CU能够存放6万条记录，而计划中7万记录需要扫描2000+ CU，说明当前可能存在小CU较多的情况 。
   
 
#### 排查方法
查看相关表CU中数据分布情况，以下操作在DN执行。
1. 查看列存表对应的cudesc表 针对非分区表：
   ```
   SELECT 'cstore.'||relname FROM pg_class where oid = (SELECT relcudescrelid FROM pg_class c inner join pg_namespace n on c.relnamespace = n.oid where relname = 'table name' and nspname = 'schema name');
   ```
   针对分区表：
   ```
   SELECT 'cstore.'||relname FROM pg_class where oid in (SELECT p.relcudescrelid FROM pg_partition p,pg_class c,pg_namespace n where c.relnamespace = n.oid and p.parentid = c.oid and c.relname = 'table name' and n.nspname = 'schema name' and p.relcudescrelid != 0);
   ```
   
2. 查看cudesc中各CU的rowcount情况 查询步骤一返回的cudesc表信息，查询结果类似如下，主要关注row_count过小（远小于6万）的CU数量，如果此数量较大，说明当前小CU多，CU膨胀问题严重，影响存储效率和查询访问效率。
   ![](https://support.huaweicloud.com/trouble-dws/figure/zh-cn_image_0000001537223649.png "点击放大")
   
 
#### 触发场景
列存频繁小批量导入，针对含分区且分区个数比较多的场景，小CU问题更加突出。
#### 解决方案
**业务侧：**
1. 对列存表进行攒批入库，单次入库量（有分区则针对单分区单次入库量）接近或大于60000\*主DN个数。
2. 表数据量不大时建议改为行存表。
**运维侧：**
当业务侧因业务特征无法调整入库量时，定期对列存表进行VACUUM FULL可达到整合小CU的目的，一定程度缓解小CU问题。