Stress testing the T2000 running Sun's Application Server
By John Clingan-Oracle on Nov 02, 2006
Sigh. Sorry folks. I'm dangerously close to adding myself to my own non-blogging heathen list. Not only have I been sacrificing my blog for the sake of time, I've sacrificed reading other blogs as well My regular-blogging schedule is completely out of whack.
I had the privilege last week of stress testing a T2000 with a boatload of zones running Sun's Application Server. Ya know, I never knew about the stress-transfer capabilities of running a stress test. The last couple of weeks have been a bit more stressful due to a shortage of sleep, and running the stress test was more effective than Tylenol. I found inexplicable pleasure in nearly pounding a server into submission. I envy BMSeer
It sure took quite a bit of work to pound the server into submission. We threw more and more servers running JMeter at the poor T2000, and it kept chewing through them. I'm not going to post results as this was customer & application specific. Plus, more formal testing will be done later. We simply wanted to get an idea if we were heading in the right direction.
I can say that we were RAM, CPU and disk constrained Note, it was not a top-end T2000. The CPUs were 100% busy with runnable threads growing over time but with good response time. According to iostat, the mirrored volume was hitting ~250 IOPS (95+% writes) and %60 busy. I should have run iosnoop, but I'm pretty sure most writes were log file writes. The (memory) scan rate was consistent. It wanted RAM but managed to stay sane. The few really big spikes were due to me running scripts to - oddly enough - free up memory. The server was pretty much "comfortably numb" when we stopped - it had some headroom left.
Were we headed in the right direction? Absolutely! Plus, we were running out of servers to generate load