[ https://issues.apache.org/jira/browse/CLOUDSTACK-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rohit Yadav reassigned CLOUDSTACK-1309: --------------------------------------- Assignee: (was: Rohit Yadav) > Large guest subnets 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 > Fix For: Future > > Attachments: Large guest subnets in CloudStack.jpg > > > 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 was sent by Atlassian JIRA (v6.4.14#64029)