This is one of the thing I don't like of version 7.6, the discontinued user tool.
The fact that rebooting the mid-tier fixes the system doesn't mean that the problem is on mid-tier. When you reboot the mid-tier all user sessions at ARS are closed, and any bad situation regarding those sessions is fixed. It happened to me to have a active link endless loop (BMC bug: The typical goto 999 to end the processing, that was written "99", and the goto was at order 500). When the user got inside it, the system started to go slow. Rebooting the mid-tier solved the problem, because the active link stopped. When connecting to the server during the slow-time-frame with the user tool we demonstrate that the ARS was the slow part. So we focused to see what was happening at this part, debug of workflow and see the abnormal API activity. Regards, Jose Huerta On Sat, Jul 21, 2012 at 7:11 AM, Brian Pancia <panc...@finityit.com> wrote: > ** > > Here are a few options you may want to try. These variables do depend on > your architecture and may require tweaking.**** > > ** ** > > Java Settings**** > > ** ** > > -XX:+UseCompressedOops**** > > -XX:+UseConcMarkSweepGC**** > > -XX:+UseParNewGC**** > > -XX:NewRatio=3**** > > -XX:PermSize=256m**** > > -XX:+HeapDumpOnOutOfMemoryError**** > > -XX:ErrorFile=<Path>\java_hs_err.log**** > > -XX:HeapDumpPath=<Path>**** > > -Xincgc**** > > -XX:PermSize=256m**** > > ** ** > > JAVA_HOME C:\Program Files\Java\jdkx.x.x**** > > JAVA_OPTS –server –Xms3072m –Xmx4096m**** > > ** ** > > Tomcat**** > > ** ** > > <Connector URIEncoding="UTF-8" acceptCount="250"**** > > connectionTimeout="90000" disableUploadTimeout="true"**** > > enableLookups="false" maxHttpHeaderSize="8192"**** > > maxKeepAliveRequests="-1" maxThreads="300"**** > > minSpareThreads="50" port="80"**** > > protocol="HTTP/1.1" redirectPort="8443"/>**** > > ** ** > > Mid-Tier**** > > ** ** > > Turn off preload**** > > arsystem.cache_update_interval=86400**** > > arsystem.formhtmljs_expiry_interval=86400**** > > arsystem.resource_expiry_interval=86400**** > > arsystem.pooling_max_connections_per_server=80**** > > arsystem.log_level=Severe**** > > arsystem.ehcache.overflowToDisk=true**** > > arsystem.encache.overflowToDiskTemp=false**** > > ** ** > > ARS**** > > ** ** > > Allow-Unqual-Queries F**** > > Max-Entries-Per-Query 2000**** > > Turn Development Cache Mode off**** > > if using FTS setup 390602 2 2 thread**** > > ** ** > > ** ** > > Brian**** > > ** ** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Ibbi > *Sent:* Friday, July 20, 2012 9:13 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: 7.6.04 Super Slow**** > > ** ** > > ** **** > > I just realized that you mentioned it is consistent! Sorry for lack of > attention! Watching a rare game (blue jays vs red sox and jays are actually > winning!) Please have your systems team check the environment for taks/jobs > scheduled during that time or any new changes to the infrastructure. **** > > ** ** > > > Sent from my iPhone**** > > > On Jul 20, 2012, at 9:05 PM, Ibbi <ahmed.sa...@gmail.com> wrote:**** > > It's a tricky one but here's my stab at it. I'm not saying its not > possible but i think it's not the app. It could be the environment.**** > > ** ** > > Can you please provide: **** > > ** ** > > if the slowness is consistent during a particular time during the day? Is > it always the case? **** > > > > **** > > What about Afterhours? Does the slowness also happen during Afterhours? > <--- key since that's how I found my issue! example: the systems team is > testing a new back up system or daily network job/task of some sort. **** > > > > **** > > I see your on Sp3, when was SP3 applied? Or was it from a fresh install > that included SP3?**** > > > > **** > > > > **** > > > Sent from my iPhone**** > > > On Jul 20, 2012, at 6:32 PM, Tauf Chowdhury <taufc...@gmail.com> wrote:*** > * > > ** Claire, > I'm going to assume that your AR servers are fine during this? In that > case, and since you mentioned everything is OK when rebooting the mid-tier, > it could be, like Ravi mentioned, the pre-load setting. Usually, I turn > that off once the mid tier has been up for a few days. Also, you could > check to see in the java settings on the mid tier, to see if you have the > following garbage collection related settings enabled. This could lead to > some stability for you. > > -XX:+UseCompressedOops > -XX:+UseConcMarkSweepGC **** > > On Fri, Jul 20, 2012 at 5:33 PM, ravi rai <ravira...@hotmail.com> wrote:** > ** > > ** **** > > How many App server you have and how many Mid tier serves? > Running FTS and all operation on a single box might cause that as FTS is > very heavy > You can also check Tomcat settings related to HTTP-keep Alive , max and > min memory, Heap size etc > Refere 7.6 Performance tuning for BSM.pdf > > check your defination check interval, pre Load , Prefetch setting, caching > on Mid tier might be causing it. > > > Ravi > > **** > > > **** > > > -- > *Tauf Chowdhury > > * > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _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"
