My InternalIndexer is showing 0 documents. I've confirmed this is the case using Luke. I've tried to rebuild it using the Examine Management tab in the Developer section of the back-office, but I cannot get it to complete. It runs for an hour or so and then stops. There's nothing in the log at all regarding this rebuild operation, however, we can see the CPU on the server go up and sustain at 35%.
One theory is the app pool is recycling, although there's no specific evidence of that.
Umbraco 6.1.6, there are 233,820 records in our umbracoNode table.We have other Examine indexes that we can rebuild just fine.
The only Examine related events in the log file are these:
2013-12-04 00:12:06,062 [8] INFO Umbraco.Web.Search.ExamineEvents - [Thread 1] Initializing Examine and binding to business logic events 2013-12-04 00:12:06,078 [8] INFO Umbraco.Web.Search.ExamineEvents - [Thread 1] Adding examine event handlers for index providers: 6
I don't know what gatheringnodedata is, so I'm assuming I'm not doing anything with it.
Here's my InternalIndexer configuration, which I believe is just the stock config...
We have the same problem with on Umbraco version 6.1.1.
It does seem to eventually finish even though the front-end timesout. What's odd is that you don't see the Lucene index files churning for extended periods during the rebuild. That makes me think Umbraco is doing something inefficiently on the calls to rebuild.
I have a pet theory there's a query under the hood that touches the umbraco history table when supportUnpublished & supportProtected is true. The rationale is that our database used to be as large as yours, but we purged 90% of the content. The only data of scale remaining is the history.
I'll experiment with purging history over the next few days to test the hypothesis.
Cannot get InternalIndexer Examine index to finish rebuilding
My InternalIndexer is showing 0 documents. I've confirmed this is the case using Luke. I've tried to rebuild it using the Examine Management tab in the Developer section of the back-office, but I cannot get it to complete. It runs for an hour or so and then stops. There's nothing in the log at all regarding this rebuild operation, however, we can see the CPU on the server go up and sustain at 35%.
One theory is the app pool is recycling, although there's no specific evidence of that.
Umbraco 6.1.6, there are 233,820 records in our umbracoNode table.We have other Examine indexes that we can rebuild just fine.
Thoughts?
David,
Can you see anything in the umbraco log file? Also are you doing anything with gatheringnodedata on the internalindex?
Regards
Ismail
The only Examine related events in the log file are these:
I don't know what gatheringnodedata is, so I'm assuming I'm not doing anything with it.
Here's my InternalIndexer configuration, which I believe is just the stock config...
ExamineIndex.config:
ExamineSettings.config:
This is still an issue for us. Does anyone have any thoughts on this?
We have the same problem with on Umbraco version 6.1.1.
It does seem to eventually finish even though the front-end timesout. What's odd is that you don't see the Lucene index files churning for extended periods during the rebuild. That makes me think Umbraco is doing something inefficiently on the calls to rebuild.
I have a pet theory there's a query under the hood that touches the umbraco history table when supportUnpublished & supportProtected is true. The rationale is that our database used to be as large as yours, but we purged 90% of the content. The only data of scale remaining is the history.
I'll experiment with purging history over the next few days to test the hypothesis.
is working on a reply...