Re: about virtual processors

Greg wrote: > > Art - > > I can't tell you how giggly I am that you seem to be coming around to my > long held assertion that the "conventional wisom" of: NUMCPUVPS = > realCPUs-1 (or so) ain't necessarily so.....could it be your switch to > Sun/Solaris that's changing your mind?? Most of my (admittedly limited) > testing along this line has been Solaris based. > > Have you really *empirically* observed 2 CPUVP's on a 2 CPU machine > producing less throughput than 1 CPUVP on a 2 CPU machine?? Even on > Solaris?? I still can't imagine that the overhead could be that > great.... Hi Greg. It is not Solaris so much as having FAST CPUs. I have seen that on a system with only 2CPUs of speeds up to 150MHZ that there is no significant gain from more CPU VPs then nCPU-1. On our DGs which use 32 50MHZ M88100 processors we actually get best performance using only 28 CPU VPs with the first four CPUs masked off for root processes only so that system services do not suffer. Adding more than 28 CPU VPs gained us nothing at all and the 28 VPs we have are capable of nailing all 28 CPUs to 100% utilization. On the Suns, however, with 20 330MHZ CPUs and 20 CPU VPs, we have not seen more than ~66% CPU Utilization. Part of that is that we have discovered that Solaris still maintained the 10ms timeslicing built into System V.4 way back when a fast CPU was 10MHZ. Our ticker machines were not able to push the machines past 66% utilization either and that with straight filesystem I/O and millions of ticker transactions per hour. We brought that to Sun and they came back with a new kernel tunable to adjust the timeslice. Setting the timeslice to 1ms allowed the ticker machines to push the CPUs beyond 95% utilization and improved throughput 30% (as expected). On our database Sun machines we have made the same change and added an additional 10 CPU VPs but, truth is, I just do not have enough transactions to stress those two machines any further (they can each handle our entire News load at 60% utilization). The point is that I believe that for CPUS faster than 300MHZ, and perhaps to some extent >200MHZ but I cannot test, the overhead issue becomes moot since the CPUs are so fast that I/O wait time, even with FAST disk farms (multiple EMC2 16 pair RAID1+0 arrays), is sufficient to ALWAYS make cycles available to run additional tasks. On slower CPUs this is only true if the I/O subsystems are relatively slow. Art S. Kagel