I now think that lack of NUMA support isn't the problem. I've done some
benchmarking of my database-backed Perl Web app with the Apache benchmark
tool, "ab". I ran the same query with differing total requests and
concurrency. After the first time, which I did manually before the tests,
all the results will be in the database query cache. Therefore, I don't
expect any disk I/O.
The results seem to be significantly slower than they should be. Is this a
problem with my config, the new x86-64 code, SMP stuff, or is it just the
cost of doing business?
This table shows the time in seconds for each request x concurrency and
kernel. There's native with NUMA, native without NUMA, and finally Domain0
(you may want to view this with a fixed font).
NUMA noNUMA Dom0
20x1 44.8 45.5 67.4
20x2 23.2 24.0 36.6
20x3 17.9 18.4 30.2
20x4 13.3 13.5 23.9
20x8 14.6 14.6 23.6
40x2 46.1 47.5 72.8
40x4 25.2 26.6 46.1
40x8 28.7 27.8 40.4
Thanks,
Alex
On Friday 07 October 2005 03:58 am, Keir Fraser wrote:
> On 7 Oct 2005, at 00:09, Nicholas Lee wrote:
> >> Xen 3.0 on it. I've found that I can compile SMP just fine, and it
> >> sees all
> >> four processors, but when I add K8 NUMA, the compile breaks.
> >
> > I just noted this complier breakage as well.
> >
> > Thinking about it, I expect the nature of Xen makes it tricky to get
> > going at the moment.
>
> We have some ideas about how to get this working, but you're right that
> it is not a totally trivial thing to fix. Don't hold your breath until
> at least 3.0 is out the door.
>
> -- Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel