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 at www.arslist.org ARSlist:"Where the Answers Are"
