April 2012

Jeremy Schneider

Ages ago I blogged about the Intel topology tool and mapping Xeon 5500 (Nehalem EP) processor threads to OS CPUs on Linux. I don’t recall if I ever blogged the same about Xeon 5600 (Westmere EP) but I’ll cover that processor and Xeon E5-2600 in this short post.  Fist, Xeon 5600.

The following two screen shots are socket 0 and socket 1 from a Xeon 5600 server. Socket 0 first:

Now, socket 1:

May 4th: some updates after discussion with Jeff Holt, Cary Millsap and Ron Christo of Method-R.

There’s all the documentation, and there all the terrific blogs about performance and Oracle wait events. But if you more or less start with this stuff, or encounter a wait event that is not (extensive enough) documented, or an event turns up and gives a response time you don’t expect, you need to understand what that wait event means. If you don’t know, it’s easy to get stuck at this point.

If you are familiar with waits, and just want to dig further, progress to “Get to know wait events”, if you want to get up speed with waits, read on.

What is a wait event?

This is the definition of the performance tuning guide in the Oracle documentation:

I am often working on systems with large number of LUNs, going into the hundreds. Trying to keep track is difficult at best. Sometimes though you might want to limit yourself to a specific number of disks-I knew about the dskfilt option in collectl but only today learned about a similar feature in nmon. The following is a very greatly simplified example of course, but it gives you the idea.

Assume you are interested in 4 disks-sd{a,b,c,d}. Let’s further assume that your disks are used for 2 ASM disk groups, DATA and RECO. You could create a file “disks.dat” with the following contents:

DATA sda sdb
RECO sdc sdd

Then pass that file to nmon with the -g flag. When you type “g” now, you are shown IO stats for those disks.