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 > > > _______________________________________________________________________________ > > 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"
