Hi Biping!
On Thu, Jul 30, 2009 at 04:24:15PM +0800, Biping MENG wrote:
> The results have just come out! But it seems the patch can in no way
> overcome the weak point of pool of threads on readwrite workloads. It
> took extremely long time to finish the iterations at high concurrency
> levels. Data in the last part of the result table could really be
> described as awful:(.
Indeed. It would be interesting to get a detailed profile at the higher
concurrency rates to see where time is being spent. Is the thread/lock
contention causing that much wasted time in the kernel? Something
strange happing with I/O? Some busy waits getting out of control
somewhere? It might be work taking some time to profile this and
maybe look for ways to improve the performance.
> Ah, Great! That will be very helpful! Thanks a lot for the offering! :)
> One point that might be important is that as I mentioned above, 16 core
> machine may be unfair for pool-of-thread scheduling, for only 8 out of 16
> cores will be used.
> The size of the pool is currently hard coded as follow:
>
> static DRIZZLE_SYSVAR_UINT(size, size,
> PLUGIN_VAR_RQCMDARG,
> N_("Size of Pool."),
> NULL, NULL, 8, 1, 1024, 0);
> I strongly suggest that the size of pool should be settable when drizzled
> is started (like providing an option --pool-size=XXX) so as to fit in
> different machines. How do you think about it?
You can do this now, the option is:
--pool-of-threads-size=#
Size of Pool.
Great work!
-Eric
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
