On Thursday, 15 December 2005 at 22:18:58 -0800, Eric Hodel wrote:
> On Dec 15, 2005, at 8:07 PM, Greg 'groggy' Lehey wrote:
>
>> On Friday, 16 December 2005 at 11:20:12 +0800, huang leo wrote:
>>>
>>> We had evaluated MySQL performance on FreeBSD and Linux. The
>>> result is attached.
>>
>> This i
On Sun, 8 Jan 2006 06:57:34 +
Chris <[EMAIL PROTECTED]> wrote:
> ah thanks for correcting me, so libthr and libpthread are both new then in
> 5.x?
Yes.
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
http://w
On 04/01/06, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> On Mon, 2 Jan 2006 01:28:07 +
> Chris <[EMAIL PROTECTED]> wrote:
>
> > have had mysql lockups until I tinkered with the threading settings.
> Libthr
> > is the good old threading routine from the 4.x days if I am correct, so
> if
>
On Thursday, 5 January 2006 at 10:49:48 +0800, Leo Huang wrote:
>> Personally I was surprised by this statement that libpthread wasn't
>> working for his test, for me it does benchmark a tad slower but I have
>> always seen libpthread as the most stable threading library.
>
> I am surprised too. B
> Personally I was surprised by this statement that libpthread wasn't
> working for his test, for me it does benchmark a tad slower but I have
> always seen libpthread as the most stable threading library.
I am surprised too. But It really happened in my test. You can get the
crash situation from
On Mon, 2 Jan 2006 01:28:07 +
Chris <[EMAIL PROTECTED]> wrote:
> have had mysql lockups until I tinkered with the threading settings. Libthr
> is the good old threading routine from the 4.x days if I am correct, so if
> libpthread is indeed unstable under continous heavy load how has it become
Chris wrote:
On 01/01/06, Michael Vince <[EMAIL PROTECTED]> wrote:
huang leo wrote:
Hi, all:
We had evaluated MySQL performance on FreeBSD and Linux. The result is
attached.
We are longing for your feedbacks!
Best regards,
Leo Huang
Really good work.
I gave your results
On 01/01/06, Michael Vince <[EMAIL PROTECTED]> wrote:
>
> huang leo wrote:
>
> >Hi, all:
> >
> >We had evaluated MySQL performance on FreeBSD and Linux. The result is
> >attached.
> >
> >We are longing for your feedbacks!
> >
> >
> >Best regards,
> >
> >Leo Huang
> >
> Really good work.
>
> I gave
huang leo wrote:
Hi, all:
We had evaluated MySQL performance on FreeBSD and Linux. The result is
attached.
We are longing for your feedbacks!
Best regards,
Leo Huang
Really good work.
I gave your results some thought and was thinking that maybe you should
check to see if you reached the
Chris wrote:
Make sure your compile your MySQL dynamically which is done by default,
if you include 'BUILD_STATIC=yes' you ruin your ability to change
threading libs.
portupgrade -N -m 'BUILD_OPTIMIZED=yes'
/usr/ports/databases/mysql41-server
Or upgrade
portupgrade -R -m 'BUILD_OPTIMIZED=yes'
>
> Make sure your compile your MySQL dynamically which is done by default,
> if you include 'BUILD_STATIC=yes' you ruin your ability to change
> threading libs.
>
> portupgrade -N -m 'BUILD_OPTIMIZED=yes'
> /usr/ports/databases/mysql41-server
> Or upgrade
> portupgrade -R -m 'BUILD_OPTIMIZED=yes
On 17/12/05, Scott Long <[EMAIL PROTECTED]> wrote:
>
> Gea-Suan Lin wrote:
>
> > On Fri, Dec 16, 2005 at 08:06:09AM +0100, Rink Springer wrote:
> >
> >>>And you should disable these options, it may increase ~10% again:
> >>>
> >>>-cpu I486_CPU
> >>>-cpu I586_CPU
> >>> cpu
Gea-Suan Lin wrote:
On Fri, Dec 16, 2005 at 08:06:09AM +0100, Rink Springer wrote:
And you should disable these options, it may increase ~10% again:
-cpu I486_CPU
-cpu I586_CPU
cpu I686_CPU
A recent discussion on -STABLE warned against removing I586_CPU,
On Fri, Dec 16, 2005 at 08:06:09AM +0100, Rink Springer wrote:
> > And you should disable these options, it may increase ~10% again:
> >
> > -cpu I486_CPU
> > -cpu I586_CPU
> > cpu I686_CPU
>
> A recent discussion on -STABLE warned against removing I586_CPU, r
So, is ULE ready for production on 6.0-RELEASE?
Can we use it without fear?
Cheers
Gea-Suan Lin wrote:
Hi,
In http://blog.gslin.org/archives/2005/12/12/252/ we test more cases,
and summary some important conclusions:
* SCHED_ULE (kernel options) is faster than SCHED_4BSD.
* Use kern.timecoun
> And you should disable these options, it may increase ~10% again:
>
> -cpu I486_CPU
> -cpu I586_CPU
> cpu I686_CPU
A recent discussion on -STABLE warned against removing I586_CPU, refer
to
http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/02069
Hi,
In http://blog.gslin.org/archives/2005/12/12/252/ we test more cases,
and summary some important conclusions:
* SCHED_ULE (kernel options) is faster than SCHED_4BSD.
* Use kern.timecounter.choice=TSC (sysctl) will be faster than ACPI-fast
or ACPI-safe. (about 10% again)
And I notice you u
hi,
I experience the crashes myself. I used super-smack remotely to connect
MySQL with 200 clients first. After the test was done and the connections
were closed, we connected MySQL with 300 clients immediately. Then the MySQL
restarted. The error log of MySQL is:
mysqld in free(): error: modified
On Dec 15, 2005, at 8:07 PM, Greg 'groggy' Lehey wrote:
On Friday, 16 December 2005 at 11:20:12 +0800, huang leo wrote:
We had evaluated MySQL performance on FreeBSD and Linux. The
result is
attached.
Thank you!
This is some of the most plausible information I've seen in a while.
I'm for
On Friday, 16 December 2005 at 11:20:12 +0800, huang leo wrote:
>
> We had evaluated MySQL performance on FreeBSD and Linux. The result is
> attached.
Thank you!
This is some of the most plausible information I've seen in a while.
I'm forwarding it to a MySQL internal list, and I expect we'll dis
20 matches
Mail list logo
