You are here

memory

MySQL Cluster analysis for foodmart

Undefined

This is an automated analysis of the DBI:mysql:database=foodmart;host=localhost database for migration into MySQL Cluster. No warranty is made to the accuracy of the information.

This information should be valid for MySQL 4.1 and 5.0. Since 5.1 is not a final release yet, the numbers should be used as a guide only.

MySQL Cluster memory sizing

English

MySQL Cluster is pretty fast. The reason for this is, that it is completly memory based. Nowadays memory is still, in contrary to disk, limited to your systems. Thus, before installing a MySQL Cluster you have to calculate the amount of memory you need.

To say it in advance: You should consider to only use 64-bit Linux system with huge amount (4 - 64 GB) of RAM!

In release 5.1 MySQL Cluster became disk based. Now you have the possibility to swap out some data to disk. How much it is we will probably see a little further down...

Reading other processes memory

English

As you probably have experienced yet MySQL does not always provide all internal information as you might want to have them and as you are used to have from other RDBMS.

MySQL plans to improve this implementing the/a performance schema and its probably already partly done in MySQL 5.4. But who knows when this will be finished and what it contains at all...

FromDual consulting tool collection

Undefined

The following tools we use sometimes for our consulting engagements...

Caution: These tools are NOT for production use! Use with care!

Reading other processes memory

Taxonomy upgrade extras: 

As you probably have experienced yet MySQL does not always provide all internal information as you might want to have them and as you are used to have from other RDBMS.

MySQL plans to improve this implementing the/a performance schema and its probably already partly done in MySQL 5.4. But who knows when this will be finished and what it contains at all...

Possible memory leak in NDB-API applications?

Taxonomy upgrade extras: 

A customer has recently experienced a possible memory leak in its NDB-API application. What he did was something like:

# ps aux | grep <pid>

over time and then he saw the RSS increasing. When he would have had a look a little longer he would have seen that the RSS consumption would increase up to a certain level and then becomes stable. Which is the expected behavior.

Possible Memory Leak

Subscribe to RSS - memory