MySQL Forums
Forum List  »  NDB clusters

Cluster generating heavy traffic
Posted by: Roberto Mendez
Date: March 14, 2005 04:28PM

I currently run a popular website that generates a lot of traffic 600+ mbit/s. I moved to a MySQL Cluster hoping that it can solve some issues for me such as performance, redundancy, scalability.

I have a cluster that is made up of 3 machines, 1 machine for the mgmt_node the other 2 machines are running ndbd and the mysql server.

I have a simple table that contains about 90,000 records that gets updated a few hundred times a minute.

CREATE TABLE `security_keys` (
`authkeys` text,
`insert_time` int(11) unsigned default NULL,
KEY `insert_time` (`insert_time`)
)

it is a very simple table that contains a string of charachters that get generated and deleted often. However once this table reaches about 90,000 records it generates traffic in excess of 400 mbit/s between the two servers that have the ndbd process running. The machines then get really slow (3.x+ load average) because of all the interrupts/context switches that are generated from all the network traffic being recieved on the NIC's. Leaves the system also waiting on I/O. If I remove all the records or never let it get above 1,000 records the traffic is next to nothing 2mbit/s however if I let it run normal I get all those issues.

I am currently just testing the cluster system to see if it will scale to what I need. I will be adding some tables to the system that will contain 300,000+ records and be updated 100's of times a minute. Is this traffic normal between the two machines? If so will purchasing the SCI cards and SCI switches from dolphinics help out? Is anyone else seeing this much load on the systems and issues?

Options: ReplyQuote


Subject
Views
Written By
Posted
Cluster generating heavy traffic
2925
March 14, 2005 04:28PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.