limit AIE, put it on its own queue and limit the number of Threads to account for CPU usage.. I put all 32 cpu's at 85% once.. lol
On Wed, Mar 14, 2012 at 12:29 PM, Joe Martin D'Souza <jdso...@shyle.net>wrote: > ** > > Another one.. Disk fragmentation on the database server can often lead to > latency I was told wayyyyy back in the days.. I’m sure that is still > applicable.. Solution is to defrag the disk on regular maintenance cycles.. > > Joe > > *From:* patrick zandi <remedy...@gmail.com> > *Sent:* Wednesday, March 14, 2012 11:32 AM > *Newsgroups:* public.remedy.arsystem.general > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Performance Tuning > > ** I agree:: Joe.. > autorefresh, reconciliation engine, AIE > > On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza <jdso...@shyle.net>wrote: > >> ** >> >> You could add a few more to that jar that I can think at the top of my >> head... >> >> #15 Select appropriate Refresh Option for menus depending on their use >> (On Connect, On Open, 15 Minute Intervals). >> #16 Use Active Link or Filter Guides where possible. >> #17 Refresh your table fields only when necessary & use appropriate >> chunks sizes >> #18 Design Flashboard variables carefully. >> #19 Use Computed or Dynamic groups where possible... I’m guessing this >> does impact performance too?? >> >> I’m sure there are other performance related AR System related >> parameters.... Might be a good idea to compile a good list more relevant to >> our current versions.. >> >> Joe >> >> *From:* patrick zandi <remedy...@gmail.com> >> *Sent:* Wednesday, March 14, 2012 10:13 AM >> *Newsgroups:* public.remedy.arsystem.general >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Performance Tuning >> >> ** I am looking at a jar in front of me.. it says the following:: >> >> #1 use indexes appropriately >> #2 use efficient queries >> #3 consider using set field action in filters instead of AL >> #4 avoid using filters which perform run process to run a macros (old) >> ##5 stagger escalations times >> #6 use direct sql, $PROCESS$ sparingly >> #7 avoid sending notifications to too many addresses (hah!) >> #8 minimize the number of diary, and long charcter fields >> #9 avoid admin tool / migrator during peak hours. >> #10 keep your application design simple >> #11 implement MPSO (hah!) >> #12 Define carefully the number of fast and list servers. >> #13 allocate enough shared memory for the db. >> #14 provide adequate computer network resources. >> >> Most still apply ! >> >> >> On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue <sbar...@mitre.org> wrote: >> >>> ** >>> >>> I would be interested in that as well!**** >>> >>> **** >>> >>> Sue**** >>> >>> **** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of >>> America Account) >>> *Sent:* Wednesday, March 14, 2012 9:54 AM >>> *To:* arslist@ARSLIST.ORG >>> *Subject:* Performance Tuning**** >>> >>> **** >>> >>> ** **** >>> >>> Does anyone know where I can find a Performance Tuning guide or white >>> paper for the following AR System Server versions?**** >>> >>> **** >>> >>> 7.1 and 7.6.04.**** >>> >>> **** >>> >>> I have gone through the Optimizing and Troubleshooting Guide for both >>> versions but I thought there was a more detailed Performance Tuning guide >>> out there somewhere. I have gone through BMCs documentation for both >>> versions and have search the BMC Communities and have not found them >>> anywhere. Anyone have a like to these guides, I would really appreciate it >>> if you would provide it.**** >>> >>> **** >>> >>> Thanks.**** >>> >>> *Christopher Pruitt* >>> Business Consulting III **** >>> >>> *HP Enterprises Services >>> **christopher.pru...@hp.com >>> *www.hp.com **** >>> >>> **** >>> >>> **** >>> >>> *Confidentiality Notice:* This message and any files transmitted with >>> it are intended for the sole use of the entity or individual to whom it is >>> addressed, and may contain information that is confidential, privileged, >>> and exempt from disclosure under applicable law. If you are not the >>> intended addressee for this e-mail, you are hereby notified that any >>> copying, distribution, or dissemination of this e-mail is strictly >>> prohibited. If you have received this e-mail in error, please immediately >>> destroy, erase, or discard this message. Please notify the sender >>> immediately by return e-mail if you have received this e-mail by mistake. >>> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > -- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
