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 <[email protected]> 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) < > [email protected]> 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: >> [email protected]] *On Behalf Of *Rick Cook >> *Sent:* Wednesday, June 12, 2013 1:44 PM >> *To:* [email protected] >> *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" < >> [email protected]> 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:[email protected] <[email protected]>] On Behalf Of Rick Cook* >> *** >> >> Sent: Wednesday, June 12, 2013 11:29 AM**** >> >> To: [email protected]**** >> >> 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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
