freebsd stable - Nov 2007 - Also seeing 2 x quad-core system slower that 2 x dual core

I think I also just came up against the same effect that the original poster
saw. I have two sets of machines here - one is a pair of dual core Xeons,
the other a pair of quad core Xeons. They are HP servers, more or less
identical apart from the processors I belive.

Both have 7.0-BETA3 installed, and the same config on them with the
same files.  I am trying to delete a gigabyte of files using 'rm -rf'

On the dual core processors this takes about 20 seconds. On the quad
cores it takes about 3 minutes! This is true for both the 32 and 64 bit
versions of FreeBSD :-(

-pcf.

> I think I also just came up against the same effect that the original
poster
> saw. I have two sets of machines here - one is a pair of dual core Xeons,
> the other a pair of quad core Xeons. They are HP servers, more or less
> identical apart from the processors I belive.
>
> Both have 7.0-BETA3 installed, and the same config on them with the
> same files.  I am trying to delete a gigabyte of files using 'rm
-rf'
>
> On the dual core processors this takes about 20 seconds. On the quad
> cores it takes about 3 minutes! This is true for both the 32 and 64 bit
> versions of FreeBSD :-(
ULE- or 4BSD-scheduler?

Bit OT: Are the servers DL360 or DL380 (G5)? I will upgrade a DL380
server from 6.2 to 7.0 (beta3) in order to gain some performance
tomorrow.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentlest gamester is the soonest winner.

Shakespeare

> ULE- or 4BSD-scheduler?
4BSD - am just running GENERIC on both system. Should I try ULE?
> Bit OT: Are the servers DL360 or DL380 (G5)? I will upgrade a DL380
> server from 6.2 to 7.0 (beta3) in order to gain some performance
> tomorrow.
Both the old and new are DL360 G5 according the the iLo. Let us know
how the upgrade goes.

-pete.

On Thursday 29 November 2007, Pete French wrote:
> I think I also just came up against the same effect that the original
> poster saw. I have two sets of machines here - one is a pair of dual
> core Xeons, the other a pair of quad core Xeons. They are HP servers,
> more or less identical apart from the processors I belive.
>
> Both have 7.0-BETA3 installed, and the same config on them with the
> same files.  I am trying to delete a gigabyte of files using 'rm
-rf'
>
> On the dual core processors this takes about 20 seconds. On the quad
> cores it takes about 3 minutes! This is true for both the 32 and 64 bit
> versions of FreeBSD :-(
Can you provide more details on this task?  It seems like something that 
could easily be reproduced in a lab environment and serve as a regression 
test and baseline for future improvements.  Is the server doing any other 
work while doing the rm, or is this it?  What kind of directory layout 
are we looking at?  How many files, directories, users ...?  What type of 
filesystem, options, size?

BTW, what's your nsswitch.conf like?  If you don't need nis, removing it
can mean a considerable speed improvement - or try nscd(8).

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20071129/2336c65f/attachment.pgp

Pete French wrote:
> I think I also just came up against the same effect that the original
poster
> saw. I have two sets of machines here - one is a pair of dual core Xeons,
> the other a pair of quad core Xeons. They are HP servers, more or less
> identical apart from the processors I belive.
> 
> Both have 7.0-BETA3 installed, and the same config on them with the
> same files.  I am trying to delete a gigabyte of files using 'rm
-rf'
> 
> On the dual core processors this takes about 20 seconds. On the quad
> cores it takes about 3 minutes! This is true for both the 32 and 64 bit
> versions of FreeBSD :-(
That almost certainly has nothing to do with how many CPUs your system 
has, since rm -rf is a single process running on a single core.

Kris

Just as a followup to this - I soent some time going through all
the suggestions and advice that people gave me regarding this problem.
It turns out that the newer servers shipped by HP have different cache
settings to the older ones on their RAID controllers, plus I get very
different results from my benchmarks depending on how long the machines
have been booted for and what activity has occurred on them (probably due to
things ending up in cache).

Upshot - if the machines are configured identically, and an identical install
is made and an identical test doen then we get identical performance as
expected.

Part of the reason for posting this though is that a lot of people have bbeen
worrying about 8x CPU performance, and this thread won't have helped. So
I wanted to say that now I am convinced that (for my workload) these machines
are fine. To the point where I have installed 7.0-BETA4 on the ten new
8 core servers for a very large load on th webfarm this morning. I'm pleased
toio say that it went off perfectly, the servers took the load and we had
no problems at all. We are running CGI scripts against mySQL under apache22
basically - which is a pretty common thing to do. Ia m using ULE and tthe
amd64 version of the OS.

7.0 is excellent as far as I am concerned, and I don't think people
should be worried about deploying it on 8 core machines. My experinec
has been that it is fine and is also somewhat faster than 6.3 on the same
hardware.

-pete.

Andreas Pettersson wrote:
> Claus Guttesen wrote:
>> could either replace my 10K rpm drives (in raid 1+0) with 15K ditto
>> which would require a downtime which we could not afford at this tim
> 
> I have several times successfully upgraded mirrored volumes with new 
> disks without any downtime at all. Just change one disk, let the mirror 
> rebuild, change the other disk, wait for rebuild again, tell the logical 
> drive to present all the new space and then extend the filesystem. No 
> downtime.
Just an additional hint: Before you start doing this procedure, in order 
to minimize risk you may want to do a verification/repair run over the 
original mirror (if your controller supports this) to make sure that 
both disks are in sync and there are no defective sectors on the disk 
you are subsequently copying the data from.  Otherwise there could be 
some rude awakening ...

Regards,

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org  |  http://www.escapebox.net