Hi Morten,<div><br></div><div>Thanks for sending the log files. I was able to figure out, at least partially, what's going on here.</div><div><br></div><div>The "Failed to compact" message is a result of trying to index a token that's greater than 32kb in size. (The index storage engine, called merge_index, assumes tokens sizes smaller than 32kb.) I was able to decode part of the term in question by pulling data from the log file, and it looks like you may be indexing HTML with base64 encoded inline images, ie: <span class="Apple-style-span" style="color: rgb(0, 153, 0); font-family: monospace, 'Courier New'; font-size: 13px; line-height: 15px; white-space: pre; "><<span class="kw2" style="color: rgb(0, 0, 0); font-weight: bold; ">img</span> <span class="kw3" style="color: rgb(0, 0, 102); ">src</span><span class="sy0" style="color: rgb(102, 204, 102); ">=</span><span class="st0" style="color: rgb(255, 0, 0); ">"data:image/jpeg;base64,iVBORw0KG..."</span></span><span class="Apple-style-span" style="color: rgb(0, 153, 0); font-family: monospace, 'Courier New'; font-size: 13px; line-height: 15px; white-space: pre; ">> </span>The inline image is being treated as a single token, and it's greater than 32kb.</div>
<div><br></div><div>The short term workaround is to either:</div><div><br></div><div>1) Preprocess your data to avoid this situation.</div><div>2) Or, create a custom analyzer that limits the size of terms (See <a href="http://wiki.basho.com/Riak-Search---Schema.html">http://wiki.basho.com/Riak-Search---Schema.html</a> for more information about analyzers and custom analyzers.)</div>
<div><br></div><div>The long term solution is for us to increase the maximum token size in merge_index. I've filed a bugzilla issue for this, trackable here: <a href="https://issues.basho.com/show_bug.cgi?id=1069">https://issues.basho.com/show_bug.cgi?id=1069</a></div>
<div><br></div><div>Still investigating the "Too many db tables" error. This is being caused by the system opening too many ETS tables. It *may* be related to the compaction error described above, but I'm not sure. </div>
<div><br></div><div>Search (specifically merge_index) uses ETS tables heavily, and the number of tables is affected by a few different factors. Can you send me some more information to help debug, specifically:</div><div>
<ul><li>How many partitions (vnodes) are in your cluster? (If you haven't changed any settings, then the default is 64.)</li><li>How many machines are in your cluster?</li><li>How many segments are on the node where you are seeing these errors?<br>
(Run: "<b><font class="Apple-style-span" face="'courier new', monospace">find DATAPATH/merge_index/*/*.data | wc -l</font></b>", replacing DATAPATH with the path to your Riak data directory for that node.)</li>
<li>Approximately how much data are you loading (# Docs and # MB), and how quickly are you trying to load it?</li></ul><div>Best,</div></div><div>Rusty</div><div><br></div><div><div class="gmail_quote">On Thu, Apr 14, 2011 at 3:07 AM, Morten Siebuhr <span dir="ltr"><<a href="mailto:sbhr%2Blists@sbhr.dk">sbhr+lists@sbhr.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Rusty & al,<br>
<div class="im"><br>
On Wed, Apr 13, 2011 at 11:20 PM, Rusty Klophaus <<a href="mailto:rusty@basho.com">rusty@basho.com</a>> wrote:<br>
> Thanks Morten, having the logs (including the numbers) will help us debug<br>
> what's going on.<br>
<br>
</div>Here it is.<br>
<br>
It seems we've hit some db-imposed limit during the night's test data<br>
import - I'll have to investigate that too...<br>
<br>
Kind regards,<br>
<font color="#888888">Morten Siebuhr<br>
</font></blockquote></div><br></div>