Vertica “ERROR: Too many ROS containers exist”

本文讲述使用Vertica时遇到‘ERROR: Too many ROS containers exist’错误。介绍了Vertica存储机制,新数据先写入WOS,再写入ROS,还会进行MoveOut和MergeOut操作。分析可能是ROS过多且操作时间间隔长导致问题,通过减小相关参数间隔解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

原文链接:Vertica “ERROR: Too many ROS containers exist”

最近在用Vertica的时候碰到一个问题,Vertica在运行了一段时间后总是出现类似下面的错误

java.sql.SQLException: [Vertica][VJDBC](5065) ERROR: Too many ROS containers exist for the following projections: 
<projection> (limit = 18078, ROS files = 12088, DV files = 5992, new files = 10)

碰到找个问题就不得不说说Vertica的存储机制了。Vertica在默认情况下会把新写入的数据写入到WOS(写优化)中,然后根据一定的条件(比如说一定的时间周期)再把WOS中的数据写入到ROS(读优化)中,这时ROS有可能很多都是很小数据块的碎片,这是Vertica会在一定的时间周期后把这些ROS数据块合并成大的ROS文件。


这里把数据从WOS写入到ROS的过程Vertica管它叫MoveOut操作,而把零散的ROS合并成大的ROS的过程Vertica管它叫MergeOut操作。


好了,现在来看看我们的问题吧。错误里报的是ROS太多,那可能的原因是
1. WOS写ROS太多,这个原因的原因很大的可能是每次insert/update的数据集太小,导致生成的碎片太多。

2. ROS太多,而配置的MoveOut和MergeOut的时间间隔太长,导致来不及做MoveOut和MergeOut。


好吧来看看我的应用吧
1. 针对第一个可能的原因,确实是我们的应用的需求的问题,这个目前来说我们没法改变。

2. 对于第二个可能的原因,我们查了一下Vertica的资料,在Vertica中默认的MergeOutInterval是600,MoveOutInterval是300。这两个参数可以通过下面的命令来查看

SELECT GET_CONFIG_PARAMETER('MoveOutInterval');
SELECT GET_CONFIG_PARAMETER('MergeOutInterval');

由于我们的应用本身会产生很多的ROS碎片,所以我们想到了是不是可以通过减小MoveOut和MergeOut的Interval来让Vertica尽快的做MoveOut和MergeOut。因此我们修改了Vertica的参数

SELECT SET_CONFIG_PARAMETER('MoveOutInterval', 60);
SELECT SET_CONFIG_PARAMETER('MergeOutInterval', 30);

在修改了这两个参数以后,我们的应用确实在运行了很长时间后都没有再出现上面的问题了。


其实关于这个问题,还有几个参数可以调节,具体资料可以参考
Vertica Tuple Mover Parameters



评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值