And then because this is Sun CoolThread hardware, each connection runs on really, really slow CPUs. And 48 threads running concurrently will get a lot of mutex contention from MySQL so maybe running 4 copies of mysqld with each instance locked down to 12 CoolThread CPUs will help. On Sun, Apr 3, 2011 at 11:07 PM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:

Alexandre Almeida <alexandre@hti.com.br> writes:

...

      As far as I can see MariaDB stay locked/running on a single virtual  CPU and MariaDB doesn't take advantage of CoolThread/CMT technologies,  I mean it can not run on more than one virtual CPU same time. Result:  poor performance.

      Anybody knows if there is something can I do to spread ;-) MariaDB  all over cpus? Am I missing something?

Each client connection will run on its own cpu. So to use all cpus your application needs to run many queries in parallel.

 - Kristian.

_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to     : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help   : https://help.launchpad.net/ListHelp

-- Mark Callaghan mdcallag@gmail.com

Hi Mark On 04/04/2011, at 11:55 PM, MARK CALLAGHAN wrote:

And then because this is Sun CoolThread hardware, each connection runs on really, really slow CPUs. And 48 threads running concurrently will get a lot of mutex contention from MySQL so maybe running 4 copies of mysqld with each instance locked down to 12 CoolThread CPUs will help.

Yea we look at this a few years back and found that MySQL could not really make effective use of this CPU/thread design at that stage. One potentially useful avenue was the addition of partitioning to 5.1, it was intended in part as a precursor to parallel query processing, for instance have one thread per partition resolving part of a query. This together with the disconnect between connections and threads (pool-of-threads etc) would enable this. Not having looked at the partitioning code, I don't know how much of a leap this would be, architecturally. I do think this is going to be important, more so than other shinies. It would also resolve other workloads such as where you have many (full speed) cores, few connections, but complex queries. Current the right answer for such cases is to pick another RDBMS, but in terms of basic use in such cases, MySQL would generally fit the bill nicely. So that seems like an obvious development target. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery