Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
pre-4.0.0
-
Security Level: Public (Anyone can view this level - this is the default.)
-
None
-
CloudStack version: 3.0.5.20120904142539
MySQL server version: 5.1.61-4.el6
Description
When guest network / VLAN is defined in CloudStack, a separate record is created in the cloud.user_ip_address table for each address in the range, even if it isn't really allocated.
As a result, if a very wide subnet is defined (say, Class B), then the table contains at least 65534 records.
On a system with 5 such Class B VLANs defined, the size of the table grew to more than 327670 records. This caused mysqld to spend about 95-99% of its time in Waiting state and efficiently stuck the CloudStack.
top - 11:58:43 up 2:25, 3 users, load average: 2.91, 2.71, 2.21
Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.8%us, 0.4%sy, 0.0%ni, 1.8%id, 95.7%wa, 0.0%hi, 0.4%si, 0.0%st
When I tried to delete such network, the operation lasted about an hour.
It obviously doesn't seem to be limitation of MySQL itself; I suspect that CloudStack's algorythms working with this table are pretty inefficient and aren't built to the case of huge number of addresses. Am I right?
