|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: Cluster performance with data node down
From: Giulio Ferro <auryn(at)zirakzigil.org>
Date: Sat Aug 25 2007 - 12:47:09 EDT
> Again, from original message:
> -------
> Here's the setup:
> 2 sql node + 2 data node interconnected by a gigabit switch
> used just by the cluster.
> Mysql version : 5.1.20
> Freebsd 6.2 stable amd64 (source update : 2 days ago)
> DataMemory : 6500M
> IndexMemory : 500M
> Tables are created in a tablespace
> Under normal circumstances and after the first query, the performance
> is acceptable : standard select queries in my test db take about .3 /
> .4 sec
> to complete.
> The problems start when I take a data node down (gracefully, with the
> command "<nodeid> stop"). When I do that the time to complete the same
> queries rises to an unacceptable 12 seconds and stays that way.
> Then I start the node again and performances go back to what they
> were before.
> -------
> The query is a simple select on a single table. The tables contains
> about 330.000 entries. The queries executed are like this:
> select * from <tablename> where <varchar_field> = '....';
> select * from <tablename> where <varchar_field> like '%....%';
> <varchar_field> is a varchar(255) and is also an index.
> explain output:
> +----+-------------+----------------+------+---------------+------+---------+------+--------+-----------------------------------+
> +----+-------------+----------------+------+---------------+------+---------+------+--------+-----------------------------------+
> 1 row in set (0.01 sec)
> I hope it helps.
>
Date: Sat Aug 25 2007 - 12:47:09 EDT
Nobody managed to verify this issue?
Giulio Ferro wrote:
> Stewart Smith wrote:
>> On Wed, 2007-08-15 at 20:02 +0200, Giulio Ferro wrote: >> >>> What we are talking about here is a query which on a single machine >>> configuration (no cluster) takes less than .3 sec. to complete. >>> >>> So we have >>> Time to complete select query : >>> *) single machine - no cluster : < 0.3 seconds >>> *) cluster - 2/2 data nodes : < 0.4 seconds >>> *) cluster - 1/2 data nodes : > 12 seconds. >>> >>> What we have here is a configuration without any workload (except >>> the query I execute). As far as I can tell there is no task here which >>> can benefit from parallelization. >>> >>> But even if it were, parallelization could in no way account for a >>> difference in execution of a factor of 30 (12 / 0.4) >>> >>> As a software architect my guess is that here we have something >>> of an anomaly in the way things are managed in a degraded cluster. >>> >>> I could also add data nodes, but unless some of you explains to me >>> how this could really set things right I'm still thinking we are >>> barking >>> at the wrong tree... >>> >> >> What queries? on what tables? on what data set? EXPLAIN output? >> >> cluster configuration? >> >> >
> Again, from original message:
>
> -------
>
> Here's the setup:
> 2 sql node + 2 data node interconnected by a gigabit switch
> used just by the cluster.
> Mysql version : 5.1.20
> Freebsd 6.2 stable amd64 (source update : 2 days ago)
> DataMemory : 6500M
> IndexMemory : 500M
> Tables are created in a tablespace
> >
> Under normal circumstances and after the first query, the performance
> is acceptable : standard select queries in my test db take about .3 /
> .4 sec
> to complete.
>
> The problems start when I take a data node down (gracefully, with the
> command "<nodeid> stop"). When I do that the time to complete the same
> queries rises to an unacceptable 12 seconds and stays that way.
>
> Then I start the node again and performances go back to what they
> were before.
> >
> -------
> >
> The query is a simple select on a single table. The tables contains
> about 330.000 entries. The queries executed are like this:
> select * from <tablename> where <varchar_field> = '....';
> select * from <tablename> where <varchar_field> like '%....%';
>
> <varchar_field> is a varchar(255) and is also an index.
> > >
> explain output:
> +----+-------------+----------------+------+---------------+------+---------+------+--------+-----------------------------------+
>> NULL | NULL | 330122 | Using where with pushed condition |
> | id | select_type | table | type | possible_keys | key |
> key_len | ref | rows | Extra |
> +----+-------------+----------------+------+---------------+------+---------+------+--------+-----------------------------------+
>
> | 1 | SIMPLE | <tablename> | ALL | NULL | NULL |
> +----+-------------+----------------+------+---------------+------+---------+------+--------+-----------------------------------+
>
> 1 row in set (0.01 sec)
> > >
> I hope it helps.
>
-- MySQL Cluster Mailing List For list archives: http://lists.mysql.com/cluster To unsubscribe: http://lists.mysql.com/cluster?unsub=lists@pantek.comReceived on Sat Aug 25 12:48:19 2007
This archive was generated by hypermail 2.1.8 : Sun Oct 07 2007 - 10:15:03 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |