[SERVER-5663] Private pages accumulate in Windows RAM and page file when journaling Created: 20/Apr/12  Updated: 11/Jul/16  Resolved: 20/Apr/12

Status: Closed
Project: Core Server
Component/s: Performance, Stability
Affects Version/s: 2.0.4
Fix Version/s: 2.0.7, 2.1.1

Type: Bug Priority: Major - P3
Reporter: Tad Marshall Assignee: Tad Marshall
Resolution: Done Votes: 0
Labels: Windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Depends
Duplicate
is duplicated by SERVER-2002 Performance issues under extremely hi... Closed
is duplicated by SERVER-3660 "VirtualProtect failed" when insertin... Closed
Related
related to SERVER-4522 inserts take long time after several ... Closed
is related to SERVER-2942 MapViewOfFileEx failed during large i... Closed
is related to SERVER-6132 a failure inside MakeChunkWritable sh... Closed
Operating System: Windows
Participants:

 Description   

The remapPrivateView() routine in Windows in version 2.0.x, used when journaling is enabled, uses VirtualProtect() to try to restore CopyOnWrite pages to their original condition. This doesn't accomplish its goal and instead causes private pages to accumulate, consuming page file space. remapPrivateView() needs to unmap and remap the private view to prevent this accumulation.

This ticket summarizes the visible symptoms and the fix for those symptoms. Making this change reintroduces SERVER-2942 until the unmapping and remapping can be made completely reliable.



 Comments   
Comment by Tad Marshall [ 21/Jun/12 ]

Backported to 2.0.7.

Comment by auto [ 21/Jun/12 ]

Author:

{u'date': u'2012-06-20T14:47:51-07:00', u'email': u'tad@10gen.com', u'name': u'Tad Marshall'}

Message: SERVER-5663, SERVER-2942 MapViewOfFileEx backport

Backport the fixes for Windows memory-mapped files made in
2.1.x into the 2.0.x branch. Stop using VirtualProtect in
remapPrivateView, use UnmapViewOfFile and MapViewOfFileEx
to refresh the private view of the memory-mapped file.
Place memory-mapped files at a high address in 64-bit to
get out of the way of allocations made by Windows.
Branch: v2.0
https://github.com/mongodb/mongo/commit/881d6229e1ab58695959862a76f3175e142af84e

Comment by Tad Marshall [ 20/Jun/12 ]

Requesting backport ... should have been requested when backport for SERVER-2942 was requested.

Comment by auto [ 25/Apr/12 ]

Author:

{u'login': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: LockMongoFilesExclusive in remapViewOfFiles on Windows.

Since remapViewOfFiles isn't atomic on Windows, it must exclusively acquire the
"mongo files" lock. Otherwise, "touch" operations in other threads might try
to access memory during the window when it is not mapped.

See SERVER-5680, SERVER-5663.
Branch: master
https://github.com/mongodb/mongo/commit/d8462a26b9089c5e58d1e340dcada83719ea4e47

Comment by Tad Marshall [ 20/Apr/12 ]

Fixed by commit 6097787b1f3c7f9b4f8dca68f66d474eaa60b1d1 .

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