Bug 718993
| Summary: | [vdsm][storage]refreshStoragePool takes a long time (more than default rhevm timeout) on large scale | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Moran Goldboim <mgoldboi> | ||||
| Component: | vdsm | Assignee: | Eduardo Warszawski <ewarszaw> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Moran Goldboim <mgoldboi> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2 | CC: | abaron, bazulay, danken, hateya, iheim, ilvovsky, ykaul | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | vdsm-4.9-81.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-12-06 07:30:18 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 612978 | ||||||
| Attachments: |
|
||||||
Bug report changed to ON_QA status by me since Errata System refused to do so. A QE request has been submitted for advisory RHEA-2011:11186-01 http://errata.devel.redhat.com/errata/show/11186 verified on 4.9-81. refreshStoragePool operation was shortened drastically after above fix, and now it stands on 2 sec.
attached some logs to prove:
Thread-417::INFO::2011-07-19 15:08:27,844::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Thread-417::INFO::2011-07-19 15:08:29,558::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}}
Thread-494::INFO::2011-07-19 15:10:19,886::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Thread-494::INFO::2011-07-19 15:10:21,534::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}}
Thread-712::INFO::2011-07-19 15:15:55,213::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Thread-712::INFO::2011-07-19 15:15:56,872::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}}
Thread-728::INFO::2011-07-19 15:16:17,359::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Thread-728::INFO::2011-07-19 15:16:19,708::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}}
Thread-788::INFO::2011-07-19 15:17:38,806::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Thread-788::INFO::2011-07-19 15:17:40,531::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}}
Thread-803::INFO::2011-07-19 15:17:55,570::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=7bc55a62-937d-4c96-b65c-641ff41b9602 msdUUID=4364b7a5-1b36-41f4-bfd7-ff10825754f8 masterVersion=1)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2011-1782.html |
Created attachment 511302 [details] vdsm log Description of problem: on a large scale system - 1583 Lvs and 67 pvs - 36 active sds and 47 general refreshStoragePool take 4.5 minutes. Thread-39379::INFO::2011-07-05 12:41:24,703::dispatcher::94::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, args: ( spUUID=aa2b15e3-2e59-4772-84d7-28964c81677f msdUUID=e3fe53b2-8925-4f59-b522-3421da02b633 masterVersion=1) 12:45:54,878::dispatcher::100::Storage.Dispatcher.Protect::(run) Run and protect: refreshStoragePool, Return response: {'status': {'message': 'OK', 'code': 0}} Version-Release number of selected component (if applicable): vdsm-4.9-79.el6.x86_64 How reproducible: Steps to Reproduce: 1.on this system conditions perform activate storage domain from gui 2. 3. Actual results: Expected results: Additional info: