Steven Hartland wrote:
> sysctl -a |grep dirhash
>
> Check vfs.ufs.dirhash_mem is not close to vfs.ufs.dirhash_maxmem if it is
> and only most used boxes this seems to be the case increase maxmem.
>
> Seems this could either do with an auto tune option or a larger max by
> default in today
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
On Fri, Dec 07, 2007 at 12:39:22PM +, Pete French wrote:
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
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 m
> What settings are there on the cache? I have a DL 380 G5 with 2 x
The RAID cards on the original machines came with the cache configured
as 50/50 read/write split. The new ones came configured 25/75 read/write
splitl. Having set them all to 50/50 using the Smart Start CD then I now
get iidentica
> 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 re
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
On Fri, Nov 30, 2007 at 05:59:26AM +0100, Claus Guttesen wrote:
> > Thing is that GENERIC as installed out of the box should not take two
> > minutes
> > to delete a gig of files off a 15k RPM SAS drive! especially not
> > when identical hardware with half the number of processor cores only takes
Ivan Voras wrote:
Kris Kennaway wrote:
Check dmesg for the APIC numbers corresponding to the CPUs you want to
disable and add the corresponding entries to /boot/loader.conf, e.g.:
hint.lapic.1.disable="1"
hint.lapic.3.disable="1"
hint.lapic.5.disable="1"
hint.lapic.7.disable="1"
Hi,
Do you
Pete French wrote:
Well, the "1" is a boolean so those values will probably also work, but
the point was to disable apics 1,3,5 and 7 on the left hand side :) In
your case those are also valid but sometimes they are other numbers.
yes, I worked that out about 5 minutes after posting and makin
> Well, the "1" is a boolean so those values will probably also work, but
> the point was to disable apics 1,3,5 and 7 on the left hand side :) In
> your case those are also valid but sometimes they are other numbers.
yes, I worked that out about 5 minutes after posting and making myself
look f
On Fri, 2007-11-30 at 09:44 -0500, Jim Pingle wrote:
> This may be a silly question, but have you tried reducing the RAM on the
> quad core machine to 4GB so the machines match in that respect as well?
>
> I seem to recall a thread a while back about someone who had slowdowns in a
> certain situat
Pete French wrote:
Yes, if the claim is that the hardware is absolutely identical apart
from one having two quad-core CPUs instead of two dual-core, the next
step is to disable half of the CPUs and confirm that the problem goes away.
Just comming back to this today, will do a side by side comp
Kris Kennaway wrote:
> Check dmesg for the APIC numbers corresponding to the CPUs you want to
> disable and add the corresponding entries to /boot/loader.conf, e.g.:
>
> hint.lapic.1.disable="1"
> hint.lapic.3.disable="1"
> hint.lapic.5.disable="1"
> hint.lapic.7.disable="1"
Hi,
Do you know how
> > Yes, if the claim is that the hardware is absolutely identical apart
> > from one having two quad-core CPUs instead of two dual-core, the next
> > step is to disable half of the CPUs and confirm that the problem goes away.
>
> Just comming back to this today, will do a side by side compare of t
Pete French wrote:
>> Have you checked that your dir hash isn't suffering due to lack of memory
>> this can have a marked impact on seemingly trivial things like this as
>> could silly things like the RAID card being installed in a different slot.
>
> RAID card is onboard on these things - how wou
At 07:10 AM 11/30/2007, Pete French wrote:
> Check dmesg for the APIC numbers corresponding to the CPUs you want to
> disable and add the corresponding entries to /boot/loader.conf, e.g.:
O.K., I did that, got it running on 4 CPU's only, and the problem
is still there - so it's not the number of
On Fri, November 30, 2007 13:10, Pete French wrote:
>> Check dmesg for the APIC numbers corresponding to the CPUs you want to
>> disable and add the corresponding entries to /boot/loader.conf, e.g.:
>
> O.K., I did that, got it running on 4 CPU's only, and the problem
> is still there - so it's not
> Check vfs.ufs.dirhash_mem is not close to vfs.ufs.dirhash_maxmem if it is
> and only most used boxes this seems to be the case increase maxmem.
Its nowhere near - and the dirhash_maxmem and dirhash_minsize are the same
on both boxes.
> Seems this could either do with an auto tune option or a la
Steve
- Original Message -
From: "Pete French" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2007 2:06 AM
Subject: Re: Also seeing 2 x quad-core system slower that 2 x dual core
Have you checked that your dir ha
> Check dmesg for the APIC numbers corresponding to the CPUs you want to
> disable and add the corresponding entries to /boot/loader.conf, e.g.:
O.K., I did that, got it running on 4 CPU's only, and the problem
is still there - so it's not the number of CPU's after all. Which
is good in a way in
> Yes, if the claim is that the hardware is absolutely identical apart
> from one having two quad-core CPUs instead of two dual-core, the next
> step is to disable half of the CPUs and confirm that the problem goes away.
Just comming back to this today, will do a side by side compare of the dmes
Claus Guttesen wrote:
Thing is that GENERIC as installed out of the box should not take two minutes
to delete a gig of files off a 15k RPM SAS drive! especially not
when identical hardware with half the number of processor cores only takes
eleven seconds to do the same job. Something is wrong som
Hi
Pete French wrote:
Have you checked that your dir hash isn't suffering due to lack of memory
this can have a marked impact on seemingly trivial things like this as
could silly things like the RAID card being installed in a different slot.
RAID card is onboard on these things - how would I c
> Thing is that GENERIC as installed out of the box should not take two minutes
> to delete a gig of files off a 15k RPM SAS drive! especially not
> when identical hardware with half the number of processor cores only takes
> eleven seconds to do the same job. Something is wrong somewhere if doubli
> Have you checked that your dir hash isn't suffering due to lack of memory
> this can have a marked impact on seemingly trivial things like this as
> could silly things like the RAID card being installed in a different slot.
RAID card is onboard on these things - how would I check the dir hash ?
Have you checked that your dir hash isn't suffering due to lack of memory
this can have a marked impact on seemingly trivial things like this as
could silly things like the RAID card being installed in a different slot.
Regards
Steve
- Original Message -
From: "Pete French" <[EMAI
Pete French wrote:
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.
Well, yes, common sense would also tell me that. But the systems should
be identical aside from the number of cores. Both installed off 7.0-B
> 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.
Well, yes, common sense would also tell me that. But the systems should
be identical aside from the number of cores. Both installed off 7.0-BETA3
CD's today,
> 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
Matt Reimer wrote:
On Nov 29, 2007 11:20 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Matt Reimer wrote:
On Nov 29, 2007 10:58 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Pete French wrote:
On the dual core processors this takes about 20 seconds. On the quad
cores it takes about 3 minutes! T
On Nov 29, 2007 11:20 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Matt Reimer wrote:
> > On Nov 29, 2007 10:58 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >> Pete French wrote:
> >>> On the dual core processors this takes about 20 seconds. On the quad
> >>> cores it takes about 3 minutes! Thi
Matt Reimer wrote:
On Nov 29, 2007 10:58 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Pete French wrote:
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 ha
On Nov 29, 2007 10:58 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Pete French wrote:
> > 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 noth
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
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
> > ULE- or 4BSD-scheduler?
>
> 4BSD - am just running GENERIC on both system. Should I try ULE?
ULE has shown several improvements compared to 4BSD with more than one
cpu. It's worth trying but may not improve the rm-rimes.
> > Bit OT: Are the servers DL360 or DL380 (G5)? I will upgrade a DL380
> 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.
> 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
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,
40 matches
Mail list logo
