Many thanks for that. It was interesting to see how the one "working" server coped with the load this morning. Typically around 600 users per server, the load was all directed to one .... and while it slowed down, it didn't slow down by that much (opening an incident went from 7 secs to about 12). I think that our current configuration (aside from the 7.1.0 thread changes) is probably sufficient.
Some of our users would question current application performance, but complaining about systems is what keeps them happy. Regards Dave On 4 November 2013 15:11, LJ LongWing <lj.longw...@gmail.com> wrote: > ** > Dave, > My understanding was 3X for Fast, 5X for List...BOTH are MAX > values...neither are Min values. The idea is that it's a 'calculated' > maximum for your hardware for optimum performance. What the minimum should > be is entirely up to your system. If your system is working will with 6 > min and 35/45 max respective...that's good. I personally like to set the > min to somewhere around 2, then 'let the system run' and see where the > thread counts are at in general, and adjust my min's appropriately. > > The idea behind having a min/max is that starting a thread takes time, so > you don't necessarily want to be waiting for that thread to start during > load...so you want your min to be high enough to handle your 'standard' > configuration, but not so high as to have wasted resources. I have always > considered the max to be a 'to handle overflow' type of setting...you want > to allow your system to grow within certain parameters, but not unlimited. > > > On Mon, Nov 4, 2013 at 7:55 AM, Dave Barber <daddy.bar...@gmail.com>wrote: > >> ** >> All, >> >> We've just run through an upgrade on a server group from 7.0.1 to 7.1.0 >> (latest patch of each). >> >> The "primary" upgrade ran fine. Secondary seemed to run through fine as >> well, until users started logging on this morning, when it went .... slow. >> >> Turns out that the 7.1.0 installer amended the thread configuration on >> the secondary. >> >> Previous : >> Private-RPC-Socket: 390601 1 15 >> Private-RPC-Socket: 390620 6 35 >> Private-RPC-Socket: 390625 1 40 >> Private-RPC-Socket: 390635 6 45 >> >> New : >> Private-RPC-Socket: 390601 1 15 >> Private-RPC-Socket: 390620 6 35 >> Private-RPC-Socket: 390625 1 40 >> Private-RPC-Socket: 390635 6 45 >> Private-RPC-Socket: 390620 2 2 >> Private-RPC-Socket: 390635 2 2 >> >> 390620 and 390635 were effectively replaced. Turns out the same thing >> happened on our test server group environment, but we never had more than a >> couple of users to check on performance. Commented out the two new lines >> and performance returned to normal. >> >> Our production servers are running solaris, and both are running 32 >> cores. Which - according to the old theory - means that our thread config >> is still incorrect. Does the min=3xCPUs, max=5xCPUs still count for much? >> Is the calculation based on nn x Number of cores or nn x number of CPUs? >> >> Regards >> >> Dave Barber >> >> _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"
