RE: Stress my CPU's

From: Baumgartel, Paul <>
Date: Tue, 17 Nov 2009 13:08:43 -0500
Message-ID: <>

I have also found that a script along the lines of  


does a pretty good job of CPU consumption.  

Paul Baumgartel
Information Technology
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
Phone 212.538.1143  

[] On Behalf Of

	Sent: Tuesday, November 17, 2009 11:04 AM
	Subject: Re: Stress my CPU's
	Not a database-generated CPU stress, but I find that gzip /
gunzip really suck up CPU. Sometimes I launch 8 parallel gzip sessions and bring the 8 CPUs on one of our newer servers to near 100% utilization each.         

        Write a little script that spawns 16 gzip -9 processes, then gunzips, then gzips on some multi-GB sized files. Since the CPUs won't care how they're stressed - database or otherwise - you might get the results you want.         

	Jack C. Applewhite - Database Administrator
	Austin I.S.D. - MIS Department
	512.414.9715 (wk)  /  512.935.5929 (pager)
From: 	"Robertson Lee - lerobe" <> 
To: 	<> 
Date: 	11/17/2009 09:40 AM 
Subject: 	Stress my CPU's 
Sent by:

Hi, Oracle AIX 6.1 I have been asked to do some stress testing and it is causing me
stress ;-)           

        I need to really hammer the CPU's on the box as we want to test dynamically allocating CPU's from another partition to handle the increased workload.           

        I am having difficulty getting the CPU's maxed out or indeed to even use more than 2.           

        I have been running cartesian joins with various hints (parellism, using hashes etc) but just cannot get the relevant amount of work generated. It tends to spike at about 80% on a couple of CPU's then the result set comes back after about 30 secs and CPU useage then obviously drops. This is a T & D server with 16 CPU's on it. Are there any clever tricks out there I can use to simulate a full on workload??           

        TIA                    Lee                             

 Please access the attached hyperlink for an important electronic communications disclaimer:
Received on Tue Nov 17 2009 - 12:08:43 CST

Original text of this message