cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-4179) [Performance Testing] Time taken for Deploy VM async job to complete is considerably higher
Date Fri, 09 Aug 2013 10:35:47 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734653#comment-13734653
] 

ASF subversion and git services commented on CLOUDSTACK-4179:
-------------------------------------------------------------

Commit 21c74c6453685736aa8dddd3cbaa535d9157333c in branch refs/heads/4.2 from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=21c74c6 ]

CLOUDSTACK-4179: [Performance Testing] Time taken for Deploy VM async job to complete is considerably
higher
The time increased due to the newly added dedicated resources feature. During regular VM deployment,
all dedicated resources are put in avoid list so that they are not considered for deployment.
Now the way to compute the list of dedicated resources is not optimal and performance deteriorates
in an environment having lot of pods, clusters and hosts as the logic is to query db. for
each suc resource.

The fix is to optimize the logic not to loop through all resources but get the list of each
resource type in a single query.

                
> [Performance Testing] Time taken for Deploy VM async job to complete is considerably
higher
> -------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-4179
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4179
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.2.0
>         Environment: Simulated VMs and hosts, advanced zone, RVR
>            Reporter: Sowmya Krishnan
>            Assignee: Koushik Das
>            Priority: Critical
>             Fix For: 4.2.0
>
>         Attachments: async_job_time.out, job-109.log
>
>
> Following setup is used to create performance test bed:
> Advanced zone, 2 Management Servers, 124 Pods [Each Pod having 2 Clusters]
> 248 Clusters [Each cluster having 8 hosts and one primary storage]
> 2000 Hosts
> 4000 User accounts [Each account having one network]
> ~8000 Virtual Routers
> Following config parameters were used in both the management servers
> - Java heap size = 5 GB
> - db.cloud.maxActive = 250
> - db.cloud.url.params=prepStmtCacheSize=517&cachePrepStmts=true&prepStmtCacheSqlLimit=4096&includeInnodbStatusInDeadlockExceptions=true&logSlowQueries=true
> Tried deploying around 4000 Simulator VMs across 4K accounts. Noticing considerably higher
time for deploy VM async job to complete as compared to baseline results.
> Some of the Baseline results are documented here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baseline+Reports+for+Pre-4.x+Performance+Runs
> On an average, it is now taking 70-80 seconds for deployVM to complete as compared to
10-15 seconds earlier.
> From the logs, it appears in some cases, DeploymentPlanningManager takes time to kick
in.:
> 2013-08-07 01:52:09,785 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-105:job-109
= [ 19ccfecb-c815-497a-9ff1-70d590025af3 ]) Service SecurityGroup is not supported in the
network id=304
> 2013-08-07 01:52:37,288 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-105:job-109
= [ 19ccfecb-c815-497a-9ff1-70d590025af3 ]) Deploy avoids pods: null, clusters: null, hosts:
null
> ...
> ...
> 2013-08-07 01:52:41,199 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-105:job-109
= [ 19ccfecb-c815-497a-9ff1-70d590025af3 ]) Deploy avoids pods:
> null, clusters: null, hosts: null
> 2013-08-07 01:53:19,886 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-105:job-109
= [ 19ccfecb-c815-497a-9ff1-70d590025af3 ]) Deploy avoid
> s pods: null, clusters: null, hosts: null
> Both VRs are running at the end of deploy VM and also the VM.

--
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