Thanks Tauf. We'll check into that, and we do separate out the fts javaplugins.
Regards, Andrew C. Goodall Software Engineer Development Services ago...@jcpenney.com jcpenney 6501 Legacy Drive Plano, TX 75024 jcp.com From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org] On Behalf Of Tauf Chowdhury Sent: Friday, July 27, 2012 2:14 PM To: arslist@arslist.org Subject: Re: 7.6.04 FTS real world experience for ITSM global search ** Andrew, One of the things I've had to do in a past environment is modify the knowledge search screens that open from within the consoles, mainly the Incident Console. By default, when the screen opens, all of the search sources are checked off so each time a user clicks the Search Knowledge link, a massive search is done. I modified the on open behavior to only check knowledge articles by default. This helped stabilize our environment because it stopped bombarding FTS. Another thing, which maybe you are doing, is dedicating one server to indexing and then separating out the java plugins themselves to be dedicated to each user facing server for searching. Sent from my iPhone On Jul 27, 2012, at 10:54 AM, "Goodall, Andrew C" <ago...@jcp.com> wrote: ** I'm garnering comments / feedback concerning their experience around the performance and stability of FTS for global search in ITSM 7.6.04 sp2 (ARS 7.6.04 sp3) in a server group environment with a large FTS index collection. I have an issue open with support currently where FTS plugin becomes unresponsive because it keeps running out of Java heap space. We have split the FTS indexer from the FTS searchers (per BMC support recommendations in unpublished KA363429) , so all forward facing ars servers (2 active) go against the same FTS process (we call it FTS_searcher) on the primary admin sever. So far BMC support has had us raise the Xmx from 1024 to 2048, and now to 3072. FYI - this is x64 java process on Windows 2008 x64 Each time we have bump the Xmx it runs out for memory. I was able to reproduce the rapid consumption of java memory by simply performing an incident matching search, the FTS_searcher process used up 2Gb in less than 10 seconds. Additionally, I've seen the plugin still state it was out of java heap even though the java process was no longer consuming the max Xmx defined (I'm guessing because GC ran). Looks like a lack of recovery mechanisms in place. Our FTS collection folder is 34GB in size (is that large? Above the average?), about 1.4 million incidents indexed will be the majority, plus PBIs, CRQs, RKM KAs If you have experienced similar behavior I'd love to hear your comments, but I mainly want to try and gauge from the community (with a similar setup) how stable they have seen this functionality to be. We were almost ready to go live with 7.6.04, but this is a show stopper - we can't have this instability. Regards, Andrew C. Goodall Software Engineer Development Services ago...@jcpenney.com jcpenney 6501 Legacy Drive Plano, TX 75024 jcp.com The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
