I submitted an issue with BMC support about this, and we've managed to figure out part of the problem. Since I'm testing this on a development server, I have Cache-mode (Development Cache Mode checkbox in the admin tool in server info, configuration tab) set to 1 in ar.cfg. Turns out this being on will cause client's to be blocked until any pending admin operations complete (initially tagging a field for FTS is an admin operation). Setting Cache-mode to 0 and restarting the server now will allow me to mark a field for FTS, save the form, and have my admin tool and any clients function normally....well, almost.
I figure now that I have the client blocking problem figured out, I'll queue up indexing operations for the issue summary and issue details fields on SPRT:Issue and Interaction Notes on SPRT:Interaction. Both operations queue up successfully (I can see them in the ft_pending table). Now I'll go see what the performance hit to the clients looks like. I go open a test issue, make some changes, save the issue, performance isn't really all that different. I like what I see. I go to add an activity to the same test ticket, no problem there either. I open another test ticket (created just a few days ago, not weeks ago) make some changes (not to FT-indexed fields, just the assigned person field), click save....uh-oh: ARERR [657] Failed to complete full text operation : [Hummingbird] [SearchServer]Invalid table name (FTSTATE SGS00) Huh? How is it that the "table" exists for the older issue but not this newer one? I checked the Hummingbird directory, and I see a bunch of files with various extensions that appear to match the "table" names mentioned in the full-text log. For example: t370c300120200.cat t370c300169300.cat Anyway, I'm still working with BMC on this one. Just wanted to post an update in case anyone was interested. Cheers! Mike On Jun 19, 9:17 am, patrick zandi <[EMAIL PROTECTED]> wrote: > Here is some additional helps > > --step 1----- > So your FTS Collection Directory is the correct one. > FTS Configuration Directory is correct > FTS Temp directory is correct > I have indexing failure recover interval (minutes) 60 > Temporary table threshold (1-250) 200 > Complex search threshold 1000000 > Indexer opticization threshold 1000 > Case: insensitive > Query unchanged > - My reindex is grayed out - > Diable full text indexer is not selected > ignore workds list is the default installation. > ------------step 2---------------- AR .CONF > Full-Text-License-Timeout: 1 > FTS-Debug-mode: 15 > Full-Text-Collection-Directory: C:\Program Files\Hummingbird\SearchServer > 5.4\fultext > Full-Text-Configuration-Directory: C:\Program Files\Hummingbird\SearchServer > 5.4\fultext > Full-Text-Temp-Directory: C:\Documents and Settings\Administrator\Local > Settings\Temp\1 > ====step 3===== > under the SearchServer Admin --- > you have tables there right ? > can you select one, and see table data? > select index long --- what kind of times do you see there.. are they long ? > ----------------Step 4------ > When you drop a smaller index and tell it to index again -- did you also > remove the index from the SearchServer admin ? > next time you drop one, do that, and then watch your I/O on your solaris box > while doing the indexing .. > vmstat 1 2000 - > IOstat -xtc 2 2000 > Examine output --- if your vmstat has alog of B (second column) numbers in a > row -- this is bad. > If you have the MF section consistantly high or double digits.. this is bad > > If you have the DE section Consistanly high = this is bad. > --- > IOstat exam - If a disk shows consistently high reads/writes along with , > the percentage busy (%b) of the disks is greater than 5 percent, and the > average service time (svc_t) is greater than 30 milliseconds > ----http://www.adminschoice.com/docs/iostat_vmstat_netstat.htm > > hopefully this will help you some.. > > zandi > > On 6/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > Oh, I should have mentioned that I have a separate thread queue set up > > for the full-text indexer: RPC 390602, min 4 max 8. This is a reserved > > RPC number, if you will, for the full text indexer according to the > > configuration guide (Configuring-700.pdf, page 153). > > > Mike > > > On Jun 17, 1:19 pm, Jarl Grøneng <[EMAIL PROTECTED]> wrote: > > > This does not help. Admin tool always use rpc 309600, and single > > > threaded. This is because you need constency in the database. > > > > -- > > > Jarl > > > > On 6/17/07, Grooms, Frederick W <[EMAIL PROTECTED]> wrote: > > > > > ** > > > > > What about using a private thread when you create the indexes? Add a > > > > private thread (say 309650 with min 2 max 4) to the server and specify > > this > > > > thread when using the Admin tool. > > > > This way you shouldn't tie up the admin thread. > > > > > Fred > > > > > ________________________________ > > > > From: Action Request System discussion list(ARSList) > > > > [mailto:[EMAIL PROTECTED] On Behalf Of patrick zandi > > > > Sent: Friday, June 15, 2007 3:58 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: ARS 7 and FTS > > > > > ** I might be working some this weekend.. I will try a couple of > > things to > > > > see if anything like what you are seeing.. happens.. > > > > > On 6/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Yeah, 32 is pretty excessive, but I was trying to see if I could get > > > > > the behavior to change. > > > > > > Just to be clear, updating the FT index when a record changes take > > > > > virtually no time at all. It's the initial indexing when one first > > > > > marks a field to be full text indexed that's "locking up" the > > server. > > > > > > My dev server has the DB, ARS, and FTS on the same box (production > > has > > > > > separate HW for ARS and SQL). It's a Dell 1850, two 3GHz Xeon CPU > > > > > (single core), 4GB RAM, HW resources really doesn't seem to be the > > > > > issue. > > > > > > Mike > > > > > > On Jun 15, 2:21 pm, patrick zandi <[EMAIL PROTECTED]> wrote: > > > > > > Mike, > > > > > > I have ARS 7.00 P2 and FTS. > > > > > > FTS is working fine, and it very fast on the updates.. and > > accurate from > > > > > > what I have tested. > > > > > > I have not seen the lockup at all. I am not on 7.01P2 yet, > > however I > > > > tryed > > > > > > P3 and could not login to the server.. > > > > > > I do not know if it was related to what you are saying yet... My > > Java > > > > is a > > > > > > lower version though.. and I am on SP2. > > > > > > Java 1.4.2_13 > > > > > > The record count is close to mine on some and it does not take > > long at > > > > all > > > > > > to update it. > > > > > > Threads for me are 4 - 8max..have no issues,, 32 seems quiet > > excessive > > > > > > though. > > > > > > What kind of HW ? Multiple CPU's ? duel/quad core's ? is the DB > > and > > > > ARS on > > > > > > same with FTS ? > > > > > > > Hope this give you some info... > > > > > > > > On 6/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > Anyone out there using FTS on ARS 7? If so, I have some > > questions > > > > > > > about your experiences: > > > > > > > > First off (this is one of my development servers): > > > > > > > > ARS 7.0.1 patch 2, Windows 2003 SP1, SQL 2000 SP4, Java 1.5.0_11 > > > > > > > > So I recently purchased some FTS fixed user licenses and I've > > applied > > > > > > > them to one of my development servers where I have a bunch of > > home > > > > > > > grown apps, one of which is a help desk application. I've marked > > two > > > > > > > zero-length character fields (i.e. long text fields) for full > > text > > > > > > > indexing (the problem description and the work log). Upon saving > > the > > > > > > > form, the initial indexing starts (fine), but now my admin tool > > is > > > > > > > "locked" and will either time our after an unusually long period > > of > > > > > > > time, or will remain locked until the indexing is complete. > > Also, from > > > > > > > a client perspective, the server is COMPLETELY UNAVAILABLE > > (ARERR 93 - > > > > > > > timeout during data retrieval due to busy server -- retry the > > > > > > > operation). > > > > > > > > While I expect that an initial FT index would take some time to > > > > > > > complete on 70,000 records, I do not expect the indexing > > operation to > > > > > > > tie up the server so terribly that clients can't even log in. It > > > > > > > doesn't appear to be a resource issue, arserver.exe is only > > using > > > > > > > between 5 and 20 percent of the CPU, and as of right now, there > > is > > > > > > > nearly 3GB of physical RAM available. > > > > > > > > At first I thought it might be a thread thing, so I upped > > fast/list/ > > > > > > > ftindexer threads to min 4 max 32 (from min 2 max 4), but that > > doesn't > > > > > > > seem to have made a difference. > > > > > > > > I have plans to also implement FTS on my CSS servers, where I'd > > like > > > > > > > to index the Issue Details field on the SPRT:Issue form and the > > > > > > > Interaction Notes field on the SPRT:Interaction field, as those > > fields > > > > > > > are heavily searched. However, based on some initial testing > > I've > > > > > > > done, performing an initial index on the Issue Details field on > > about > > > > > > > 200,000 records takes about 95 minutes to complete (that's a > > > > > > > reasonable amount of time IMHO), but the server is completely > > > > > > > unavailable while indexing. OK, that's not so bad, but when I > > started > > > > > > > to calculate some rough times for the SPRT:Interaction form, I > > was > > > > > > > coming up with times in excess of five and a half hours (about > > 700,000 > > > > > > > records). > > > > > > > > So, to upgrade my production CS servers to ARS 7, I'm looking at > > 30-60 > > > > > > > minutes to upgrade arserver, email, mid-tier, etc., about 90 > > minutes > > > > > > > to index one field on SPRT:Issue, and roughly 5.5 hours to index > > one > > > > > > > field on SPRT:Interaction. This adds up to (again, > > approximately) > > > > > > > eight full hours (or more) of complete and utter downtime (not a > > good > > > > > > > deal for a 24x7 shop). > > > > > > > > Thoughts? Other stories to share? > > > > > > > > Thanks everyone. > > > > > > > > Mike Wallick > > > > > > > -- > > > > > > Patrick Zandi > > > > > -- > > > > Patrick Zandi > > > > > __20060125_______________________This posting was > > > > submitted with HTML in it___ > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where > > the Answers Are" > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where > > the Answers Are" > > -- > Patrick Zandi > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where the > Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
