On Sat, Aug 13, 2005 at 07:50:14AM +0530, Akhthar Parvez. K wrote:
> Hi all,
>
> I am gettting the following error message while accessing the interchange
> admin panel.
>
> (perl), uid 1004: exited on signal 11 (core dumped)
>
> I have no problem in accessing the main page. Does anyone know w
On Sat, May 06, 2006 at 03:16:48PM +0100, Robert Watson wrote:
>
> Dear all,
>
> Attached, please find a patch implementing more fine-grained locking for
> the POSIX local socket subsystem (UNIX domain socket subsystem).
Dear Sir,
Per your request, please find attached the results of my measur
On Sun, May 07, 2006 at 07:16:34PM +0100, Robert Watson wrote:
>
> On Sun, 7 May 2006, Sven Petai wrote:
>
> >I performed tests on a 4 * dualcore 2Ghz opteron system (so 8 cores in
> >total).
> >
> >In general with 10 parallel smacker threads the performance seems to go up
> >with your patch by
On Sun, May 07, 2006 at 10:00:41PM +0300, Sven Petai wrote:
> The results in my mail were mean values over 2 runs,
> only once did I see really huge (more than 10%) differences between several
> subsequent runs with same settings, this case was clearly mentioned in the
> results.
FYI, 2 is not
On Sun, May 07, 2006 at 08:57:21PM +0100, Robert Watson wrote:
>
> >On Sun, May 07, 2006 at 10:00:41PM +0300, Sven Petai wrote:
> >
> >>The results in my mail were mean values over 2 runs,
> >>only once did I see really huge (more than 10%) differences between
> >>several
> >>subsequent runs with
On Sun, May 07, 2006 at 11:27:22PM +0300, Sven Petai wrote:
> On Sunday 07 May 2006 22:16, you wrote:
> > On Sun, May 07, 2006 at 10:00:41PM +0300, Sven Petai wrote:
> > > The results in my mail were mean values over 2 runs,
> > > only once did I see really huge (more than 10%) differences between
On Sat, May 06, 2006 at 06:19:08PM -0400, Kris Kennaway wrote:
> x norwatson-8
> + rwatson-8
> ++
> | + |
> | + + +
On Sun, May 07, 2006 at 05:04:26PM -0400, Kris Kennaway wrote:
> >477 23472709 2810986 8 5671248 1900047
> > kern/kern_synch.c:220 (process lock)
> >
> > The top 10 heavily contended mutexes are very different (but note the
> > number o
On Sun, May 07, 2006 at 05:41:53PM -0400, Kris Kennaway wrote:
> static int
> kern_sigtimedwait(struct thread *td, sigset_t waitset, ksiginfo_t *ksi,
> struct timespec *timeout)
> {
> ...
> td->td_sigmask = savedmask;
> SIGSETNAND
On Mon, May 08, 2006 at 07:22:06AM +0800, David Xu wrote:
> On Monday 08 May 2006 07:04, Kris Kennaway wrote:
>
> > i.e. apparently not a large difference, but still a large proportion
> > of cases where multiple CPUs are woken at once on the same chain.
> >
> > Kr
OK, David's patch fixes the umtx thundering herd (and seems to give a
4-6% boost). I also fixed a thundering herd in FILEDESC_UNLOCK (which
was also waking up 2-7 CPUs at once about 30% of the time) by doing
s/wakeup/wakeup_one/. This did not seem to give a performance impact
on this test though.
On Mon, May 08, 2006 at 06:43:31PM +0800, David Xu wrote:
> On Monday 08 May 2006 14:52, Kris Kennaway wrote:
> > OK, David's patch fixes the umtx thundering herd (and seems to give a
> > 4-6% boost). I also fixed a thundering herd in FILEDESC_UNLOCK (which
> > was also
On Tue, May 09, 2006 at 03:34:59AM +0300, Sven Petai wrote:
> > Hmm, with this patch mysql 4.1 seems to crash at startup. I haven't
> > yet had time to investigate. Is anyone else seeing this?
> >
>
> Seems to run fine here with 4.1.18 on amd64, but doesn't seem to make much
> difference though
On Mon, May 08, 2006 at 02:52:07AM -0400, Kris Kennaway wrote:
> OK, David's patch fixes the umtx thundering herd (and seems to give a
> 4-6% boost). I also fixed a thundering herd in FILEDESC_UNLOCK (which
> was also waking up 2-7 CPUs at once about 30% of the time) by do
On Mon, May 08, 2006 at 08:43:28PM -0400, Kris Kennaway wrote:
> On Mon, May 08, 2006 at 02:52:07AM -0400, Kris Kennaway wrote:
> > OK, David's patch fixes the umtx thundering herd (and seems to give a
> > 4-6% boost). I also fixed a thundering herd in FILEDESC_UNLOCK (which
On Mon, May 08, 2006 at 06:18:18PM -0700, Maxim Sobolev wrote:
> Kris Kennaway wrote:
> >On Mon, May 08, 2006 at 02:52:07AM -0400, Kris Kennaway wrote:
> >>OK, David's patch fixes the umtx thundering herd (and seems to give a
> >>4-6% boost). I also fixed a th
On Tue, May 09, 2006 at 06:18:11PM +0300, Sven Petai wrote:
> On Tuesday 09 May 2006 03:42, Kris Kennaway wrote:
> > On Tue, May 09, 2006 at 03:34:59AM +0300, Sven Petai wrote:
> > > > Hmm, with this patch mysql 4.1 seems to crash at startup. I haven't
> > >
On Tue, May 09, 2006 at 11:13:02AM -0700, Greg 'groggy' Lehey wrote:
> On Monday, 8 May 2006 at 21:11:09 -0400, Kris Kennaway wrote:
> > On Mon, May 08, 2006 at 08:43:28PM -0400, Kris Kennaway wrote:
> >> On Mon, May 08, 2006 at 02:52:07AM -0400, Kris Kennaway wrote:
&
I set up supersmack against postgresql 8.1 from ports (default config)
on a 12 CPU E4500. It scales and performs somewhat better than mysql
on this machine (which is heavily limited by contention between
threads in a process), but there are a number of obvious performance
bottlenecks:
* The postg
On Sun, Jun 11, 2006 at 01:45:28PM -0400, Kris Kennaway wrote:
> I set up supersmack against postgresql 8.1 from ports (default config)
> on a 12 CPU E4500. It scales and performs somewhat better than mysql
> on this machine (which is heavily limited by contention between
> threads
On Sun, Jun 11, 2006 at 04:31:44PM -0400, Kris Kennaway wrote:
> On Sun, Jun 11, 2006 at 01:45:28PM -0400, Kris Kennaway wrote:
> > I set up supersmack against postgresql 8.1 from ports (default config)
> > on a 12 CPU E4500. It scales and performs somewhat better than mysql
>
On Mon, Jun 12, 2006 at 09:08:12PM +0100, Robert Watson wrote:
> On Mon, 12 Jun 2006, Scott Long wrote:
>
> >I run a number of high-load production systems that do a lot of network
> >and filesystem activity, all with HZ set to 100. It has also been shown
> >in the past that certain things in t
On Tue, Jun 13, 2006 at 12:57:38PM -0700, Danial Thom wrote:
> Since everyone agrees that the load measuring
> tools aren't all that accurate, what criteria was
> used to determine that the changes made in 7 have
> the effect that you think they have had?
Not by using top(1). vmstat seems to do
On Fri, Jul 14, 2006 at 05:20:00PM +0800, etalk etalk wrote:
>I did some test about io performance of bsd6.1 and bsd5.3 on amd64
> machine , and i didn't see any obvious performance's improvement .
>Is there anybody know how about the performance improvement of bsd6.1
> when comparing to
On Thu, Oct 12, 2006 at 11:25:48AM +0200, Oliver Fromme wrote:
> Jerry Bell wrote:
> > I have a Dell PE2950 with 2 dual core 3.73Ghz processors and 4G of ram.
> > [...]
> > changed the clock to TSC
>
> As far as I know, it is unsafe to use TSC on SMP systems.
>
> Or did that change recently?
On Thu, Oct 12, 2006 at 05:17:31PM -0500, Derrick T. Woolworth wrote:
> Where are the numbers for this? Where is the proof? Are you using
> CARP and PF in the 4.x kernel? Are you using UNIX sockets in 4.x?
>
> The fact that your claims haven't been substantiated leads me to
> believe you're not
On Fri, Oct 13, 2006 at 11:49:04AM -0700, Chuck Swiger wrote:
> On Oct 13, 2006, at 11:26 AM, Eric Hodel wrote:
> >>>Or did that change recently?
> >>
> >>It's only on certain systems, apparently.
> >
> >Is there a list of systems where it is safe to use the TSC with
> >SMP? Or some script we ca
On Fri, Oct 13, 2006 at 01:34:36PM -0700, Danial Thom wrote:
> Yeah, bury your head in the sand as always.
>
> Its been proven over and over. Robert Watson has
> admitted many times that 6.x is not as fast as
> 4.x uniprocessor
FOR CERTAIN TASKS. Your (misquoted) claim is demonstrably false in
On Mon, Oct 16, 2006 at 07:05:28PM +0100, Chris wrote:
> On 15/10/06, Eric Hodel <[EMAIL PROTECTED]> wrote:
> >On Oct 13, 2006, at 1:13 PM, Kris Kennaway wrote:
> >> On Fri, Oct 13, 2006 at 11:49:04AM -0700, Chuck Swiger wrote:
> >>> On Oct 13, 2006, at 11:26 A
On Wed, Oct 25, 2006 at 08:56:27AM -0500, Dave wrote:
> On Oct 25, 2006, at 4:50 AM, [EMAIL PROTECTED] wrote:
>
> >At Tue, 24 Oct 2006 21:59:57 -0500,
> >[EMAIL PROTECTED] wrote:
> >>
> >>I am running some performance tests on named to see how it performs
> >>with different configurations on FreeB
On Sat, Jan 13, 2007 at 09:53:47AM -0200, Michel Santos wrote:
> I forgot to say that I tried it already. Even if it gave me no improvement
> I have it in 16 at this time together with a higher vfs.ufs.dirhash_maxmem
> value.
>
> Sincerley, any of the configuration changes I did gave me absolutel
On Sat, Jan 13, 2007 at 03:41:21PM -0200, Michel Santos wrote:
>
> Kris Kennaway disse na ultima mensagem:
> > On Sat, Jan 13, 2007 at 09:53:47AM -0200, Michel Santos wrote:
> >
> >> I forgot to say that I tried it already. Even if it gave me no
> >> improveme
On Sat, Jan 13, 2007 at 04:58:06PM -0200, Michel Santos wrote:
> I have two server, the main server is a Supermicro Dualcore Dual Opteron
> and the backup is a Athlon64 X2, both with 4GB
>
> The disks are the same, only the onboard SCSI is Adaptec and the other is
> LSI. Funny is that I have no d
On Sat, Jan 13, 2007 at 05:23:39PM -0200, Michel Santos wrote:
> >> kernel config
> >> http://suporte.lucenet.com.br/ms/kernel62
> >
> > optionsSCHED_ULE # ULE scheduler
> >
> > From the NOTES file from where you copied this:
> >
> > # SCHED_ULE is a new scheduler that has be
On Fri, Feb 23, 2007 at 07:32:28PM -0500, Francisco Reyes wrote:
> Steven Hartland writes:
>
> >The software we will be running is vBulletin so apache +
> >php and mysql.
>
> Mysql is thread based. Quadcore will not help the DB side. Will help with
> the other components though, if you host ever
Now that the goals of the SMPng project are complete, for the past
year or more several of us have been working hard on profiling FreeBSD
in various multiprocessor workloads, and looking for performance
bottlenecks to be optimized.
We have recently made significant progress on optimizing for MySQL
On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote:
> Kris Kennaway wrote:
> >
> >This shows the graph of MySQL transactions/second performed by a
> >multi-threaded client workload against a local MySQL database with
> >varying numbers of client threads,
On Sun, Feb 25, 2007 at 10:41:17AM +0200, Petri Helenius wrote:
> Kris Kennaway wrote:
> >On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote:
> >
> >>Kris Kennaway wrote:
> >>
> >>>This shows the graph of MySQL transactions/sec
On Sun, Feb 25, 2007 at 11:08:20AM +0100, Ivan Voras wrote:
> Kris Kennaway wrote:
>
> >>>> How does that compare to 6.2-RELEASE performance?
> >>>>
> >>> Much better. Fixing filedesc locking was key.
> >>>
> >>>
>
On Sun, Feb 25, 2007 at 11:16:54AM -0500, Francisco Reyes wrote:
> Kris Kennaway writes:
>
> >Actually it will help the DB side, when you have multiple simultaneous
> >transactions - that's the point :)
>
> A little confused.
> Does this mean FreeBSD will spli
On Sun, Feb 25, 2007 at 08:22:39PM +0100, Jeremie Le Hen wrote:
> Hi, Kris,
>
> On Sat, Feb 24, 2007 at 04:55:08PM -0500, Kris Kennaway wrote:
> > Now that the goals of the SMPng project are complete, for the past
> > year or more several of us have been working hard on pro
On Sun, Feb 25, 2007 at 09:15:40PM +0100, Ivan Voras wrote:
> Kris Kennaway wrote:
>
> > 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my
> > webpage linked there) are unlikely to differ much: as I said, filedesc
> > locking was key to fixing perform
On Sun, Feb 25, 2007 at 10:26:18PM +0200, Petri Helenius wrote:
> Kris Kennaway wrote:
> >
> >I'm saying that the 7.0-CVS sources, which are graphed, are unlikely
> >to differ significantly from 6.2-CVS, i.e. they do not show good
> >scaling on this benchmark becau
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim. i.e. there is a thunde
On Mon, Feb 26, 2007 at 09:36:44AM -0800, Andrew Hammond wrote:
> Would you guys mind
> graphing the relative performance of PostgreSQL on 6.2-RELEASE and
> your patched version please?
postgresql currently performs worse than mysql on SMP freeBSD systems
for the reason I posted yesterday (thunde
On Wed, Mar 14, 2007 at 09:42:00AM +0300, Boris Samorodov wrote:
> (transferring the thread from freebsd-stable@ to freebsd-performance@)
>
> On Tue, 13 Mar 2007 20:55:46 -0400 Kris Kennaway wrote:
>
> > On the same test postgresql is indeed faster, I haven't finished
On Wed, Mar 14, 2007 at 10:29:36AM +0300, Boris Samorodov wrote:
> On Wed, 14 Mar 2007 03:16:10 -0400 Kris Kennaway wrote:
> > On Wed, Mar 14, 2007 at 09:42:00AM +0300, Boris Samorodov wrote:
> > > On Tue, 13 Mar 2007 20:55:46 -0400 Kris Kennaway wrote:
> > >
> >
On Wed, Mar 14, 2007 at 06:47:23AM -0400, Mike Tancsa wrote:
> At 03:16 AM 3/14/2007, Kris Kennaway wrote:
>
>
> >On the pgsql side, disable the update_process_titles option (or
> >whatever it is called), because this has a 33% performance overhead
>
> Hi,
>
On Wed, Mar 14, 2007 at 07:41:47PM +0100, Edwin Mons wrote:
> Angelo wrote:
> > Hi,
> >
> > Can somebody give more information about this update_process_titles
> > setting?
> > I suppose there is a mispell and Google is not really helping with 3
> > results
> > in Polish!
> >
> > Thanks,
> > Angelo
On Thu, Mar 15, 2007 at 06:37:31PM -0300, Marcelo Gardini do Amaral wrote:
> Hi,
>
> I repeated that performance test done with bind [1] using now Robert's
> MFC [2]. Another tweak that I was supposed to do was to use libthr
> instead of libpthread (via libmap.conf) and build bind with threads
>
On Tue, Apr 10, 2007 at 12:04:32AM -0400, Kevin Way wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on the
&
On Tue, Apr 10, 2007 at 10:41:04PM +1200, Mark Kirkwood wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on
On Tue, Apr 10, 2007 at 10:23:42AM -0400, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > Kris Kennaway wrote:
> >> If so, then your task is the following:
> >>
> >> Make SYSV semaphores less dumb about process wakeups. Currently
>
On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> >>> Make SYSV semaphores less dumb about process wakeups. Currently
> >>> whenever the semaphore state changes, all processes sleeping on the
> >>&
On Tue, Apr 10, 2007 at 03:52:00PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
> >> Oh, I'm sure the BSD kernel acts as you describe. But Mark's point is
> >> that Postg
On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > I have not studied the exact code path, but there are indeed multiple
> > wakeups happening from the semaphore code (as many as the number of
> > active postgresql
On Tue, Apr 10, 2007 at 06:26:37PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
> >> Anyway I'd be interested to know what the test case is, and which PG
> >> version you wer
On Tue, Apr 17, 2007 at 02:51:55PM -0400, Kevin Way wrote:
> I built 7.0 as of 6 days ago, and ran the same test using 8-cores, ULE
> and 4BSD. The results are available at:
>
> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
>
> Unfortunately, I can't run t
On Thu, Apr 19, 2007 at 12:32:53PM +1000, Michael Vince wrote:
> Hey All,
> I been benchmarking Diablo Java under AMD64 on 6.2R and using the same
> methods I posted a while ago detailed somewhat here
> http://lists.freebsd.org/pipermail/freebsd-java/2006-August/005576.html
>
> The difference her
On Fri, Apr 20, 2007 at 04:59:12PM +1000, Michael Vince wrote:
> Kris Kennaway wrote:
> >On Thu, Apr 19, 2007 at 12:32:53PM +1000, Michael Vince wrote:
> >
> >>Hey All,
> >>I been benchmarking Diablo Java under AMD64 on 6.2R and using the same
> >>meth
On Fri, Apr 20, 2007 at 12:13:19PM -0700, Sean McNeil wrote:
> Greg Lewis wrote:
> >On Fri, Apr 20, 2007 at 03:09:34AM -0400, Kris Kennaway wrote:
> >
> >>On Fri, Apr 20, 2007 at 04:59:12PM +1000, Michael Vince wrote:
> >>
> >>>Kris Kennaway wro
On Wed, May 16, 2007 at 12:08:24PM -0400, Andrew Edwards wrote:
> I have a system running a dual intel zeon 2.8Ghz with 4G of ram and
> using an intel raid controller model SRCU42X which uses the amr driver.
> I have had this server running 5.4 upgraded to 6.2 and was running fine
> for several mon
On Wed, May 16, 2007 at 01:16:27PM -0400, Andrew Edwards wrote:
> Here's the backtrace from the last crash along with the output from show
> alllocks when the system was deadlocked. I have been running
> 6.2-release and compliled with makeoptions debug=-g, invariants,
> invariant_support and witne
On Fri, Jun 01, 2007 at 04:45:47PM -0300, NOC Meganet wrote:
> On Friday 01 June 2007 11:30:24 Arne W?rner wrote:
> > --- NOC Prowip <[EMAIL PROTECTED]> wrote:
> > > > Why d?nt u use glabel?
> > >
> > > hmm, I never considered it
> > > but I guess it does not solve my problem because let's say da0
On Wed, Jun 06, 2007 at 10:52:58AM +0700, binto wrote:
> did anyone could tell me, useful command to check bsd performance?
> sorry, me, just a newbie
"Performance" is not a well-defined term, so you need to first ask a
more focused question :)
Kris
___
I have been benchmarking BIND 9.4.1 recursive query performance on an
8-core opteron, using the resperf utility (dns/dnsperf in ports). The
query data set was taken from www.freebsd.org's httpd-access.log with
some of the highly aggressive robot IP addresses pruned out (to avoid
huge numbers of re
On Thu, Jun 14, 2007 at 09:36:55AM -0300, NOC Meganet wrote:
> On Thursday 14 June 2007 05:48:17 Kris Kennaway wrote:
> > 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is
> > broken in 6.x).
>
> just curious what is broken because I use ULE on several ser
On Thu, Jun 14, 2007 at 04:53:01PM -0700, Chuck Swiger wrote:
> Hi, Kris--
>
> This was interesting, thanks for putting together the testing and
> graphs.
>
> On Jun 14, 2007, at 1:48 AM, Kris Kennaway wrote:
> >I have been benchmarking BIND 9.4.1 recursive query per
I did some benchmarking of sysbench in read-write mode (previous tests
have focused on read-only mode). The reason for this is that the disk
hardware in my 8-core test system is slow (single disk) and is too
easily saturated. In fact mysql and pgsql have identical performance
when writing to disk
Alfred Perlstein wrote:
Palle,
I really haven't kept pace with Intel versus AMD in a while, my
understanding is that AMD is still the only 64bit game in town.
For a database, the more memory you can get, the better.
I've found many machines with 4 gigs of ram to not be enough to
get decent per
Alfred Perlstein wrote:
* Kris Kennaway <[EMAIL PROTECTED]> [070910 16:32] wrote:
Alfred Perlstein wrote:
Palle,
I really haven't kept pace with Intel versus AMD in a while, my
understanding is that AMD is still the only 64bit game in town.
For a database, the more memory you c
Hi,
I have been running the volano java benchmark
(http://www.volano.com/benchmarks.html) on an 8-core i386 system, and
out of the box jdk15 on FreeBSD performs extremely poorly. The system
is more than 90% idle, and profiling shows that the ~800 threads in the
benchmark are spending most of
Daniel Eischen wrote:
When I removed this hack (i.e. revert to pthread_yield()) I got an
immediate 7-fold performance increase, which brings FreeBSD
performance on par with Solaris.
What is the reason why this code is necessary? Does FreeBSD's
sched_yield() really have different semantics t
Kurt Miller wrote:
On Saturday 15 September 2007 10:50:50 pm Kurt Miller wrote:
The following are programs I wrote when I isolated the problem.
If the c program runs ok on 7.0 for both single cpu and mp then
remove the os_sleep() and try the java program. If that works too
then you're clear to m
Kurt Miller wrote:
David Xu confirmed for me that pthread_yield() does give some
time to lower priority threads on 7.0 using thr. Attached and inline
are two patches for the 1.5 port that is how I suggest the issue be
addressed.
For 7.0 and up default UseThreadPriorities to true and always
use p
Kurt Miller wrote:
On Tuesday 18 September 2007 03:17:14 pm Kris Kennaway wrote:
Kurt Miller wrote:
David Xu confirmed for me that pthread_yield() does give some
time to lower priority threads on 7.0 using thr. Attached and inline
are two patches for the 1.5 port that is how I suggest the
Josh Carroll wrote:
Hello,
I posted this to the stable mailing list, as I thought it was
pertinent there, but I think it will get better attention here. So I
apologize in advance for cross-posting if this is a faux pas. :)
Anyway, in summary, ULE is about 5-6 % slower than 4BSD for two
workload
Josh Carroll wrote:
ffmpeg: 1:38.885
sysbench: (4,8,12,16 threads respectively):
2221.93
2327.87
2292.49
2269.29
And buildworld: 13m47.052s
I ran these after changing the slice value to 7 as well with this patch.
ffmpeg: 1:38.547
BTW, it doesn't make much sense to be measurin
Steven Hartland wrote:
Some interesting comments here:
http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=10
Indeed, mysql 5.0 has poor scaling compared to postgresql (this affects
reads but severely affects writes). However when I tested the latest
beta of 5.1 about 6 months ago I found it h
Alfred Perlstein wrote:
* Kris Kennaway <[EMAIL PROTECTED]> [071128 11:13] wrote:
Steven Hartland wrote:
Some interesting comments here:
http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=10
Indeed, mysql 5.0 has poor scaling compared to postgresql (this affects
reads but severe
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
Philipp Wuensche wrote:
Adrian Chadd wrote:
On 05/12/2007, Philipp Wuensche <[EMAIL PROTECTED]> wrote:
As I understand it, and correct me if I'm wrong, polling helps against
high interrupt rates but for that intel gigabit cards have interrupt
moderation. We don't have a problem with interrupts
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
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&#
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
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
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
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 th
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:
G
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
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 GENER
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
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.
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
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
Hi,
Some months ago someone on this list offered to provide to me a data set
of DNS query data and the corresponding zone file for benchmarking of
BIND performance as an authoritative server. Unfortunately I have lost
the email and forgot who it was who made the offer :) If it was you,
plea
Erik Cederstrand wrote:
Hi
I'd like to send a small update on my progress on the Performance
Tracker project.
I now have a small setup of a server and a slave chugging along,
currently collecting data. I'm following CURRENT and collecting results
from super-smack and unixbench.
The projec
Erik Cederstrand wrote:
Kris Kennaway wrote:
This is coming along very nicely indeed!
One suggestion I have is that as more metrics are added it becomes
important for an "at a glance" overview of changes so we can monitor
for performance improvements and regressions among many
Robert Watson wrote:
I think it's best if participating machines supply data regularly for
an extended period of time. Single or infrequent data points for a
specific configuration don't make much sense. We need to compare
apples to apples.
Yes -- I was mostly thinking about backdating in or
Kris Kennaway wrote:
P.S. If I understand correctly, the float test shows a regression?
The metric is calculations/second, so higher = better?
The documentation on Unixbench is scarce, but I would think so.
Interesting. Some candidate changes from 2007-10-02:
Modified files
1 - 100 of 154 matches
Mail list logo
