Re: "CPU Mask" on E6500

Ralph wrote:

> Hi All
>
> We are running oracle 8.1.7.3 EE on a veritas cluster of two E6500
> (Solaris 7 14cpu + 14gb ram).
>
> After starting a statistical analysis of library cache latch
> contention and cpu utilisation against "work done" by call centres, it
> became apparent that we were suffering increased CPU utilization (15 -
> 20%) and latch contention (not sure about the order) on box A over box
> B.
>
> The two boxes are meant to be identical. When our unix guy ran some
> diagnostics on each box and compared them he discovered that two of
> the cpus on box A had incorrect CPU mask settings. After speaking to
> sun engineer it appears that this setting is incorrect though he
> couldn't say whether correcting it would fix our cpu utilisation
> issue.
>
> Can anybody shed any light on this? Nobody seems to be in much of a
> hurry to sort it and it's playing havoc with out capacity forecasts!
>
>
> Cheers
> Ralph
>

Hi Ralph

I have seen similar thing on a benchmark setup with 5 identical 6500, 12 cpu and 12 Gb memory, used as front end to a fully equipped E10000. On running tests, the E6500's had the same (heavy) workload. They were accessed in a round robin fashion. But one system suffered ~25% less latch contention than the other four. Beats me, the were (on paper) identical! Sun's benchmark engineer claimed the were identical, but they were not performing alike. We then opened the boxes and the see, one had twice the number of ram (or DIM) modules, each module half size. I think it was 128 Mb and 256 Mb modules. The one with more modules had less contention. It has something to do with the recovery time on each write in a memory chunk. More modules => less chance of cpu waiting for elapsing recovery time. Remember the cpu clock is much faster then the memory access time. Spread the memory access on more modules => less contention.
Elas - equip your servers with as many memory modules as they can carry. Choose a module size to fit your total memory needs using all memory slots.

rgds

/Svend Received on Tue Oct 22 2002 - 16:08:38 CDT