aah yes, FT_PENDING ... I had perhaps falsely presumed this was a cache mechanism to queue fields for the indexer while the indexer was busy doing things (for instance re-indexing, as it is now, or for instance to queue records if the indexer is still working on the last run at the next scan interval).
I see a relatively small number of records in FT_PENDING (around 9k). However, I don't think the indexer is stuck. It is consistently writing to the collection directory (albeit excruciatingly slowly), and also it's logging like mad. It should have several million records to scan ... each with multiple indexed fields, so I would expect this to run for a while, but at the same time ... at this point, I need to get an idea of what it's doing ... how much longer it has to go. People have questions, and I don't have answers :-/ I should mention that we've taken the obvious steps of allocating more threads to the FTS RPC queue and also in the FTS plugin config. I should also mention that for a period of about a week and a half, we had some external issues which were causing the arserverd process to hang, die and restart at least twice daily ... does anyone know if arsystem restart causes an in-progress FTS re-index to dump it's work and begin again? I wonder if this could be part of our problem? By that same token I can't seem to find any obvious way to force FTS to abort a re-index procedure and begin again (presuming that's not what happens by default when you restart arsystem). thanks for the pointers to the docs and the kb guys ... I'll have another search through those. -Andy On May 28, 2013, at 12:53 PM, Tauf Chowdhury wrote: > I may be fuzzy on this but there is a table called FT_Pending that > holds some data on what is being indexed and then dropped once it is > in the collection directory. If your indexing is running for more than > a month though, I'm pretty sure it's hung and not doing anything. The > size of FT_Pending should always be small if the indexing is in > progress. > > Sent from my iPhone > > On May 28, 2013, at 1:47 PM, Andrew Hicox <[email protected]> wrote: > >> Hello everyone, >> >> I currently find myself in the third circle of ARS hell ... debugging FTS on >> ARS 7.6.03 (it's a long story on why we're not on 7.6.04 yet, but suffice it >> to say, I have no immediate control of that situation). >> >> We have had an FTS re-index procedure running for more than a month now. I >> need to get an idea on where it is, and how much longer it needs to finish. >> I can trace some of this through the arftsindex.log(s). It seems to iterate >> per-form, per-indexed field. So ... form A, indexed field 1 ... then indexed >> field 2, etc, etc cycling through every record in the form N times where N >> is the number of indexed columns in the form. >> >> So ... part of this is that I need to be able to know exactly how many such >> fields and forms I'm looking at. >> I need a better way of doing this than to open each form on the server, and >> pick through the field properties on every form. >> >> I've tried running the sql log on server startup to try and capture whatever >> it is the ft dispatcher executes in the DB to find the indexed fields, but >> if it's there I sure as heck can't find it. There do not appear to be any >> obvious columns on the 'FIELD' table that would indicate FTS indexing mode, >> nor do there appear to be any adjunct tables (like the various FIELD_* >> tables) that would contain this data. >> >> I'd like very much to be able to execute a query on the DB that would return >> schemaid and fieldid of all the fields that the FTS indexer is going to try >> and run through. >> >> Does anyone know of a way to do this? >> >> -Andy >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
