This is where Server Statistics are your friend, as you can watch the thread count growth over time to get an idea of peak thread counts, watch the growth, Identify times when more threads are needed (End of month List Count Jumping up for reports), etc. We found that when we moved from a Solaris 9 zone to a physical Linux server, our initial thread counts at startup was way too high, as the counts never really grew above the initial numbers, we set the start numbers lower without changing the max numbers and got much better performance.
About the destroying of threads, if I remember correctly, once a List/Fast/Escalation thread is created, it is not destroyed until a server restart (barring a thread crash) because of the cost of destroying the thread and then needing to recreate it later was greater than leaving it idle, Keep me honest here Doug Muller. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Steve Kallestad Sent: Wednesday, June 12, 2013 3:02 PM To: arslist@ARSLIST.ORG Subject: Re: How much RAM does an AR System thread use? ** I don't know the details of AR System threading, and I might be stepping a bit outside my bounds of knowledge but... I agree with Sean that the memory usage for a particular thread when spawned should be insignificant. The more threads are active on a given system, the more the OS needs to cycle through each thread to see if it is ready for processing. Modern CPUs are capable of managing multiple threads simultaneously, but the limit of how many can truly be processed at any given time is pretty small. When the limit is reached, the OS will iterate through the running threads based on priority. With the AR System, the number of threads that you have will increase performance up to the point where you hit the limit and start to see a diminished in performance because the CPU is spending more time selecting threads than processing them. That's a little bit simplistic and doesn't really account for blocking / interruption / IPC, but it's at least a simple understanding. The AR System separates it's types of configurable threads into a few different purposes - Fast / List / Admin / Private / etc. It's been quite some time since I've had to do thread configuration for performance purposes, but if you want to go beyond the basic recommendations it's more a matter of your traffic patterns than anything else. You want to have a balance between the number of idle threads and your end user's activity. Idle threads are created ahead of time so end users don't perceive a performance issue because new threads are being created. Thread logging will show you when threads are being created and when threads are destroyed because they are idle or when there's an unrecoverable error. If I'm not mistaken, Misi has a tool to analyze and make recommendations for thread counts. Sun used to produce numbers for how many threads an individual CPU could reasonably process. I don't think Intel ever put out those numbers and I'm not sure Sun does anymore. I honestly think this is a much lower priority issue these days than it once was. You could do some testing by looking at memory usage at startup for an arserver with various thread counts and run performance tests, but personally I don't look at optimizations like this unless I'm experiencing a problem or I'm going through a formal performance optimization cycle. There is always the strong possibility that your end user activity will change, and it will change from day to day and week to week. If you try to squeeze out every ounce of performance from a system at the end of the month when everybody is running reports, your configuration is going to look a lot different than if you tried to do the same thing on the 7th. I could be remembering wrong, but I think once upon a time the queues were processes and not threads (way back in the 90s). I could be thinking of apache httpd, but I think ars did the same thing. At that point optimization of queues was a much bigger deal. Just my two cents. Not sure that I added much to the discussion :). Steve On Wed, Jun 12, 2013 at 11:36 AM, Longwing, Lj <llongw...@usgs.gov<mailto:llongw...@usgs.gov>> wrote: ** I think the question was based on Remedy/Peregrine/BMC's long standing statement of "You don't want to allocate 'too many' threads, because each one comes with a memory/cpu cost, so your thread counts need to be a perfect balance to allow proper performance, but not utilize too many resources" So, from that standpoint, it's a fair question of "ok...what is the 'cost' of each thread so I can figure out if I have enough resources to handle the cost" On Wed, Jun 12, 2013 at 12:29 PM, Garrison, Sean (Norcross) <sean.garri...@fiserv.com<mailto:sean.garri...@fiserv.com>> wrote: ** It was my understanding it uses a shared pool of memory. Each thread probably uses a small almost insignificant amount except when large queries are run, etc. If it runs right you will see it double in memory during caching scenarios and go back down to ~1-3 gig. Sean From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org<mailto:arslist@arslist.org>] On Behalf Of Rick Cook Sent: Wednesday, June 12, 2013 1:44 PM To: arslist@arslist.org<mailto:arslist@arslist.org> Subject: Re: How much RAM does an AR System thread use? ** I meant how much does each thread allocate, not the entire AR Server. Rick On Jun 12, 2013 9:37 AM, "Sanford, Claire" <claire.sanf...@memorialhermann.org<mailto:claire.sanf...@memorialhermann.org>> wrote: ** Mine uses between 1 and 1.2 GB My other answer is totally off topic.... I saw this subject line and immediately this came to mine - How much wood would a woodchuck chuck if a woodchuck could chuck wood? ------------------------- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Wednesday, June 12, 2013 11:29 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: How much RAM does an AR System thread use? ** I remember hearing a number some years ago, but it probably has changed since then. Trying to balance hardware availability with resource requirements. Rick _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
