Scott Marlowe <scott.marlowe@gmail.com> wrote:
> FYI, on an 8 or 16 core machine, 10k to 30k context switches per
> second aren't that much.
Yeah, on our 16 core machines under heavy load we hover around 30k.
He was around 50k, which is why I said it looked like it was
"becoming a problem."
> If you're climbing past 100k you might want to look out.
We hit that at one point; cutting our connection pool size brought
it down and improved performance dramatically. I don't think I'd
wait for 100k to address it next time.
> The more I read up on the 74xx CPUs and look at the numbers here
> the more I think it's just that this machine has X bandwidth and
> it's using it all up. You could put 1,000 cores in it, and it
> wouldn't go any faster. My guess is that a 4x6 core AMD machine
> or even a 2x6 Nehalem would be much faster at this job. Only way
> to tell is to run something like the stream benchmark and see how
> it scales, memory-wise, as you add cores to the benchmark.
I haven't been keeping up on the hardware, so I defer to you on
that. It certainly seems like it would fit with the symptoms. On
the other hand, I haven't seen anything yet to convince me that it
*couldn't* be a client-side or network bottleneck, or the sort of
lock contention bottleneck that showed up in some of Sun's
benchmarks. If it were my problem, I'd be trying to rule out
whichever one of those could be tested most easily, iteratively.
Also, as you suggested, identifying what queries are taking most of
the time and trying to optimize them is a route that might help,
regardless.
-Kevin
