directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Benchmarks feedback
Date Tue, 27 Mar 2007 02:38:12 GMT
I subscribed to your list so you won't have to copy me.

I'd do a couple of things.  The system is Hyperthreaded so you have  
"16" CPUs.  I'll reboot the system and go back to 8 real cores just  
to make sure hyperthreading isn't a cause.  I'll do that tonight if  
no one is on the system.

Next, I've used the IBM VM for this kind of analysis as it has a Java  
Lock monitor built in that will help to identify hot locks that might  
be causing the scaling problem.

The next thing we can do is I have a hardware profiler on the system  
that is similar to VTune that is most excellent at tracking CPU, time  
in method, etc.  I need to recompile the kernel so this will take a  
few days.

So if you want to take this baby for another spin around the block,  
let me know.  I'll get some instructions on setting up the lock monitor.

Nice to know my basement is getting warmed for good reason :)

Matt

On Mar 26, 2007, at 4:52 PM, Emmanuel Lecharny wrote:

> Hi,
>
> I have done some benchmarks on the powerfull server on which Matt  
> was kind enough to give me an access (8 dual core CPUs, 11 131  
> mogomips, 20 Gb mem !).
>
> The results are pretty preliminary, and a little bit disappointing.  
> Here are the tests I did :
>
> - 4 clients requesting the server;
> - each client doing 10 000 random requests for each run;
> - 12 runs for each client with a fixed number of thread;
> - a number of thread being 1, 2, 4, 5, 8, 10, 20 and 50.
>
> the best result I reached was around 1600 req/s, CPU peaked to 300  
> % (which means that no more than 3 cpus out of 16 where used), a  
> maximum of 20% total CPU out of which 2,5% system. Not exactly  
> brillant.
>
> I would have excpected that the CPU would have been more working  
> more, so I guess something is wrong (contention, or not enough  
> threads, or threads not being distributed enough, or simply not  
> enough clients ).
>
> The last point (not enough client) should not be the reason : with  
> only one client, I almost reached the same level of performance,  
> and each new client added does not make a lot of difference (maybe  
> 10% more requests being fulfilled ...)
>
> I don't think either that threads are not correctly distributed on  
> the CPUs, because I tried with Sun JVM and Jrockit, and I get  
> similar results, always above 250% (which means that threads are  
> really distributed). However, I have no idea on how to know which  
> CPU is a thread running on (any clue ?)
>
> So, contention. I did some other tests :
> 1) always requesting the same entry
> 2) requesting the rootDSE only
>
> Both tests should be running without any disk access (any idea on  
> how to get some info about disk access, btw ?). Here are the  
> results (same clients, same number of requests
> 1) same entry : around 4500 req/s, which is 3 times the number with  
> random searches. CPU peaked to 400%, no more...
> 2) rootDSE : 11500 req/s. Same CPU peak.
>
> I have one more test to run, I want to setup a higher cache size,  
> to see if it has some impact on the first scenario results.
>
> Ok, I will really appreciates any idea, any suggestion, any  
> information whcih can help to find out why we are so limited.
>
> Thanks a lot for the server, Matt, this is really helpfull ! You  
> will deserve a bunch of beers in may :) (let's say one beer for  
> eacj thousand requests per second we can get :)
>
> Emmanuel
>


Mime
View raw message