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"_ >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
