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