On Sat, Mar 05, 2011 at 09:04:50PM -1000, Clifton Royston wrote:
> On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote:
> ...
> > $ unset LANG
> > - Result: still 80x slower with -i
> > $ unset LANG LC_COLLATE
> > - Result: still 80x slower with -i
> > $ unset LANG LC_CTYPE
> > -
On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote:
...
> $ unset LANG
> - Result: still 80x slower with -i
> $ unset LANG LC_COLLATE
> - Result: still 80x slower with -i
> $ unset LANG LC_CTYPE
> - Result: normal/fast.
> $ unset LC_CTYPE
> - Result: still 80x slower with -i
>
On Sat, Mar 05, 2011 at 09:46:04PM -0500, Gary Palmer wrote:
> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> > This is a strange one, and the more I started debugging it (starting
> > with truss, comparing fast vs. slow results, where all that appears
> > different is read() op
On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> This is a strange one, and the more I started debugging it (starting
> with truss, comparing fast vs. slow results, where all that appears
> different is read() operations are taking a lot longer -- I haven't had
> time to check wit
On 5 March 2011 21:05, Jeremy Chadwick wrote:
> On Sat, Mar 05, 2011 at 08:49:46PM -0500, ill...@gmail.com wrote:
>> On 5 March 2011 20:43, Jeremy Chadwick wrote:
>> > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote:
>> >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick
On Sat, Mar 05, 2011 at 08:49:46PM -0500, ill...@gmail.com wrote:
> On 5 March 2011 20:43, Jeremy Chadwick wrote:
> > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote:
> >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> >> > This is a strange one, and the more I
On 5 March 2011 20:43, Jeremy Chadwick wrote:
> On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote:
>> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
>> > This is a strange one, and the more I started debugging it (starting
>> > with truss, comparing fast vs. slow re
On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote:
> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> > This is a strange one, and the more I started debugging it (starting
> > with truss, comparing fast vs. slow results, where all that appears
> > different is read(
On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> This is a strange one, and the more I started debugging it (starting
> with truss, comparing fast vs. slow results, where all that appears
> different is read() operations are taking a lot longer -- I haven't had
> time to check wit
This is a strange one, and the more I started debugging it (starting
with truss, comparing fast vs. slow results, where all that appears
different is read() operations are taking a lot longer -- I haven't had
time to check with ktrace yet), the more strange it got: that's when I
found out the behav
Just had one of hour webservers flag as down here and on
investigation the machine seems to be struggling due to
a hung vmdaemon process.
top is reporting vmdaemon as using a constant 55.57% CPU
yet CPU time is not increasing:-
last pid: 36492; load averages: 0.04, 0.05, .11 up 89+19:5
On Thu, Nov 27, 2008 at 2:29 AM, Claus Guttesen <[EMAIL PROTECTED]> wrote:
>> We recently found that the Performance of the NFS Client in FreeBSD is
>> worse than that in Linux.
>
> What OS is your nfs-server running?
Our NFS server is NetApp.
>
> You can ommit read- and write-size using tcp-mounts
> We recently found that the Performance of the NFS Client in FreeBSD is
> worse than that in Linux.
What OS is your nfs-server running?
> It's about 1/3 of NFS client in Linux. We have tuned TCP recv/send
> buffer, and got no gain. The mount parameters are: (We use amd)
> rw,nfsv3,lockd,grpid,in
Hi Listers,
We recently found that the Performance of the NFS Client in FreeBSD is
worse than that in Linux.
Linux [/net/iscsi] -jnlin- sudo ls -al
/net/iscsi/mysql/blog-2/var/pixblog_2/blogarticle.ibd
-rw-rw 1 3306 3306 734003200 2008-11-27 00:13
/net/iscsi/mysql/blog-2/var/pixblog_2/blogart
韓家標 Bill Hacker wrote:
>
> You haven't indicated what drives are on that controller, or how (RAID?)
> arranged.,, what sort of on-drive or on-controller cahce and policy.
>
> Nor how you measured the '..performs better', which a single
> can often do compared to several of the possible RAID conf
r us (now
over 50MB/sec. seq. write).
Regards,
Ruben van der Zwan
Espen Tagestad wrote:
Hi,
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR
SATA RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av majo
Espen Tagestad wrote:
Tom Judge wrote:
Espen Tagestad wrote:
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR
SATA RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major
performance issue with the dis
Espen Tagestad wrote:
Tom Judge wrote:
Espen Tagestad wrote:
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR
SATA RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major
performance issue with the dis
Tom Judge wrote:
Espen Tagestad wrote:
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR
SATA RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major performance
issue with the disc i/o. On write I get a
Espen Tagestad wrote:
Hi,
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR SATA
RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major performance
issue with the disc i/o. On write I get at max 7-8M
Espen Tagestad wrote:
Hi,
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR SATA
RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major performance
issue with the disc i/o. On write I get at max 7-8M
Hi,
We recently bought 3 new Dell 860 servers with the onboard SAS5/IR SATA
RAID-controller. They seem to be quite well spec'ed servers with
management and everything - but I am experiencing av major performance
issue with the disc i/o. On write I get at max 7-8MB/sec, while read
gives
dmose wrote:
>
>
> Scott Long-2 wrote:
>> dmose wrote:
>>>
>>> Bjoern A. Zeeb wrote:
On Tue, 27 Mar 2007, Ivan Voras wrote:
> Richard Tector wrote:
>> Is there any information I could obtain that would be of use to you in
>> tracking this one down?
> You could maybe cont
figure these options?
>>
>>
>
> Are you asking about FreeBSD or Windows 2000?
>
> Scott
>
> _______
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/list
dmose wrote:
>
>
> Bjoern A. Zeeb wrote:
>> On Tue, 27 Mar 2007, Ivan Voras wrote:
>>
>>> Richard Tector wrote:
Is there any information I could obtain that would be of use to you in
tracking this one down?
>>> You could maybe contact the driver's author(s) directly and ask them.
>>> Se
27;m experiencing the same issue win2kx64
environment slow I/O write (read about 65MB/sec) in RAID 1.
There is no way to enable caching in the boot BIOS ... anyone hear plans for
them to update a version that will allow us to configure these optio
Matthew Jacob wrote:
I've been trying to get one in my lab. I also am completely saturated
with two jobs and a new infant (which is why I'm responding to this at
0100) and was trying to get a box in my lab that evidenced te
behaviour. If I get stuck when I actually get time to chase this, I'll
as
I've been trying to get one in my lab. I also am completely saturated
with two jobs and a new infant (which is why I'm responding to this at
0100) and was trying to get a box in my lab that evidenced te
behaviour. If I get stuck when I actually get time to chase this, I'll
ask- thanks.
On 4/24/07
Matthew Jacob wrote:
Is there any news on the performance of this card?
I personally have not been able to reproduce the problem. It seems to
occur whether in Integrated Raid or not. It seems to be related to
specific backplanes and drives. It's an important problem to solve I
agree.
We hav
On Tue, 17 Apr 2007, Matthew Jacob wrote:
Hi,
Is there any news on the performance of this card?
I personally have not been able to reproduce the problem. It seems to
occur whether in Integrated Raid or not. It seems to be related to
specific backplanes and drives. It's an important problem
Is there any news on the performance of this card?
I personally have not been able to reproduce the problem. It seems to
occur whether in Integrated Raid or not. It seems to be related to
specific backplanes and drives. It's an important problem to solve I
agree.
__
Richard Tector wrote:
Ivan Voras wrote:
Richard Tector wrote:
I'm suffering from very slow write performance on a Dell PowerEdge 860
with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
6.2-STABLE with sources from yesterday. The controller hosts 2 Western
Digital 320GB SATA
Bjoern A. Zeeb wrote:
On Sun, 1 Apr 2007, Richard Tector wrote:
A perhaps unrealted issue:
I've noticed a large number of messages being produced by the mpt
driver after boot occuring approximately every 90 seconds.
Apr 1 15:51:43 moses kernel: mpt0: mpt_cam_event: 0x14
Apr 1 15:51:43 moses
On 4/1/07, Richard Tector <[EMAIL PROTECTED]> wrote:
Matthew Jacob wrote:
> On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
>> Matthew Jacob wrote:
>> > It's been seen before but the fix isn't know yet.
>> >
>> > On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
>> >> I'm suffering from
On Sun, 1 Apr 2007, Richard Tector wrote:
A perhaps unrealted issue:
I've noticed a large number of messages being produced by the mpt driver
after boot occuring approximately every 90 seconds.
Apr 1 15:51:43 moses kernel: mpt0: mpt_cam_event: 0x14
Apr 1 15:51:43 moses kernel: mpt0: Unhandl
Matthew Jacob wrote:
On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
Matthew Jacob wrote:
> It's been seen before but the fix isn't know yet.
>
> On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
>> I'm suffering from very slow write performance on a Dell PowerEdge
860
>> with the SAS
On Tue, 27 Mar 2007, Matthew Jacob wrote:
On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
Thank you for the quick reply.
Is there any information I could obtain that would be of use to you in
tracking this one down?
not at the momeny- it's really that I won't have time until april
As
not at the momeny- it's really that I won't have time until april
On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
Matthew Jacob wrote:
> It's been seen before but the fix isn't know yet.
>
> On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
>> I'm suffering from very slow write perform
On Tue, 27 Mar 2007, Ivan Voras wrote:
Richard Tector wrote:
Is there any information I could obtain that would be of use to you in
tracking this one down?
You could maybe contact the driver's author(s) directly and ask them.
See the AUTHORS section of the man page for details.
you should h
Bjoern A. Zeeb wrote:
> you should have done your homework before saying this and you might
> have noticed something;-)
Ah, yes, I see now :)
My apologies - I only glanced and compared the e-mail addresses of the
posters and the authors and arrived to the obvious conclusion :)
signature.asc
Richard Tector wrote:
> Is there any information I could obtain that would be of use to you in
> tracking this one down?
You could maybe contact the driver's author(s) directly and ask them.
See the AUTHORS section of the man page for details.
signature.asc
Description: OpenPGP digital signatur
Matthew Jacob wrote:
It's been seen before but the fix isn't know yet.
On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
I'm suffering from very slow write performance on a Dell PowerEdge 860
with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
6.2-STABLE with sources from
Ivan Voras wrote:
Richard Tector wrote:
I'm suffering from very slow write performance on a Dell PowerEdge 860
with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
6.2-STABLE with sources from yesterday. The controller hosts 2 Western
Digital 320GB SATA disks in a RAID1 conf
It's been seen before but the fix isn't know yet.
On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote:
I'm suffering from very slow write performance on a Dell PowerEdge 860
with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
6.2-STABLE with sources from yesterday. The contro
Richard Tector wrote:
> I'm suffering from very slow write performance on a Dell PowerEdge 860
> with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
> 6.2-STABLE with sources from yesterday. The controller hosts 2 Western
> Digital 320GB SATA disks in a RAID1 configuration.
> Rea
I'm suffering from very slow write performance on a Dell PowerEdge 860
with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or
6.2-STABLE with sources from yesterday. The controller hosts 2 Western
Digital 320GB SATA disks in a RAID1 configuration.
Reads approach 65MB/s however wr
> >
> >I think I've found the problem: Python uses setjmp/longjmp to protect
> >against SIGFPU every time it does floating point operations. The python
> >script does not actually use threads, and libpthread assumes
> >non-threaded processes are system scope. So, it would end up using the
>
Suleiman Souhlal wrote:
Hello,
On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
On Tue, 10 May 2005, Peter Jeremy wrote:
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it
On Tue, 10 May 2005, Suleiman Souhlal wrote:
> Hi,
>
> On May 10, 2005, at 1:24 AM, Daniel Eischen wrote:
>
> > No, libc_r wraps execve() and a lot of other syscalls that libpthread
> > or libthr don't need to. Take a look at libc_r/uthread/
> > uthread_execve.c
> > and you will see it sets the s
Hi,
On May 10, 2005, at 1:24 AM, Daniel Eischen wrote:
No, libc_r wraps execve() and a lot of other syscalls that libpthread
or libthr don't need to. Take a look at libc_r/uthread/
uthread_execve.c
and you will see it sets the signal mask before exec()ing.
Couldn't we do the same thing in libpthr
On Tue, 10 May 2005, Suleiman Souhlal wrote:
> Hello,
>
> On May 9, 2005, at 7:21 PM, Daniel Eischen wrote:
>
> > I don't think that patch is correct. You need the signal mask
> > in the kernel to match in case of an exec() after a fork()
> > for instance. If the application fork()'s, then chang
On Mon, 9 May 2005, Jonathan Noack wrote:
> On 05/09/05 18:47, Daniel Eischen wrote:
> >>If the process wasn't linked to libpthread, then the longjmp()
> >>and setjmp() would still be calling the syscall, so it isn't
> >>the syscall itself that is making things slower. You'll notice
> >>that ther
Hello,
On May 9, 2005, at 7:21 PM, Daniel Eischen wrote:
I don't think that patch is correct. You need the signal mask
in the kernel to match in case of an exec() after a fork()
for instance. If the application fork()'s, then changes the
signal mask in the child (which is now single threaded), th
On 05/09/05 18:47, Daniel Eischen wrote:
On Mon, 9 May 2005, Daniel Eischen wrote:
On Mon, 9 May 2005, Suleiman Souhlal wrote:
I think I've found the problem: Python uses setjmp/longjmp to protect
against SIGFPU every time it does floating point operations. The
python script does not actually use t
On Mon, 9 May 2005, Daniel Eischen wrote:
> On Mon, 9 May 2005, Suleiman Souhlal wrote:
> > I think I've found the problem: Python uses setjmp/longjmp to protect
> > against SIGFPU every time it does floating point operations. The
> > python script does not actually use threads, and libpthread ass
On Mon, 9 May 2005, Suleiman Souhlal wrote:
> On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
>
> > The threading libraries don't play with the signal mask. In fact,
> > libpthread has userland versions of sigprocmask() et. al. and won't
> > even make the syscall() unless the threads are system
Hello,
On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
On Tue, 10 May 2005, Peter Jeremy wrote:
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is
On 5/9/2005 1:30 PM, Jonathan Noack wrote:
On 5/9/2005 12:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I ju
Daniel Eischen wrote:
> {sig}setjmp(), {sig}longjmp(),
A very wild guess.. python is using setjmp/longjmp to implement
continuations, tailcalls, or any mechanism similar to that and using
that in a loop?
mkb.
___
freebsd-stable@freebsd.org mailin
On Tue, 10 May 2005, Peter Jeremy wrote:
> On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
> >I have what I think is a serious performance issue with fbsd 5.3
> >release. I've read about threading issues, and it seems to me that
> >that is what I'm looking a
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
>I have what I think is a serious performance issue with fbsd 5.3
>release. I've read about threading issues, and it seems to me that
>that is what I'm looking at, but I'm not confident enough to rule out
>that it m
On 5/9/2005 12:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I just ran a test here with SMP turned of on 5
On Mon, 9 May 2005, Suleiman Souhlal wrote:
> Hello,
>
>
> I ran ktrace(1) on it, and it appears that python keeps calling
> sigprocmask() continually:
>
> 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c)
> 673 python 0.05 RET sigprocmask 0
> 673 python 0.09 CALL
On Mon, May 9, 2005 1:06 pm, Scott Long said:
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP turned on by
> default. Would you be able to re-run your test with SMP turned off?
This is what i get on my system, wh
Hello,
On May 9, 2005, at 1:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I just ran a test here with SMP tur
Scott Long wrote:
> First of all, make sure that you have WITNESS and INVARIANTS off in your
> kernel. You might also want to recompile your kernel with the SMP
> option turned off.
I can confirm this.
I just rerun it on RELENG_5_4 as of yesterday and got
136.52 real80.29 user
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP
> turned on by default. Would you be able to re-run your test with
> SMP turned off?
I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the
follow
Ewan Todd wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I'm pretty sure there's no SMP in this kernel.
#cd /usr/src/sys/i38
>
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP
> turned on by default. Would you be able to re-run your test with
> SMP turned off?
>
I'm pretty sure there's no SMP in this kernel.
#cd /usr/src/sys/i386/c
Ewan Todd wrote:
Whereas, the typical result for the new rig looked more like
105.36 real71.10 user33.41 sys
...
10548 involuntary context switches
First of all, make sure that you have WITNESS and INVARIANTS off in your
kernel. You might also want to recompile your ker
> >
> >Whereas, the typical result for the new rig looked more like
> >
> > 105.36 real71.10 user33.41 sys
> > ...
> > 10548 involuntary context switches
> >
> >
>
> First of all, make sure that you have WITNESS and INVARIANTS off in your
> kernel. You might also wan
@freebsd.org
Subject: Re: Performance issue
> Whereas, the typical result for the new rig looked more like
>
> 105.36 real71.10 user33.41 sys
...
> 10548 involuntary context switches
Now I just ran this test myself. This machine is a 2.4 gig P4 with
hyperth
> Whereas, the typical result for the new rig looked more like
>
> 105.36 real71.10 user33.41 sys
...
> 10548 involuntary context switches
Now I just ran this test myself. This machine is a 2.4 gig P4 with
hyperthreading enabled. Much as I am an AMD fan, I would expect
At 11:00 AM 09/05/2005, Ewan Todd wrote:
Here's the background. I just got a new (to me) AMD machine and put
5.3 release on it. I'd been very happy with the way my old Intel
There have been quite a few changes since 5.3. If you are starting fresh, I
would strongly recommend going to 5.4 RC4. The
Ewan Todd wrote:
Hi All,
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is what I'm looking at, but I'm not confident enough to rule out
that it might be a hardware issue, a kernel configur
Hi All,
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is what I'm looking at, but I'm not confident enough to rule out
that it might be a hardware issue, a kernel configuration issue, or
[EMAIL PROTECTED] said:
> Yesterday I upgraded my news server from 5.1 to 5.2.1 and ran into
> performance problem.
> Want to say from the beginning that during upgrade I transferred all
> my sysctl and other settings from 5.1 into 5.2.1
You might get a better response from the folks on the freebs
77 matches
Mail list logo
