[Maria-discuss] MariaDB and Sun CoolThread
Hi all,
I am installing MariaDB on a server Sun/Oracle T5140 with CoolThread/ CMT technology.
This server has two physical Sparc CPU with 48 1165MHZ virtual processors each. However, it's look like that MariaDB is performing much better on my MacBook Pro when compared against this server.
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?
Thank you all
Alex
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.
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
Hi Mark,
It makes sense. Thanks.
Alex
Em 04/04/2011, às 10:55, MARK CALLAGHAN escreveu:
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.
On Tue, Apr 5, 2011 at 5:50 AM, Arjen Lentz arjen@openquery.com wrote:
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.
Stephane (now at SkySQL) told me he had used Spider engine as a hack to get parallel query processing across partitions. Ie you can use spider even if you have just one physical host, and it will process the query against each partition in parallel.
henrik
participants (5)
-
Alexandre Almeida -
Arjen Lentz -
Henrik Ingo -
Kristian Nielsen -
MARK CALLAGHAN