Disruptive? Not unless you go crazy with it. If you want to know the thread utilization for a given queue (e.g., Fast, List, etc.) you will need the individual queues. It's going to be hard to tune a queue if you don't know the numbers for that queue. If you are only tuning the thread counts, a 1 hour interval should be more than sufficient. The server stats data is recorded in a form name Server Statistics.
Axton Grams On Mon, Apr 2, 2012 at 11:29 AM, Goodall, Andrew C <[email protected]> wrote: > ** > > Thanks so much for all this input Axton.**** > > Great info.**** > > ** ** > > Question regarding turning on the Server statistics recording…**** > > ** ** > > **1. **Is it disruptive ? wondering whether I can turn on in prod > for a short time to get a true load picture during peak time.**** > > **2. **Do I need cumulative and individual queue mode or just > cumulative**** > > **3. **What’s a good recording interval?**** > > **4. **I assume it saves the data to a .log in BMC > Software\ARSystem\Arserver\Db location**** > > ** ** > > This all started because we’ve been having performance issues on 7.5 and > we’re upgrading to 7.6.04 with all new hardware (Windows x64 Quad CPU / > Quad core 2.6 GHz – 12GB Ram VMs)**** > > We use full ITSM suite (mainly incident, problem, change, SRM, RKM)**** > > Between 300 – 400 concurrent users**** > > ** ** > > In recent doc from Performance and Scalability White Paper from BMC - > http://documents.bmc.com/supportu/documents/97/70/249770/249770.pdf**** > > They use a 2 CPU Quad Core Windows x64 (page 10/77) 8 total cores and set > threads (page 48/77) List = 24 and Fast = 40**** > > ** ** > > ** ** > > Regards,**** > > **** > > *Andrew Goodall***** > > Software Engineer 2 | Development Services | jcpenney . www.jcp.com > <http://www.jcp.com/>| > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Monday, April 02, 2012 11:12 AM > *To:* [email protected] > *Subject:* Re: fast and list threads - by cores or cpus? - documentation > conflicts.**** > > ** ** > > ** To add to that, the goals of setting the queue thread settings should > only include:**** > > - you don't want the min thread count too high**** > > - you don't want the max thread count too low**** > > - you don't want the max thread count too high > > Getting the mix right will ensure that there are sufficient threads to > handle the workload. Having too many threads is bad and will result in > excessive overhead within the kernel and the database (each thread creates > a connection to the database server). Having too few threads (without the > ability to increase the ceiling) is bad and will result in performance > problems or timeouts.**** > > ** ** > > There are no options to adjust how Remedy dispatches work to the threads > available or to alter how Remedy breaks up the work when handling. It > either has sufficient threads to do what it needs to do, or it does not. > Giving the process more threads than it will use will not increase the > performance of the application, it will just add work during cache > operations, create more db connections, and add overhead to the OS in > managing all those threads.**** > > ** ** > > Probably equally important to getting the thread configuration right, is > moving certain subsystems to separate queues. Things like email, approval, > reconciliation, etc. should be moved to separate queues. By doing this, > you can leave the fast and list queues available for user requests. This > makes managing the threads (by you) much easier because you don't have many > subsystems competing for a limited pool of threads. Instead you have known > subsystems using private queues that are all theirs and you have queues > available to end users that are all theirs.**** > > ** ** > > Axton Grams**** > > On Mon, Apr 2, 2012 at 10:57 AM, Axton <[email protected]> wrote:**** > > Can 2 cores execute 2 threads of execution in parallel? If so, why would > you not want to leverage that capability? I would not suggest putting your > min threads to the max value expected. Start low, say 1. Creating more > threads than are needed adds overhead, esp. during cache operations. > Remedy will create a new thread when all threads are busy and another > request is in the queue. Set the max to the target of what you think you > might need. With this approach, Remedy will allocate what it needs.**** > > ** ** > > There is no formula that will magically tell you the ideal number of > threads that you need for your system. Two people can write an application > where both applications provide a comparable set of capabilities. > Depending on how the workflow is written, different thread requirements > will be needed.**** > > ** ** > > Thread to parallel execution ratio is not the best way to measure things. > An execution path, while only capable of handling one instruction at a > time, can effectively handle more than one thread of execution by > performing a context switch. While context switching does cost some > overhead, it may in fact enable the server to handle a larger concurrency > or provide a higher throughput of operations. That's not to say that in > your case, 4 threads per execution path, is the best scenario, but it might > be.**** > > ** ** > > The server statistics, coupled with OS statistics, are your best indicator > of whether or not you have allocated the appropriate number of threads. > It's a game of trial and error until you find the right fit for your > environment. To start, set the min threads to 1 for all queues (except > escalation, if you use escalation pools) and the max to some nominal > number, like 10. If you start to see queu blocked counts in the server > statistics, increase the max for that queue. If you do not see queue > blocked counts, you have enough threads to handle the load the system is > experiencing. Check the thread count for each queue after a period of > time. If the number of threads never reaches the max threads allowed for > that queue, your max is too high. Once you figure where the thread count > hovers, set the minimum to match that number. Continue to monitor for > queue blocked items, and increase the max as needed.**** > > ** ** > > Axton Grams**** > > ** ** > > On Mon, Apr 2, 2012 at 10:32 AM, LJ LongWing <[email protected]> > wrote:**** > > ** **** > > Andrew,**** > > I think you should go with 16. I know that a quad core is not the same > thing as 4 CPU’s….BUT…it is for most practical purposes…I believe the terms > core and cpu are used loosely to mean the same thing these days when > referring to CPU power….it’s my understanding that to make a quad core cpu, > they shrunk the technology of a single core to be able to fit 4 dies on the > same chip….so while you are more constrained on bus because you are all on > one chip…your processing power should be better than a single core on a > single cpu….**** > > **** > > I know I’m going to get a lot of flack for my loose and probably improper > usage of terms….but that’s roughly how I think of it J**** > > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Goodall, Andrew C > *Sent:* Thursday, March 22, 2012 5:57 PM > *To:* [email protected] > *Subject:* fast and list threads - by cores or cpus? - documentation > conflicts.**** > > **** > > ** **** > > I’m confused – the doc seems to conflict and BMC architects have signed > off on our ar.cfg settings in the past in which they were set by CPU and > not by Cores.**** > > **** > > My previous understanding was that these values should be set by the > number of CPUs and not Cores, in fact BMC architects have signed off on > these settings many times – and if you look at “BMC Remedy AR System > Server 7.6 – Performance Tuning” page 33 – it states CPUs**** > > **** > > However, in the recent publication for performance and scalability > “Performance and Scalability White Paper” released this month – see page 4 > and 48 – this was set at the number of total cores.**** > > **** > > So – we have a Quad CPU 2.2 GHz Quad Core AMD with 12GB ram Windows box.* > *** > > **** > > So should I use x4 or x16 = a huge difference in the number of threads, > which could substantially impact performance.**** > > **** > > **** > > See:**** > > **** > > “Performance and Scalability White Paper” page 4 and 48 - > http://documents.bmc.com/supportu/documents/97/70/249770/249770.pdf**** > > **** > > “BMC Remedy AR System Server 7.6 – Performance Tuning” page 33 - > http://documents.bmc.com/supportu/documents/90/37/199037/199037.pdf**** > > **** > > **** > > Regards,**** > > **** > > *Andrew Goodall***** > > Software Engineer 2 | Development Services | jcpenney . www.jcp.com > <http://www.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"_**** > > ** ** > > ** ** > > _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"
