Activity log for bug #1461322

Date Who What changed Old value New value Message
2015-06-02 23:31:37 Nischal Sheth bug added bug
2015-06-02 23:31:44 Nischal Sheth nominated for series juniperopenstack/trunk
2015-06-02 23:31:44 Nischal Sheth bug task added juniperopenstack/trunk
2015-06-02 23:31:44 Nischal Sheth nominated for series juniperopenstack/r2.20
2015-06-02 23:31:44 Nischal Sheth bug task added juniperopenstack/r2.20
2015-06-02 23:31:48 Nischal Sheth juniperopenstack/r2.20: assignee Nischal Sheth (nsheth)
2015-06-02 23:31:50 Nischal Sheth juniperopenstack/r2.20: importance Undecided High
2015-06-02 23:31:54 Nischal Sheth juniperopenstack/r2.20: milestone r2.20-fcs
2015-06-03 00:03:19 Vinay Mahuli juniperopenstack/trunk: status New In Progress
2015-06-03 00:03:20 Vinay Mahuli juniperopenstack/r2.20: status New In Progress
2015-06-03 23:59:04 Nischal Sheth summary Make SchedulingGroup::Leave more efficient Make SchedulingGroupManager::Leave more efficient
2015-06-04 16:26:57 Nischal Sheth description Scaling tests for OVSDB have identified SchedulingGroup::Leave as a heavy CPU user. The tests have a small number of agents that Join a large number of RibOuts. Most of the problems are seen when one or more agents is brought down. This bug tracks improvements to handle this scenario more efficiently. Scaling tests for OVSDB have identified SchedulingGroupManager::Leave as a heavy CPU user. The tests have a small number of agents that Join a very large number of VNs. There are 4 TOR-Agents which subscribe to 2K VNs each and 1 TSN-Agent which subscribes to 8K VNs. System takes 20+ minutes to settle down when all these agents are killed. Profiling data shows that bulk of time is spent in SchedulingGroupManager::Leave. This bug tracks improvements to handle this scenario more efficiently.
2015-06-04 16:42:44 Nischal Sheth description Scaling tests for OVSDB have identified SchedulingGroupManager::Leave as a heavy CPU user. The tests have a small number of agents that Join a very large number of VNs. There are 4 TOR-Agents which subscribe to 2K VNs each and 1 TSN-Agent which subscribes to 8K VNs. System takes 20+ minutes to settle down when all these agents are killed. Profiling data shows that bulk of time is spent in SchedulingGroupManager::Leave. This bug tracks improvements to handle this scenario more efficiently. Scaling tests for OVSDB have identified SchedulingGroupManager::Leave as a heavy CPU user. The tests have a small number of agents that Join a very large number of VNs. There are 4 TOR-Agents which subscribe to 2K VNs each and 1 TSN-Agent which subscribes to 8K VNs. System takes 23+ minutes to settle down when all these agents are killed. Profiling data shows that bulk of time is spent in SchedulingGroupManager::Leave. This bug tracks improvements to handle this scenario more efficiently.
2015-06-04 16:51:13 Nischal Sheth description Scaling tests for OVSDB have identified SchedulingGroupManager::Leave as a heavy CPU user. The tests have a small number of agents that Join a very large number of VNs. There are 4 TOR-Agents which subscribe to 2K VNs each and 1 TSN-Agent which subscribes to 8K VNs. System takes 23+ minutes to settle down when all these agents are killed. Profiling data shows that bulk of time is spent in SchedulingGroupManager::Leave. This bug tracks improvements to handle this scenario more efficiently. Scaling tests for OVSDB have identified SchedulingGroupManager::Leave as a heavy CPU user. The tests have a small number of agents that Join a very large number of VNs. There are 4 TOR-Agents which subscribe to 2K VNs each and 1 TSN-Agent which subscribes to 8K VNs. System takes 23+ minutes to settle down when all these agents are killed. Profiling data shows that bulk of time is spent in SchedulingGroupManager::Leave. The numbers will be much worse when the number [TOR|TSN]-Agents and/or VNs goes up. This bug tracks improvements to handle this scenario more efficiently.
2015-06-11 18:37:07 Nischal Sheth juniperopenstack/r2.20: status In Progress Fix Committed
2015-06-11 18:37:09 Nischal Sheth juniperopenstack/trunk: status In Progress Fix Committed