Here's what we figured out with the final problem we were having with FTS. The server I upgraded to ARS 7 also has SLA installed. Many fields on various SLA forms are marked for full-text indexing; it's just that a 6.3 server ignores that attribute. Once the server was upgraded to ARS 7, all the fields on SLA forms marked for FTS became "active" for lack of a better word, so when saving an issue that had an active SLA running against it, the FTS service couldn't update the FTS "table" for the SLA:Rule Event Occurrence form because the initial index had never been created. What I ended up doing was going through all the SLA fields that were marked for FTS indexing, removing them from FTS and adding them back in to FTS so the Hummingbird "tables" would get created. That's the hard way. BMC told me that triggering a re-index operation would have the same effect.
Mike On Jun 20, 12:14 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 > forFTSis an admin operation). Setting Cache-mode to 0 and restarting > the server now will allow me to mark a field forFTS, 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 yourFTSCollection Directory is the correct one. > >FTSConfiguration Directory is correct > >FTSTemp 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:ARS7andFTS > > > > > > ** 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, andFTSon the same box (production > > > has > > > > > > separate HW forARSand 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 haveARS7.00 P2 andFTS. > > > > > > >FTSis 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 > > > > >ARSon > > > > > > > same withFTS? > > > > > > > > Hope this give you some info... > > > > > > > > > On 6/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > Anyone out there usingFTSonARS7? If so, I have some > > > questions > > > > > > > > about your experiences: > > > > > > > > > First off (this is one of my development servers): > > > > > > > > >ARS7.0.1 patch 2, Windows 2003 SP1, SQL 2000 SP4, Java 1.5.0_11 > > > > > > > > > So I recently purchased someFTSfixed 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 implementFTSon 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 toARS7, I'm looking at > > > 30-60 > > > > > > > > minutes to upgrade arserver, email, mid-tier, etc., about 90 > > > minutes > > > > > > > > to index one field on > > ... > > read more » _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
