14 messages in com.mysql.lists.clusterRe: DataMemory Strange Behaviour| From | Sent On | Attachments |
|---|---|---|
| Adam Dixon | 24 Jul 2005 20:20 | |
| Mikael Ronström | 25 Jul 2005 01:34 | |
| Matthew Glubb | 25 Jul 2005 01:46 | |
| Mikael Ronström | 25 Jul 2005 01:59 | |
| Matthew Glubb | 25 Jul 2005 02:12 | |
| Adam Dixon | 25 Jul 2005 03:09 | |
| Mikael Ronström | 25 Jul 2005 03:17 | |
| Matthew Glubb | 25 Jul 2005 03:20 | |
| Matthew Glubb | 25 Jul 2005 03:40 | |
| Jonas Oreland | 25 Jul 2005 03:54 | |
| Mikael Ronström | 25 Jul 2005 04:36 | |
| Adam Dixon | 25 Jul 2005 05:11 | |
| Mikael Ronström | 25 Jul 2005 05:52 | |
| Adam Dixon | 25 Jul 2005 06:14 |
| Subject: | Re: DataMemory Strange Behaviour |
|---|---|
| From: | Mikael Ronström (mik...@mysql.com) |
| Date: | 07/25/2005 03:17:11 AM |
| List: | com.mysql.lists.cluster |
Hi,
2005-07-25 kl. 12.09 skrev Adam Dixon:
Matthew Glub wrote:
I'm going to set up mrtg
I have had MRTG running for all my nodes, and for me there was only up to 14mbit of traffic for around about 15 minutes while a node was restarting, and the same for a complete trashing and rebuild. While restart times are relatively slow, the setup of a cluster should mean that no one single event should stop the cluster from being utilized therefore one node having issues causes no problem for the cluster as a whole. So this doesn't concern me much. However, handy to know what exactly the phases are.
On 7/25/05, Mikael Ronström <mik...@mysql.com> wrote:
No, this is correct, the code currently do not return any reorganise data pages to return to pool when deleting records.
So I tried a restart of the whoe cluster, which takes a fair while, and behold it came up with a datausage of 96%
In a node restart, data is currently reorganised and this one way of performing an on-line REORG TABLE sort of.
OK so the cluster does not recalculate the page usage once the pages are consumed by the database. I was under the impression that once DataMemory fills up, since cluster is a diskless solution, no more data entry can be done? Is this so or does it manage free memory in some other fashion.
Pages are reusable after a table has been dropped and the other method of of retrieving pages after a major delete session is a "rolling upgrade" that will reorganise the data such that pages will be completely filled.
Also, if the 'all dump 1000' method never truly comes back down, how can we ever monitor the cluster to see if memory is becoming a problem.
Not sure what you mean here?
Again, after the node restart, the data is reorganised and compacted. Phase 5 is the copy phase when all data is copied from the live node to the starting nodes.
My Cluster on 100mbit switch at the moment, which is a 4ndbdm, 2 replica setup, achieved around 15mbit restore throughput. The systems are all 2x2.8ghz Xeon. Do any of the mgmd config parameters help improve rebuild times and general throughput? However I believe that perhaps there may be a bottleneck in the SATA disk which data may be drawn from during a rebuild? Perhaps this applies to Matt's issues also.
The copy phase involves no disk issues and is currently not configurable but a node restart also involves a local checkpoint and this could be the issue making the restart take a long time if there are slow disks around.
Rgrds Mikael
Adam
-- MySQL Cluster Mailing List For list archives: http://lists.mysql.com/cluster To unsubscribe: http://lists.mysql.com/cluster?unsub=mik...@mysql.com
Mikael Ronstrom, Senior Software Architect MySQL AB, www.mysql.com
Jumpstart your cluster: http://www.mysql.com/consulting/packaged/cluster.html