[SERVER-18375] High CPU during insert-only stress test due to heap contention on Windows Created: 07/May/15  Updated: 09/Apr/20

Status: Open
Project: Core Server
Component/s: Storage, WiredTiger
Affects Version/s: None
Fix Version/s: Needs Further Definition

Type: Bug Priority: Critical - P2
Reporter: Eitan Klein Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Unresolved Votes: 0
Labels: 32qa, WTmem, move-sa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File TCmalloc2.5.png     PNG File TCmalloc3.5.png     PNG File WT-Secondery.png    
Issue Links:
Related
is related to SERVER-18079 Large performance drop with documents... Closed
Operating System: Windows
Steps To Reproduce:

Hammer.mongo insert only workload for long period of time,

Sprint: Platform 4 06/05/15, Platform 5 06/26/16, Platform 6 07/17/15, Platform 7 08/10/15
Participants:

 Description   

Configuration:
2-node replica set w/ TCMalloc fix for WT heap (3.1.3-pre-)

Problem:

  • High CPU during insert only stress after a day,
    profiler indicated high cpu usage around the heap functions

I think it's early in the 3.2 cycle that we can implement a full solution and stabilize it.

This happened b/c we implemented the TCMalloc 1/2 way (only for WT) so the heap contention is still around , see profiler information about the % of the time around new/free functions



 Comments   
Comment by Alessandro Gherardi [ 21/Sep/16 ]

Related ticket has been closed. This issue is 1 year+ old. Can it be resolved?

Comment by Alessandro Gherardi [ 18/Dec/15 ]

Is this still an issue in 3.2.0/3.2.1?

Comment by Eitan Klein [ 18/May/15 ]

50% of CPU time on WT secondary has been spent on free memory (See profile output on the attached file)

Repro:

  • Configure WT on primary
  • Configure WT on secondary windows machines (you will observe high CPU as results of heap contention)
Comment by Eitan Klein [ 07/May/15 ]

See SERVER-18079 option 2 and 3 that we didn't implemented.

Generated at Thu Feb 08 03:47:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.