[SERVER-28642] The Same query's performance reduces by 40 folds for 10 concurrent users Created: 05/Apr/17  Updated: 21/Jun/17  Resolved: 24/May/17

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: 3.2.9
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Gulshan Wadhwani Assignee: Mark Agarunov
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File 1User_vs_10User_Scenrio_for_SameAggregateQuery.jpg    
Participants:

 Description   

I have a complex aggregate query, that spans through 4 collections (3 collections have few hundred documents, and 1 collection has 15k documents) all have relevant indexes, that are indeed being used for the actual query.

The Aggregate query in question takes about 2-3 seconds for 1 user, but if 10 parallel threads with same query are sent at same time, it takes 80-100 seconds.

Environment details : single instance mongoDB Server
Version : 3.2.9
OS - RHEL 7.3

The actual area where the slowness is happening is at the Global Locks.
The aggregate query should have read locks, but it is causing "Global Write locks", refer attached snapshot.
(LEFT SIDE: 1 user sends aggregate query, the write locks can't be explained, but are not hurting as much)
(RIGHT SIDE : 10 users send same aggregate query, the write locks are taking significant time , whereas instead on READ locks were expected)



 Comments   
Comment by Kelsey Schubert [ 24/May/17 ]

Hi wadhwanig,

We haven’t heard back from you for some time, so I’m going to mark this ticket as resolved. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Regards,
Thomas

Comment by Mark Agarunov [ 06/Apr/17 ]

Hello wadhwanig,

In addition to the diagnostic data from my previous request, please provide the complete logs from mongod from an instance where you see this behavior.

Thanks,
Mark

Comment by Mark Agarunov [ 05/Apr/17 ]

Hello wadhwanig,

Thank you for the report. To get a better insight into this issue, please archive (tar or zip) the $dbpath/diagnostic.data directory and attach it to this ticket.

Thanks,
Mark

Comment by Gulshan Wadhwani [ 05/Apr/17 ]

Just a slight correction, with 10 user+ situation, it is spending too much time on waiting for a write lock on MetaData/timeAcquiringMicros, but I think we should expect only read locks.

Generated at Thu Feb 08 04:18:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.