cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abhinandan Prateek (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-1309) Large guest subnets downgrade performance
Date Thu, 19 Sep 2013 08:05:55 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Abhinandan Prateek updated CLOUDSTACK-1309:
-------------------------------------------

    Fix Version/s:     (was: 4.2.0)
                   4.2.1
    
> 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
>            Assignee: Prasanna Santhanam
>             Fix For: 4.2.1
>
>         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 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

Mime
View raw message