# [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200:
For accurate measurements and comparisons, you have to make
sure to use _exactly_ the same physical location on the
disk.
No you don't. You want to make a side-by-side comparison
of two products, and if one of them underperforms, it just
On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote:
No you don't. You want to make a side-by-side comparison
of two products, and if one of them underperforms, it just
underperforms. You cannot use a poor location selection
strategy in the driver as an excuse for poor operation.
# [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930:
On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote:
No you don't. You want to make a side-by-side comparison
of two products, and if one of them underperforms, it just
underperforms. You cannot use a poor location selection
Roman Neuhauser wrote:
In all honesty, I'm getting somewhat irritated by all the
dd is meaningless performance measurement tool, use something
real and similar arguments: dd is a real command for real
work, and if it shows abysmal performance of sequential writes,
then
On Tue, 28 Jun 2005 20:43, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930:
On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote:
No you don't. You want to make a side-by-side comparison
of two products, and if one of them underperforms, it just
Hi,
i wouldn't start a principal discussion, but i have too?
I have one Machine! and on this machine with identical Hardware,
identical real! not same not side by side, real the same disk,
processor, ram, board..
-- read my other postings, it's recommendet.
on this machine i have made 4
Michael Schuh wrote:
# cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile;
I would only compare the performace from 2 Versions of FreeBSD, while
i mean that the performance from RELENG_5 is more slower than under
GENTOO and it is double as slow as under RELENG_4.
Let me guess:
On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote:
I can't reproduce it in -current.
-bash-2.05b$ uname -a
FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT
2005
Yeah, you already said that before. So where do we go from here? Should I try
to get a backtrace of
On Tue, 28 Jun 2005, Michael Nottebrock wrote:
On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote:
I can't reproduce it in -current.
-bash-2.05b$ uname -a
FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT
2005
Yeah, you already said that before. So where
On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200:
For accurate measurements and comparisons, you have to make
sure to use _exactly_ the same physical location on the
disk.
No you don't. You want to make a side-by-side
Yes, i know that and i agree with them.
that was the reason, why my disk is tiled on first physical Gigabyte for Swap,
and the rest for the system
my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux,
but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5.
so that the
# [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400:
Note how the transfer rate for the outside is almost twice that of the
inside. Suppose I run tests on two different operating systems, one
of which resides in a partition on the inside portion and the other in
one on the outside portion.
# [EMAIL PROTECTED] / 2005-06-28 18:29:59 +0200:
2005/6/28, Paul Mather [EMAIL PROTECTED]:
On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200:
For accurate measurements and comparisons, you have to make
sure to use _exactly_ the
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400:
Note how the transfer rate for the outside is almost twice that of the
inside. Suppose I run tests on two different operating systems, one
of which resides in a partition on the
(Note that however good or bad it may be, the location selection
strategy in the driver can only lay out data within the confines of
the partition.) Now, I do a dd test and find that the outside OS
is almost twice as fast as the other. Would it be wise to conclude
that the slower OS is
# [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400:
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote:
My apologies if it wasn't clear, but I was responding to your apparent
assertion that location does not matter in disk performance benchmarks.
We seem to have a misunderstaning, I
On Tue, 2005-06-28 at 19:17 +0200, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400:
What you see as being defensive I see as being rigorous. If someone is
making a claim based upon a performance benchmark, people will quiz the
person conducting the benchmark to
On Tue, Jun 28, 2005 at 07:17:39PM +0200, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400:
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote:
My apologies if it wasn't clear, but I was responding to your apparent
assertion that location does not matter in
On 28-Jun-05, at 1:01 PM, Xin LI wrote:
We care about why MySQL appears to be slower, how to improve the
situation,
and not numbers from poorly done benchmarks which ignored the
effect of
debugging options, version, disk mount options, etc., which is IMHO
meaningless.
Maybe a key
Having just read this thread, I'd like to say that all messages are
making valid points, and all participants agree with each other.
However, the argumentative discussion is creating a lot of noise.
Meanwhile, there are people doing meaningful work on this.
A good standby would be to patch your
I also quickly put a wiki together to help me document any kind of
testing or patching we can try. Feel free to contribute. My hope is
we can refer others to this document, and not create too much noise
on this list as others have suggested is being created (the noise
that is).
I hope
speaking of noise how about I include a URL
http://www.segr.ca/index.php/FreeBSD/MySQL
sheesh... sorry to all.
Stephane
On 28-Jun-05, at 8:55 PM, Stephane Raimbault wrote:
I also quickly put a wiki together to help me document any kind of
testing or patching we can try. Feel free to
On Monday, 20. June 2005 19:17, Daniel Eischen wrote:
Works here on a month or two old -current. I'm using
/usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so).
Crashes for me:
[EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf
Steve Roome wrote:
I posted these results and anything else that went with this thread to
the freebsd-performance mailing list.
-current proved a slightly better performer for us, but not enough to
bring it even close to the performance we get with gentoo.
Off the top of my head the select
On Mon, 27 Jun 2005, Michael Nottebrock wrote:
On Monday, 20. June 2005 19:17, Daniel Eischen wrote:
Works here on a month or two old -current. ?I'm using
/usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so).
Crashes for me:
[EMAIL PROTECTED]:127:~ env
Michael Schuh [EMAIL PROTECTED] wrote:
now i have another question, if i use the same Os in 2 versions
(RELENG_4, RELENG_5) can i hope that the tests are made on the same
part of disk?
yoda
Hope you always can. But rely on it you should not.
/yoda
;-)
or in other words can an dd on the
Hi Oliver,
2005/6/22, Oliver Fromme [EMAIL PROTECTED]:
Michael Schuh [EMAIL PROTECTED] wrote:
now i have another question, if i use the same Os in 2 versions
(RELENG_4, RELENG_5) can i hope that the tests are made on the same
part of disk?
yoda
Hope you always can. But rely on it
hello,
first sorry for my bad english, with noop i mean no operation.
i can live with a better performance from postgresql under RELENG_5 :-D
i find it great.
As i sayed i have the installations always made in the same way, so that i mean.
I mean i have alwas made the swap on the first gig of
Michael Schuh [EMAIL PROTECTED] wrote:
As i sayed i have the installations always made in the same way, so that i
mean.
I mean i have alwas made the swap on the first gig of the disk, and
the installation
on the rest of the disk. and i have no multiple os'es on these disk.
The problem
Hello Oliver,
ah, that are the hint that i missed.
now i have another question, if i use the same Os in 2 versions
(RELENG_4, RELENG_5) can i hope that the tests are made on the same
part of disk?
or in other words can an dd on the two OS' es so much different
because they use an
totally
On Fri, Jun 17, 2005 at 10:30:25AM -0500, Greg Barniskis wrote:
I think he meant comparing 36,000 on CentOS (async) to 24,000 on
CURRENT (sync). I wondered that myself, and having searched out the
answer I find that it is declared in
Hello,
i follows up these thread and i think you all digging on the false
possible error location..
I have made many performance tests with RELENG_4 related to RELENG_5
and DragonFly and Gentoo.
My results was that RELENG_5 is half as RELENG_4 fast by disk-access
(ata-related).
I have seen
Michael Schuh wrote:
My results was that RELENG_5 is half as RELENG_4 fast by disk-access
(ata-related).
I have seen that RELENG_5 with GENERIC Kernel and only modified option HZ=2000.
the spread begind with Gentoo (mentoided from me as the slowest, but
errare humanum est)
Gentoo : 100%
Hello,
yes random IO is more targetted to Databases.
noop, i have the installation always made in the same way, and i have respected
the different diskperformace in different disk-parts.
this was the reason for
#cd /;
at the beginning of my tests.
In the first test i have me shooting self
On Fri, 17 Jun 2005, David Sze wrote:
FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope)
FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process
scope)
CentOS/amd64 4.0 (i.e. RHEL4.0)
I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE,
On Saturday, 11. June 2005 17:05, Daniel Eischen wrote:
You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force
libpthread to use system scope.
I've played around with that variable (set it in .xsession) and found that
kpdf (from graphics/kdegraphics3) will reproducably crash if
On Mon, 20 Jun 2005, Michael Nottebrock wrote:
On Saturday, 11. June 2005 17:05, Daniel Eischen wrote:
You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force
libpthread to use system scope.
I've played around with that variable (set it in .xsession) and found that
kpdf
On Monday, 20. June 2005 18:53, Daniel Eischen wrote:
Works here on a month or two old -current. I'm using
/usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so).
Crashes for me:
[EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf
On Mon, 20 Jun 2005, Michael Nottebrock wrote:
On Monday, 20. June 2005 18:53, Daniel Eischen wrote:
Works here on a month or two old -current. I'm using
/usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so).
Crashes for me:
[EMAIL PROTECTED]:127:~ env
Michael Schuh wrote:
Hello,
yes random IO is more targetted to Databases.
noop, i have the installation always made in the same way, and i have respected
the different diskperformace in different disk-parts.
this was the reason for
#cd /;
at the beginning of my tests.
In the first test
I've posted a longer reply, with a trimmed cc list on the -performance
mailing list if anyone is still interested and I'll leave it off
-stable as it's probably become somewhat off topic now.
Sadly, I don't think simply having an async FS is going to solve our
problem though. :(
Ta,
On Friday 17 June 2005 23:47, Javier Henderson wrote:
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per
Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:
Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy Helmer: PREEMPTIVE, vfs.read_max
Jon Dama: David Xu's Thrds, Ptmalloc, cpu
On Thu, 16 Jun 2005, Steve Roome wrote:
The good news though, is that the Mysql folks have agreed to setup tests
to profile mysql on identical hardware running FreeBSD and Linux with an
aim to find out exactly where the problem really is. They reckon they'll
spend at least two weeks trying
At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:
Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:
Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy Helmer: PREEMPTIVE,
[...]
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
super-smack update-select
5.4-RELEASE
David Sze wrote:
At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:
Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:
Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy
Uzi wrote:
[...]
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
super-smack update-select
5.4-RELEASE
J. T. Farmer wrote:
Uzi wrote:
[...]
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
super-smack update-select
J. T. Farmer wrote:
Uzi wrote:
[...]
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
super-smack update-select
On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote:
i think you're missing the point... using CURRENT on a production
machine is a bad idea... the performance is great, but hardly worth the
risk of breaking something.
Under normal circumstances I'd agree, but -CURRENT is already in code
Greg Barniskis [EMAIL PROTECTED] writes:
that async provides fast writes at the cost of no guarantee at all
for a consistent state of the filesystem. So, you choose: fast but
not so reliable writes, or slower writes with fast, reliable
disaster recovery.
Thanks to the FreeBSD team for
On Fri, Jun 17, 2005 at 05:47:56PM +0200, Matthias Buelow wrote:
Is CentOS using ext2? I thought everyone moved to ext3 already, which
provides nearly the speed of ext2+async but is safe due to its journal.
If you make such comparisons, please use current technology, and not
the status quo
David Sze wrote:
On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote:
i think you're missing the point... using CURRENT on a production
machine is a bad idea... the performance is great, but hardly worth the
risk of breaking something.
Under normal circumstances I'd agree, but
On Fri, Jun 17, 2005 at 12:05:54PM -0400, JM wrote:
David Sze wrote:
Under normal circumstances I'd agree, but -CURRENT is already in code
freeze in preparation for the upcoming 6.0 release:
http://www.freebsd.org/releases/6.0R/schedule.html
I also follow the cvs-src mailing list
Matthias Buelow wrote:
Greg Barniskis [EMAIL PROTECTED] writes:
that async provides fast writes at the cost of no guarantee at all
for a consistent state of the filesystem. So, you choose: fast but
not so reliable writes, or slower writes with fast, reliable
disaster recovery.
Thanks to
David Sze [EMAIL PROTECTED] writes:
CentOS uses ext3 by default. How does having a journal help if the
journal is stored on the same async filesystem? Unless the journal
writes are guaranteed sync.
The journal guarantees that the filesystem will always be consistent. If
a journal entry doesn't
i think you're missing the point... using CURRENT on a production
machine is a bad idea... the performance is great, but hardly worth the
risk of breaking something.
In general, this is true. But since we're in the glide path to a
release, and since we have measures in place to keep
* David Sze ([EMAIL PROTECTED]) wrote:
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
Uh, this should be an
On Fri, Jun 17, 2005 at 06:20:59PM +0200, Matthias Buelow wrote:
David Sze [EMAIL PROTECTED] writes:
CentOS uses ext3 by default. How does having a journal help if the
journal is stored on the same async filesystem? Unless the journal
writes are guaranteed sync.
The journal guarantees
On Fri, 17 Jun 2005 13:57:26 -0500
David Sze [EMAIL PROTECTED] wrote:
I'm not sure filesystem consistency alone is good enough. Say your
bank's database crashes right after you make a deposit. When it comes
back up it's consistent, but only up to 5 minutes before the crash due
to the async
--On Freitag, 17. Juni 2005 17:47 Uhr +0200 Matthias Buelow [EMAIL PROTECTED]
wrote:
Greg Barniskis [EMAIL PROTECTED] writes:
Is CentOS using ext2? I thought everyone moved to ext3 already, which
provides nearly the speed of ext2+async but is safe due to its journal.
If you make such
David Sze [EMAIL PROTECTED] writes:
I'm not sure filesystem consistency alone is good enough. Say your
bank's database crashes right after you make a deposit. When it comes
back up it's consistent, but only up to 5 minutes before the crash due
to the async mount.
A bank doesn't run on Unix. It
On Fri, Jun 17, 2005 at 11:01:30PM +0200, Matthias Buelow wrote..
David Sze [EMAIL PROTECTED] writes:
I'm not sure filesystem consistency alone is good enough. Say your
bank's database crashes right after you make a deposit. When it comes
back up it's consistent, but only up to 5 minutes
Andreas Braukmann [EMAIL PROTECTED] writes:
That makes your arguments pointless. I wouldn't even think of
running a database server on an async mounted filesystem; all the
more I wouldn't connect a drive with enabled write cache to a
production box.
So you remount all filesystems -o sync on your
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial transaction processing, and the customer's accounts?
I hope it's not my bank..
mkb.
___
freebsd-stable@freebsd.org mailing
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial transaction processing, and the customer's accounts?
Yes. Go and visit the London City and check
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial transaction processing, and the customer's accounts?
Yes. Go and visit the
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial transaction processing, and the customer's accounts?
Yes. Go and visit the
Wilko Bulte [EMAIL PROTECTED] writes:
Yes. Go and visit the London City and check their computer rooms.
You will be surprised about the number of UNIX boxes. You don't
think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
And these are the machines where the master account data
On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial
Javier Henderson wrote:
Wilko Bulte wrote:
[ ... ]
Yes. Go and visit the London City and check their computer rooms.
You will be surprised about the number of UNIX boxes. You don't
think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
But are those Unix servers actually
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
--On Freitag, 17. Juni 2005 23:10 Uhr +0200 Matthias Buelow [EMAIL PROTECTED]
wrote:
Andreas Braukmann [EMAIL PROTECTED] writes:
That makes your arguments pointless. I wouldn't even think of
running a database server on an async mounted filesystem; all the
more I wouldn't connect a drive
On Fri, Jun 17, 2005 at 02:47:54PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If
Andreas Braukmann [EMAIL PROTECTED] writes:
no. But I don't mount them async, either.
The default noasync in combination with softupdates
on disks with disabled write caches is perfectly fine
with me.
Noasync only makes sense in the absence of softupdates. With
softupdates, metadata is written
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote..
Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can
matthias,
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote:
Wilko Bulte [EMAIL PROTECTED] writes:
If you give me $5 per Unix system found there I can retire here and now.
For financial transaction processing, and the customer's accounts?
I hope it's not my bank..
i know
On 17 Jun, David Sze wrote:
AFAIK, SCSI disks normally have write caching disabled.
All the ones that I've encountered in recent years have had write
caching enabled. I always have to remember to use camcontrol to disable
WCE when I install a new disk.
On Fri, 2005-Jun-17 10:38:34 -0400, David Sze wrote:
It turns out that the problem was the same thing everyone usually points
the finger at, but no one actually mentioned this time: Linux mounts its
partitions async by default.
This shouldn't be an issue here. The FreeBSD default has always
On Fri, 2005-Jun-17 23:42:08 +0200, Wilko Bulte wrote:
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
Wilko Bulte wrote:
Yes. Go and visit the London City and check their computer rooms.
You will be surprised about the number of UNIX boxes. You don't
think IBM, HP, Sun
You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force
libpthread to use system scope. This is easier than rebuilding libpthread
(with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some
applications and 1:1 for others.
Is the sysctl kern.threads.thr_scope_sys
On Mon, 13 Jun 2005, Pete French wrote:
You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force
libpthread to use system scope. This is easier than rebuilding libpthread
(with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some
applications and 1:1 for others.
Reread the above for the answer to your last question.
Sorry, rephrased - 'How can I set that environment variable for all processes?'
I'm kind of embarassed to have to ask, as this should surely be very simple,
but I cant think of anywhere to set system-wide environment variables which
all
On Mon, 13 Jun 2005, Pete French wrote:
Reread the above for the answer to your last question.
Sorry, rephrased - 'How can I set that environment variable for all
processes?'
login.conf perhaps?
I'm kind of embarassed to have to ask, as this should surely be very simple,
but I cant
On Tue, 14 Jun 2005 01:24, Pete French wrote:
I'm kind of embarassed to have to ask, as this should surely be very
simple, but I cant think of anywhere to set system-wide environment
variables which all processes will have. I've only ever done this in shell
profiles before and I cant think of
Just wondering:
How much processor migration takes place on linux mysql?
Do the threads mostly stick to the same processors?
I've noticed that on FreeBSD the 4BSD scheduler doesn't do much to
preserve cache coherency.
What sort of cache/TLB misses do you see running mysql linux vs. mysql
Steve Roome wrote:
We're using mostly:
5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005
This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks),
we've been keeping up with stable because supposedly all these new
fixes to threading will help us out here.
We're
On Fri, 10 Jun 2005, Steve Roome wrote:
We're using mostly:
5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005
In my experience, the following factors make a big performance difference:
- Thread package. In 5.x, you get process scope threads by default, but
it turns out
On 6/11/05, Robert Watson [EMAIL PROTECTED] wrote:
I think there's a compile-time option to make libpthread use system scope
threads but the details ellude me. The Linuxthreads library may well
provide a substantial improvement -- not as good for MySQL as the 6.x
libthr, but perhaps
I've been working with Steve on this project. We've been playing with various tuning
factors, including kernel changes, different stripe sizes on the RAID, my.cnf
tuning, libmap.conf, and although we can gain a bit here and there, we can't account for
the doubling of performance with Gentoo.
One thing more...
I've seen a message on a PostgreSQL list that MySQL can
_silently_ change the type of the tables if it cannot find
some library. Check that you have really same DBs
in Gentoo and FreeBSD.
--
V.Chukharev
___
freebsd-stable@freebsd.org
Am Samstag, 11. Juni 2005 10:00 schrieb Robert Watson:
On Fri, 10 Jun 2005, Steve Roome wrote:
[...]
- Thread package. In 5.x, you get process scope threads by default, but
it turns out MySQL is tuned for system scope threads, and this is
particularly visible in the supersmack
Robert Watson wrote:
On Fri, 10 Jun 2005, Steve Roome wrote:
We're using mostly:
5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005
In my experience, the following factors make a big performance difference:
- Thread package. In 5.x, you get process scope threads by default,
On Fri, Jun 10, 2005 at 06:05:37PM +0100, Steve Roome wrote:
We're using mostly:
5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005
Show your kernel config etc.
Kris
pgpfXpy1EB8Ez.pgp
Description: PGP signature
Hi Kris,
On 10 Jun 2005, at 18:17, Kris Kennaway wrote:
Show your kernel config etc.
I've been working with Steve on this project. We've been playing
with various tuning factors, including kernel changes, different
stripe sizes on the RAID, my.cnf tuning, libmap.conf, and although
we
* Steve Roome ([EMAIL PROTECTED]) wrote:
We're trying to get FreeBSD to perform reasonably well, in comparison
to Linux, or even what we should expect to see. We're getting about
half the performance we get from gentoo on the same application
(mysql).
Fancy giving CURRENT a try?
For the
Steve Roome wrote:
We're using mostly:
5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005
This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks),
we've been keeping up with stable because supposedly all these new
fixes to threading will help us out here.
We're
Hi Guy,
On 10 Jun 2005, at 21:37, Guy Helmer wrote:
Have you tried a kernel with PREEMPTION enabled? I haven't
quantified the effect, but it's improved performance in some
situations.
Have you tried increasing vfs.read_max?
Thanks for your suggestions... I've given them a go, and it
1 - 100 of 106 matches
Mail list logo
