Kris Kennaway wrote:
Gergely CZUCZY wrote:
On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
* Compare to my config file here:
http://people.freebsd.org/~kris/scaling/my.
Gergely CZUCZY wrote:
On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
* Compare to my config file here:
http://people.freebsd.org/~kris/scaling/my.cnf
The default mysql
On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
> >On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
> >>Gergely CZUCZY wrote:
> >>
> * Compare to my config file here:
>
> http://people.freebsd.org/~kris/scaling/my.cnf
>
> Th
Gergely CZUCZY wrote:
On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
* Compare to my config file here:
http://people.freebsd.org/~kris/scaling/my.cnf
The default mysql config has very poor performance for innodb (you need at least innodb_thread_concurren
On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
>
> >>* Compare to my config file here:
> >>
> >>http://people.freebsd.org/~kris/scaling/my.cnf
> >>
> >>The default mysql config has very poor performance for innodb (you need at
> >>least innodb_thread_concur
On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
>
> >>* Compare to my config file here:
> >>
> >>http://people.freebsd.org/~kris/scaling/my.cnf
> >>
> >>The default mysql config has very poor performance for innodb (you need at
> >>least innodb_thread_concur
Gergely CZUCZY wrote:
* Compare to my config file here:
http://people.freebsd.org/~kris/scaling/my.cnf
The default mysql config has very poor performance for innodb (you need at least innodb_thread_concurrency = 0 to disable some mysql
brain-death). Maybe tuning is required for myisam also.
On Wed, 2 Jan 2008, Gary Stanley wrote:
At 06:00 AM 1/2/2008, Kris Kennaway wrote:
Per later discussion you will also need to either comment out the syscalls
that are (might be) being cached by glibc to artificially inflate its
reported rate, or verify that it is not doing so.
IIRC linux us
On Wed, 2 Jan 2008, Bruce Evans wrote:
On Tue, 1 Jan 2008, Jeff Roberson wrote:
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features.
IIRC
Linux takes advantage of this, while FreeBSD doesn't. I might be wrong
here,
of course.
T
Quoting Gergely CZUCZY <[EMAIL PROTECTED]> (Tue, 1 Jan 2008 15:21:16 +0100):
> Is there some wiki pages or any writings on this issue? I'm not so
> familiar with this COMPAT_43 obsolated stuff, and I'd like to
> know what's going on, what's the problem, and so on...
http://www.freebsd.org/project
At 06:00 AM 1/2/2008, Kris Kennaway wrote:
Per later discussion you will also need to either comment out the
syscalls that are (might be) being cached by glibc to artificially
inflate its reported rate, or verify that it is not doing so.
Kris
IIRC linux uses vsyscalls on x86_64, and calling
On 02/01/2008, Josh Carroll <[EMAIL PROTECTED]> wrote:
> > Does anyone have a theory why syscalls are so expensive in FreeBSD? Here
> > are the results of unixbench 4.1 on two machines. First is the machine
> > running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386
> > mode), 2 GH
Josh Carroll wrote:
Does anyone have a theory why syscalls are so expensive in FreeBSD? Here
are the results of unixbench 4.1 on two machines. First is the machine
running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386
mode), 2 GHz:
I ran the syscall benchmark from UnixBench o
> Does anyone have a theory why syscalls are so expensive in FreeBSD? Here
> are the results of unixbench 4.1 on two machines. First is the machine
> running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386
> mode), 2 GHz:
I ran the syscall benchmark from UnixBench on the same hard
Bruce Evans wrote:
> FreeBSD has more layers, with less optimization in each layer. Normally
> this doesn't matter, since everyone knows that syscalls are expensive
> and avoids them :-).
My point is that the majority of applications are written for Linux and
they are both syscall-intensive and
Kris Kennaway wrote:
> So it is using getpid? It should be fine on FreeBSD with the previous
> provisos, but you also need to check Linux behaviour and compare on
> identical hardware before you can draw conclusions.
Here's the source of unixbench syscall benchmark:
unsigned long iter;
void re
On Tue, 1 Jan 2008, Jeff Roberson wrote:
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features. IIRC
Linux takes advantage of this, while FreeBSD doesn't. I might be wrong
here,
of course.
This is true on 32bit x86 and not true on
Ivan Voras wrote:
Kris Kennaway wrote:
That's why it's important to dig into the details of what the benchmark
is actually doing before you conclude that "the numbers are higher for
linux, therefore it has faster syscalls".
Can you propose a simpler syscall on the GENERIC kernel that could be
Kris Kennaway wrote:
> It is likely to remain in people's custom kernels, possibly including
> the one used by Ivan. Anyway, this is all speculation until someone
> studies the claims in more detail.
I'm using GENERIC minus debugging options.
signature.asc
Description: OpenPGP digital signatu
Kris Kennaway wrote:
> That's why it's important to dig into the details of what the benchmark
> is actually doing before you conclude that "the numbers are higher for
> linux, therefore it has faster syscalls".
Can you propose a simpler syscall on the GENERIC kernel that could be
used instead of
Roman Divacky wrote:
BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep
COMPAT_43TTY, even when Linux emulation is not needed?
COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything.
COMPAT_43 did slow down things (the getpid for example) and it was remove
>BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep
> COMPAT_43TTY, even when Linux emulation is not needed?
COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything.
COMPAT_43 did slow down things (the getpid for example) and it was removed.
I dont see any pr
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote:
Vlad GALU wrote:
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUC
On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote:
> Vlad GALU wrote:
> >On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >>Gergely CZUCZY wrote:
> >>>On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> Ivan Voras wrote:
> >Kris Kennaway wrote:
> >>Gergely
Vlad GALU wrote:
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same f
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Gergely CZUCZY wrote:
> > On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> >> Ivan Voras wrote:
> >>> Kris Kennaway wrote:
> Gergely CZUCZY wrote:
> >> It looks like myisam is doing huge numbers of concurrent reads of th
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the kernel
(vnode interl
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> Ivan Voras wrote:
> >Kris Kennaway wrote:
> >>Gergely CZUCZY wrote:
> It looks like myisam is doing huge numbers of concurrent reads of the
> same file which is running into exclusive locking in the kernel
> (vnode interlo
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the kernel
(vnode interlock and lockbuilder mtxpool). Does it not do any
caching of the data in userspace bu
On Mon, 31 Dec 2007, Ivan Voras wrote:
Kris Kennaway wrote:
It's a general question. It looks like myisam either has a design
deficiency in this regard or it has poor defaults. If it can be made to
improve caching of the data in userland then performance should improve.
Isn't this common fo
Kris Kennaway wrote:
> Gergely CZUCZY wrote:
>>> It looks like myisam is doing huge numbers of concurrent reads of the
>>> same file which is running into exclusive locking in the kernel
>>> (vnode interlock and lockbuilder mtxpool). Does it not do any
>>> caching of the data in userspace but rel
Gergely CZUCZY wrote:
Still waiting for your sysbench command lines :)
There were 2 scripts and a sources file with options:
basicall that's everything. I know it's a but complex, but this was all behind
it.
OK, that was very important since you're changing defaults.
For different configurat
On Sun, Dec 30, 2007 at 03:08:28PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
> >On Sun, Dec 30, 2007 at 02:35:56PM +0100, Kris Kennaway wrote:
> >>Gergely CZUCZY wrote:
> >>
> I appreciate that you might be constrained by local requirements, but
> it's really not meaningful to co
Gergely CZUCZY wrote:
On Sun, Dec 30, 2007 at 02:35:56PM +0100, Kris Kennaway wrote:
Gergely CZUCZY wrote:
I appreciate that you might be constrained by local requirements, but it's really not meaningful to compare different mysql versions
if your goal is to study OS performance.
It'd be a PI
On Sun, Dec 30, 2007 at 02:35:56PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
>
> >>I appreciate that you might be constrained by local requirements, but it's
> >>really not meaningful to compare different mysql versions
> >>if your goal is to study OS performance.
> >It'd be a PITA to
Gergely CZUCZY wrote:
I appreciate that you might be constrained by local requirements, but it's really not meaningful to compare different mysql versions if
your goal is to study OS performance.
It'd be a PITA to install the both versions. Maybe now, that the ports freeze
is over, i can
do so
On Sun, Dec 30, 2007 at 02:18:31PM +0100, Kris Kennaway wrote:
> Gergely CZUCZY wrote:
> >On Sat, Dec 01, 2007 at 12:22:34PM -1000, Jeff Roberson wrote:
> >>On Sat, 1 Dec 2007, Gergely CZUCZY wrote:
> >>
> >>>On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> At 03:56 PM 12/1/2007,
Gergely CZUCZY wrote:
On Sat, Dec 01, 2007 at 12:22:34PM -1000, Jeff Roberson wrote:
On Sat, 1 Dec 2007, Gergely CZUCZY wrote:
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
I don't quite understand the question. It's the very same b
On Tue, Dec 04, 2007 at 09:46:44AM -0500, Mike Tancsa wrote:
> At 09:30 AM 12/4/2007, Gergely CZUCZY wrote:
> >Excuse me, but i have never heard of this "StorSav" thing, nor google gives
> >my anything but two hits, and suggests "StorSave" instead, which seems to
> >be some kind of "platform" fro
On Tue, Dec 04, 2007 at 09:22:36AM -0500, Mike Tancsa wrote:
> At 06:08 AM 12/4/2007, Gergely CZUCZY wrote:
> >cache seems to be turned on in the web-based management. However, I still
> >don't think this is OS-specific, since I see no OS-specific options, and
> >3ware makes the devices available
At 06:08 AM 12/4/2007, Gergely CZUCZY wrote:
cache seems to be turned on in the web-based management. However, I
still don't think this is OS-specific, since I see no OS-specific
options, and 3ware makes the devices available through SCSI, and WC
is handled differently there.
Its the queuing
On Sat, Dec 01, 2007 at 12:22:34PM -1000, Jeff Roberson wrote:
> On Sat, 1 Dec 2007, Gergely CZUCZY wrote:
>
> >On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> >>At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
> >>>I don't quite understand the question. It's the very same box, with
> >
On Tue, Dec 04, 2007 at 04:40:55AM -0500, Mike Tancsa wrote:
> At 04:22 AM 12/4/2007, Gergely CZUCZY wrote:
> >On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> >> At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
> >> >I don't quite understand the question. It's the very same box, with
> >
At 04:22 AM 12/4/2007, Gergely CZUCZY wrote:
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
> >I don't quite understand the question. It's the very same box, with
> >a dualboot configuration.
>
> Fire up the 3ware controller's RAID mana
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
> >I don't quite understand the question. It's the very same box, with
> >a dualboot configuration.
>
> Fire up the 3ware controller's RAID management software and make sure the
> same writ
At 04:10 PM 12/2/2007, Peter Losher wrote:
Mike Tancsa wrote:
> I think the card in question is twa in this case.
Not in our case...
Sorry, I was referring to the original posters card
http://lists.freebsd.org/pipermail/freebsd-performance/2007-November/002942.html
The box is a dual
Mike Tancsa wrote:
> I think the card in question is twa in this case.
Not in our case...
-=-
twe0: <3ware Storage Controller. Driver version 1.50.01.002> port
0x9c00-0x9c0f mem 0xfb6ffc00-0xfb6ffc0f,0xfa80-0xfaff irq 29 at
device 3.0 on pci1
twe0: [GIANT-LOCKED]
twe0: [ITHREAD]
On Sat, 1 Dec 2007 17:48:24 -0800 Manjunath R Gowda wrote:
> On 12/1/07, Boris Samorodov <[EMAIL PROTECTED]> wrote:
> > 3ware driver is under GIANT at 7.x. I don't know if it's the same for
> > linux.
> It is not under GIANT any more, MPSAFE starting from 7.0 BETA1.
Wow, that's great news! Thank
At 08:54 PM 12/1/2007, Peter Losher wrote:
Manjunath R Gowda wrote:
> On 12/1/07, Boris Samorodov <[EMAIL PROTECTED]> wrote:
>>
>> 3ware driver is under GIANT at 7.x. I don't know if it's the same for
>> linux.
>
> It is not under GIANT any more, MPSAFE starting from 7.0 BETA1.
I know in one cas
Manjunath R Gowda wrote:
> On 12/1/07, Boris Samorodov <[EMAIL PROTECTED]> wrote:
>>
>> 3ware driver is under GIANT at 7.x. I don't know if it's the same for
>> linux.
>
> It is not under GIANT any more, MPSAFE starting from 7.0 BETA1.
I know in one case on a box running BETA2 the kernel dmesg re
On 12/1/07, Boris Samorodov <[EMAIL PROTECTED]> wrote:
>
>
> 3ware driver is under GIANT at 7.x. I don't know if it's the same for
> linux.
It is not under GIANT any more, MPSAFE starting from 7.0 BETA1.
-Manjunath
___
freebsd-performance@freebsd.org
On Sat, 1 Dec 2007 17:33:34 +0100 Gergely CZUCZY wrote:
> I am using sysbench, with read-write tests.
> The test-table has 10M tuples, and i'm querying it for two minutes.
[...]
> The testbox has a dual opteron 246, 12G of memory and a 3ware-9550 with
> two disks in a mirror for the rootfs (also t
On Sat, 1 Dec 2007, Gergely CZUCZY wrote:
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
I don't quite understand the question. It's the very same box, with
a dualboot configuration.
Fire up the 3ware controller's RAID management sof
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
> At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
> >I don't quite understand the question. It's the very same box, with
> >a dualboot configuration.
>
> Fire up the 3ware controller's RAID management software and make sure the
> same writ
At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
I don't quite understand the question. It's the very same box, with
a dualboot configuration.
Fire up the 3ware controller's RAID management software and make sure
the same write caching strategy is set for FreeBSD and Linux. The
driver my default
On Sat, Dec 01, 2007 at 03:53:08PM -0500, Mike Tancsa wrote:
> At 11:33 AM 12/1/2007, Gergely CZUCZY wrote:
> >> >
> >> >The box is a dual opteron 246 with 12GB of memory with 10K RPM
> >> >SATA disks on a 9550 3ware.
> >> >
> >> >So, what can cause this big difference?
>
> Are the caching options
At 11:33 AM 12/1/2007, Gergely CZUCZY wrote:
> >
> >The box is a dual opteron 246 with 12GB of memory with 10K RPM
> >SATA disks on a 9550 3ware.
> >
> >So, what can cause this big difference?
Are the caching options for the 3ware the same on FreeBSD as Linux ?
---Mike
_
On Fri, Nov 30, 2007 at 02:31:50PM -1000, Jeff Roberson wrote:
> I've forwarded this mail to the freebsd performance list so more people can
> take a look at it. Thanks for all of the details. What
> was the test that you're doing? sysbench? With writes or without? Or some
> other benchmark
Jeff Roberson wrote:
[...]
the MySQL binary is statically linked, i've built it
that way.
ldd: /usr/local/libexec/mysqld: not a dynamic executable
Though, maybe I should rebuild it dynamically to ensure it's
linked against libthr (and not pthread or c_r)...
So, any tips, guesses, anything what
At 07:31 PM 11/30/2007, Jeff Roberson wrote:
Though, maybe I should rebuild it dynamically to ensure it's
linked against libthr (and not pthread or c_r)...
So, any tips, guesses, anything what can cause this?
I would make it dynamic instead of static. I seem to recall this
issue in the past
I've forwarded this mail to the freebsd performance list so more people
can take a look at it. Thanks for all of the details. What was the test
that you're doing? sysbench? With writes or without? Or some other
benchmark?
Thanks,
Jeff
On Thu, 29 Nov 2007, Gergely CZUCZY wrote:
Hello
I
62 matches
Mail list logo
