[SERVER-6954] FlushViewOfFile with error 487 when trying to do repair database and recreate capped collection several times Created: 06/Sep/12  Updated: 10/Dec/14  Resolved: 19/Aug/14

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.0.7
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Pavel Surikov Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: WIndows, community-team, crash, service
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Microsoft Windows Web Server 2008R2, 64-bit
Microsoft Windows Server 2008R2 Standard, 64-bit


Attachments: Text File Script_FlushViewOfFile.txt     Text File Script_FlushViewOfFile_Result.txt     Text File ServerLogFlushViewOfFile_webServer2008.txt     Text File ServerLogFlushViewOfFile_webServer2008_verbose.txt     Text File ServerLogFlushViewOfFile_win2008_verbose.txt    
Issue Links:
Duplicate
duplicates SERVER-10516 mongod crashes when re-mapping above ... Closed
Related
is related to SERVER-9489 Recreating a dropped capped collectio... Closed
Operating System: Windows
Participants:

 Description   

After making nearly 10 attempts to do repair database, drop capped collection, create a new capped collection with different size a Mongo db windows service terminates and shows the following error in log file:

[DataFileSync] FlushViewOfFile for E:/Serena/SBM/Common/Diagnostics/MongoDb/data/sbm.0 failed with error 487 after 1 attempts taking 0 ms

The size of capped collection is ranged from 10000MB to 10010MB.
I've seen similar issues, but none of them were related with repairing database.



 Comments   
Comment by Matt Kangas [ 19/Aug/14 ]

Same underlying issue as SERVER-10516

Comment by Pavel Surikov [ 07/Sep/12 ]

I've added steps to reproduce the defect:
Script_FlushViewOfFile.txt - steps I used
Script_FlushViewOfFile_Result.txt - server log.

Comment by Pavel Surikov [ 06/Sep/12 ]

Hi Tad,

The reason why I was using 'repair database' is because I needed to reduce the size of the files created by Mongo db. Each time I change the capped collection size I end up with new files. Even though I rarely use collections larger than 5GB I got 22GB of data. On 32-bit systems there was also a problem of hitting 2GB limit.

I'll prepare the exact sequence of steps I was doing, but in general: I'm performing a 'repair database', dropping existing capped collection of one size, and creating another collection with the same name, but with a different size. The goal is to configure the size of the capped collection we use for logs from a windows application. When I was testing it, I tried to change the size the way I described several times. The number of attempts may be different, but in average I did 10 attempts before service terminates.

As for the --nojournal option, I need to take a look why we didn't use it.
Before changing the size there were only a few operations of updating sbm.conf collection with a several documents. The collection is not large and there only a dozen of element that need to be updated.

Comment by Tad Marshall [ 06/Sep/12 ]

Thank you for the bug report and for the log files.

Were your 10 attempts because you would get the FlushViewOfFile error 487 every time? Why was "repair database" needed? Were you seeing corruption?

If I was to reproduce your bug here, what sequence of steps should I follow?

Is there a reason why you are running with --nojournal? The journal-related memory issues in Windows are fixed in version 2.0.7.

From the logs, it looks like there was a lot of activity in the sbm database (judging from the extremely long flush times), followed by a drop of the sbm.diag collection. In each log file, there is a drop of sbm.diag in the same second that you get your FlushViewOfFile failure. It seems likely that these are related and I'm trying to figure out what you are doing, so some sort of step-by-step set of instructions would be helpful.

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