Hi Morten,<div><br></div><div>It looks like at least one of the offending fields is "photos_value", which, as you said, should be skipped according to your schema. This makes me think that either the schema isn't set correctly, or that one or more nodes is caching an old value of the schema. </div>
<div><br></div><div>Can you try running "search-cmd show-schema INDEXNAME" on each node to verify that the schema is set correctly? Also, you can run "search-cmd clear-schema-cache" to clear the schema cache across all nodes. </div>
<div><br></div><div>Also, the number of segments is *way* higher than it should be, and this is the reason for the "too many DB tables" error. It appears that these problems are linked, the compaction errors are preventing the system from combining segments, leading to a large number of segments, so solving one problem should solve the other.</div>
<div><br></div><div>Best,</div><div>Rusty<br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 4:27 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,<br>
<div class="im"><br>
On Thu, Apr 14, 2011 at 8:00 PM, Rusty Klophaus <<a href="mailto:rusty@basho.com">rusty@basho.com</a>> wrote:<br>
> Hi Morten,<br>
> Thanks for sending the log files. I was able to figure out, at least<br>
> partially, what's going on here.<br>
<br>
</div>Fantastic - thanks!<br>
<div class="im"><br>
> The "Failed to compact" message is a result of trying to index a token<br>
> that's greater than 32kb in size. (The index storage engine, called<br>
> merge_index, assumes tokens sizes smaller than 32kb.) I was able to decode<br>
> part of the term in question by pulling data from the log file, and it looks<br>
> like you may be indexing HTML with base64 encoded inline images, ie: <img<br>
> src="data:image/jpeg;base64,iVBORw0KG..."> The inline image is being treated<br>
> as a single token, and it's greater than 32kb.<br>
<br>
</div>That's odd - in the search schema, I asked it to ignore everything<br>
besides a few specific fields:<br>
<br>
{<br>
        schema,<br>
        [<br>
                {version, "0.1"},<br>
                {default_field, "_owner"},<br>
                {n_val, 1}<br>
        ],<br>
        [<br>
                %% Don't parse _id and _owner, just treat it as single token<br>
                {field, [<br>
                                {name, "id"},<br>
                                {required, true},<br>
                                {analyzer_factory, {erlang, text_analyzers, noop_analyzer_factory}}<br>
                        ]},<br>
                {field, [<br>
                                {name, "_owner"},<br>
                                {required, true},<br>
                                {analyzer_factory, {erlang, text_analyzers, noop_analyzer_factory}}<br>
                        ]},<br>
<br>
                %% Parse Name fields for full-text indexing<br>
                {field, [<br>
                                {name, "displayName"},<br>
                                {aliases, ["nickname", "preferredUsername", "name_formatted",<br>
"name_displayName"]},<br>
                                {analyzer_factory, {erlang, text_analyzers, standard_analyzer_factory}}<br>
                        ]},<br>
<br>
                {field, [<br>
                                {name, "emails_value"},<br>
                                {analyzer_factory, {erlang, text_analyzers, standard_analyzer_factory}}<br>
                        ]},<br>
<br>
                %% Add modification dates<br>
                {field, [<br>
                                {name, "published"},<br>
                                {aliases, ["updated"]},<br>
                                {type, date}<br>
                        ]},<br>
<br>
                %% Skip all else...<br>
                {dynamic_field, [<br>
                                {name, "*"},<br>
                                {skip, true}<br>
                        ]}<br>
        ]<br>
}.<br>
<br>
(We're indexing Portable Contacts, where the user images reside in a<br>
'image'-field.)<br>
<div class="im"><br>
> The short term workaround is to either:<br>
> 1) Preprocess your data to avoid this situation.<br>
> 2) Or, create a custom analyzer that limits the size of terms<br>
> (See <a href="http://wiki.basho.com/Riak-Search---Schema.html" target="_blank">http://wiki.basho.com/Riak-Search---Schema.html</a> for more information<br>
> about analyzers and custom analyzers.)<br>
> The long term solution is for us to increase the maximum token size in<br>
> merge_index. I've filed a bugzilla issue for this, trackable<br>
> here: <a href="https://issues.basho.com/show_bug.cgi?id=1069" target="_blank">https://issues.basho.com/show_bug.cgi?id=1069</a><br>
> Still investigating the "Too many db tables" error. This is being caused by<br>
> the system opening too many ETS tables. It *may* be related to the<br>
> compaction error described above, but I'm not sure.<br>
> Search (specifically merge_index) uses ETS tables heavily, and the number of<br>
> tables is affected by a few different factors. Can you send me some more<br>
> information to help debug, specifically:<br>
><br>
> How many partitions (vnodes) are in your cluster? (If you haven't changed<br>
> any settings, then the default is 64.)<br>
<br>
</div>It's 64 (no defaults changed at all).<br>
<div class="im"><br>
> How many machines are in your cluster?<br>
<br>
</div>Four.<br>
<div class="im"><br>
> How many segments are on the node where you are seeing these errors?<br>
> (Run: "find DATAPATH/merge_index/*/*.data | wc -l", replacing DATAPATH with<br>
> the path to your Riak data directory for that node.)<br>
<br>
</div>foreach srv ( nosql1 nosql2 nosql4 nosql5 )<br>
echo -n "$srv "; ssh $srv sh -c 'find<br>
/var/lib/riaksearch/merge_index/*/*.data | wc -l'<br>
end<br>
nosql1 32434<br>
nosql2 14170<br>
nosql4 15480<br>
nosql5 13501<br>
<br>
(nosql1 is the one the error log is lifted from - but the errors<br>
seemed to come of all of the servers.)<br>
<div class="im"><br>
> Approximately how much data are you loading (# Docs and # MB), and how<br>
> quickly are you trying to load it?<br>
<br>
</div>~17m records, weighing in just shy of four GB.<br>
<br>
While I didn't do the loading, I believe we did it with 25 concurrent<br>
threads, using the four machines in round-robin fashion.<br>
<font color="#888888"><br>
/Siebuhr<br>
</font></blockquote></div><br></div>