Обсуждение: Pg on SMP half-powered
Hello, hackers! I am running postgresql 7.1 on a SMP Linux box. It runs, but it never pass a loadavg of 0.4, no matter how I try to overload the system. The same configuration, the same executable, the same test on a non-SMP machine gives a loadavg of 19. That means that a Xeon SMP box with 1Gb of RAM goes slowlier than a weak CPU, with the same postgres, the same configuration, and the same test. Anybody knows what is happening? Is there something to do on a SMP machine for it to run? I tried with lots of shared memory, and with "commit_delay=0", but nothing worked. Yours:
What is the postgres process doing? what does iostat show for disk I/O?
from reading this, you are comparing apples->oranges ... are the drives
the same on the non-SMP as the SMP? amount of RAM? speed of CPUs? hard
drive controllers with same amount of cache on them? etc, etc, etc ...
On Thu, 5 Jul 2001, [iso-8859-1] V�ctor Romero wrote:
>
>
> Hello, hackers!
>
>
> I am running postgresql 7.1 on a SMP Linux box. It runs, but it never pass a
> loadavg of 0.4, no matter how I try to overload the system.
>
> The same configuration, the same executable, the same test on a non-SMP
> machine gives a loadavg of 19.
>
> That means that a Xeon SMP box with 1Gb of RAM goes slowlier than a weak
> CPU, with the same postgres, the same configuration, and the same test.
>
> Anybody knows what is happening? Is there something to do on a SMP machine
> for it to run? I tried with lots of shared memory, and with "commit_delay=0",
> but nothing worked.
>
> Yours:
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
El Jueves 05 Julio 2001 19:34, The Hermit Hacker escribió:
> What is the postgres process doing? what does iostat show for disk I/O?
> from reading this, you are comparing apples->oranges ... are the drives
> the same on the non-SMP as the SMP? amount of RAM? speed of CPUs? hard
> drive controllers with same amount of cache on them? etc, etc, etc ...
The postgres is doing inserts, but it does not matter. Other tests and
benchs do the same weird results. All the process stay the most of the time
sleeping.
The disk of the non-SMP is a cheap IDE. The disk of the SMP is a SCSI-2
disk. Bonnie and other benchs give to the SMP machine better results (that is
evident). Thay is what does strange that postgres run fater on the non-SMP
machine.
(about comparing apples with oranges) Yes, I know. More exactly, I am
comparing a F-1 car with a bike, bike run faster, and I ask on the F-1
experts mailing list why.
RAM: 1Gb on the SMP machine. 128Mb on the non-SMP machine.
Speed: 400MHz on the non-SMP machine. 550 on the SMP one.
The SMP machine is far away better than the non-SMP one. Same OS,
same distro, same Postgres, same test, and a cheap non-SMP machine
outperforms a very expensive HP SMP server. It looks a interblocking stuff,
due to all the postmasters are sleeping but one, meanwhile on the non-SMP
they runs concurently. Does anybody knows what is happening?
Yours:
On 06 Jul 2001 10:52:33 +0200, Víctor Romero wrote:
> (about comparing apples with oranges) Yes, I know. More exactly, I am
> comparing a F-1 car with a bike, bike run faster, and I ask on the F-1
> experts mailing list why.
>
> RAM: 1Gb on the SMP machine. 128Mb on the non-SMP machine.
>
> Speed: 400MHz on the non-SMP machine. 550 on the SMP one.
>
> The SMP machine is far away better than the non-SMP one. Same OS,
> same distro, same Postgres, same test, and a cheap non-SMP machine
> outperforms a very expensive HP SMP server. It looks a interblocking stuff,
> due to all the postmasters are sleeping but one, meanwhile on the non-SMP
> they runs concurently. Does anybody knows what is happening?
>
>
> Yours:
What kernel version? 2.4.x has had problems with mtrr on SMP Xeon
systems and we had to upgrade to 2.2.19 to get 2.2.x to use the L2 cache
on newer Xeon CPU's. The default redhat kernel had no idea what they
were, according to our sysadmin here and they ended up running with L2
cahce disabled. And then we ran into problems with bigmem with RedHat's
2.2.19 upgrade and decided that the better route was to complile our own
, ensuring all of your hardware gets explicitly supported properly.
--
Colin M Strickland perl -e'print "\n",map{chr(ord()-3)}(reverse split
//,"\015%vhlwlqxpprF#ir#uhzrS#hkw#jqlvvhqudK%#\015\015nx".
"1rf1wilv1zzz22=swwk###369<#84<#:44#77.={di##339<#84<#:44#77.=ohw\015]".
"K9#4VE#/ORWVLUE#/whhuwV#dlurwflY#334#/wilV\015uhsrohyhG#ehZ#urlqhV");'
On Thursday 05 July 2001 10:51, Víctor Romero wrote: > I am running postgresql 7.1 on a SMP Linux box. It runs, but it never pass > a loadavg of 0.4, no matter how I try to overload the system. > The same configuration, the same executable, the same test on a non-SMP > machine gives a loadavg of 19. Sounds like a kernel issue. However, the load average numbers alone are not enough information to get a benchmark. You need to benchmark using a benchmark that can generate enough traffic to load both machines and get good time results for the run of the standard benchmark queries. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
El Sábado 07 Julio 2001 16:36, Lamar Owen escribió: > On Thursday 05 July 2001 10:51, Víctor Romero wrote: > > I am running postgresql 7.1 on a SMP Linux box. It runs, but it never > > pass a loadavg of 0.4, no matter how I try to overload the system. > > > > The same configuration, the same executable, the same test on a non-SMP > > machine gives a loadavg of 19. > > Sounds like a kernel issue. > > However, the load average numbers alone are not enough information to get a > benchmark. You need to benchmark using a benchmark that can generate > enough traffic to load both machines and get good time results for the run > of the standard benchmark queries. Now Im at home... as soon as I get office again Ill send you the little script benchs I wrote, I think them genetares enoughtraffic because if I throw more than 400 threads the postmaster start to fail...