I think you're right Paul, now that you mention it. Forgive me - it really has been a long time. I could have sworn there was a MaxIdleThreads parameter, but I just looked at two environments and neither has a setting.
On Wed, Jun 12, 2013 at 12:20 PM, Longwing, Lj <llongw...@usgs.gov> wrote: > ** > Paul, > Your understanding regarding killing is the same as mine...but Doug is > always welcome to weigh in on anything he feels like doing so :) > > > On Wed, Jun 12, 2013 at 1:18 PM, Campbell, Paul (Paul) <p...@avaya.com>wrote: > >> ** >> >> 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> >> 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> 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] *On Behalf Of *Rick Cook >> *Sent:* Wednesday, June 12, 2013 1:44 PM >> *To:* 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> 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 <arslist@ARSLIST.ORG>] On Behalf Of Rick Cook* >> *** >> >> Sent: Wednesday, June 12, 2013 11:29 AM**** >> >> To: 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_ **** >> _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"
