Vladimir Ostrovsky created CLOUDSTACK-1309:
----------------------------------------------
Summary: Large guest subnet downgrade performance
Key: CLOUDSTACK-1309
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1309
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: pre-4.0.0
Environment: CloudStack version: 3.0.5.20120904142539
MySQL server version: 5.1.61-4.el6
Reporter: Vladimir Ostrovsky
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?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
