Fwiw, I am on a windows platform. Rick On Jun 12, 2013 12:47 PM, "Steve Kallestad" <st...@tabtonic.com> wrote:
> ** > 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_ >> > > _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"
