Re: pg 8.1.3, AIX, huge box, painfully slow.

Gavin,

On 4/7/06 3:27 PM, "Gavin Hamill" <gdh(at)laterooms(dot)com> wrote:

> 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) = 0
> 155712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) = 0
> 278774: __semop(15728649, 0x0FFFFFFFFFFF6F10, 1)
> 114914: __semop(15728649, 0x0FFFFFFFFFFF6A40, 1) = 0 = 0
> 114914: __semop(15728650, 0x0FFFFFFFFFFF61E0, 1)
> 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0
> 155712: __semop(15728650, 0x0FFFFFFFFFFF6890, 1) = 0 1
> 55712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1)
> 278774: __semop(15728650, 0x0FFFFFFFFFFF6F10, 1)
> 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0
> 278774: __semop(15728649, 0x0FFFFFFFFFFF7E40, 1)
> 114914: __semop(15728649, 0x0FFFFFFFFFFF6A80, 1) = 0 = 0
> 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1)

Seems like you're hitting a very small target in RAM with these semop calls.
I wonder what part of the code is doing this - Tom would know better how to
trace it, but the equivalent of oprofile output would be nice.

The other thing that I'd like to see is an evaluation of the memory access
latency of this machine from Register to RAM. I couldn't find a
benchmarking tool that was UNIX friendly out there, maybe I'll write one
real quick. I suspect this machine has a heinous latency and a storm of
semops to the same spot of RAM might be a far worse performance problem on
this machine than on others...

- Luke