Vertica “ERROR: Too many ROS containers exist”，verticacontainers

Vertica “ERROR: Too many ROS containers exist”，verticacontainers

原文連結：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