I've seen bad things happen with FTS when the server stays up so if your arserver process hung up and restarted, that could def be a problem. In order to start the indexing fresh again, you would need to stop AR, delete the contents of the collection directory and delete the data from FT_Pending. Then start.
Sent from my iPhone On May 28, 2013, at 2:19 PM, Andrew Hicox <[email protected]> wrote: ** 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" _ARSlist: "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"
