Re: mysql scaling questions

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 kernel
(vnode interlock and lockbuilder mtxpool). Does it not do any
caching of the data in userspace but relies on querying into the
kernel every time? innodb doesn't have this behaviour.
Sorry, but was this a rethorical kind of question, or was this
addressed to me? :)
If the later, then how do I find this out?
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 for software developed for Linux? I mean assuming
syscalls are cheap; for example: gettimeofday(2), settitle(2), etc. I
don't think the applications should be blamed for relying on performance
optimizations not present in FreeBSD. Saying applications must do their
own caching instead of relying on the kernel and need to avoid
concurrent accesses to the same file seems like a doctrine from the dark
ages.

Why? Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary trips
into the kernel is in no sense a "doctrine from the dark ages". Besides, if my hypothesis about the problem is correct then mysql
itself does this with the alternate innodb backend anyway.
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 amd64/x86_64. On 32bit x86 platforms our syscalls cost about 750 cycles more due to using int0x80. Various patches have been around for a while to implement sysenter/sysexit support but it's difficult to get compatibility right and probably not worth it now that everyone is moving to 64bit.

Cheers,
Jeff


Sincerely,

Gergely Czuczy
mailto: gergely.czuczy@xxxxxxxxxxx

--
Weenies test. Geniuses solve problems that arise.

_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: mysql scaling questions
    ... same file which is running into exclusive locking in the kernel ... improve caching of the data in userland then performance should improve. ... Isn't this common for software developed for Linux? ... into the kernel is in no sense a "doctrine from the dark ages". ...
    (freebsd-performance)
  • Re: mysql scaling questions
    ... same file which is running into exclusive locking in the kernel ... improve caching of the data in userland then performance should improve. ... Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary trips into the kernel is in no sense a "doctrine from the dark ages". ...
    (freebsd-performance)
  • Re: mysql scaling questions
    ... Gergely CZUCZY wrote: ... basicall that's everything. ... Does it not do any caching of the data in userspace but relies on querying into the kernel every time? ... If it can be made to improve caching of the data in userland then performance should improve. ...
    (freebsd-performance)
  • Re: IIS6, ASP.NET and Kernel Caching
    ... If ASP.Net or any other handler is scriptmapped to handle the resource, ... declarative kernel response caching, but only if you ask for it in the ASPX ... on the originating server ...
    (microsoft.public.inetserver.iis)
  • Re: Ruby-specific performance heuristics?
    ... require 'tempfile' # ... middle of a 40MB image but nothing else - the kernel will only read/write the ... - compose things out of array, hashes, and strings whenever possible. ... One case that stood out was caching results of floating point calculations involving roots: ...
    (comp.lang.ruby)