[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 |
||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| 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:
The size of capped collection is ranged from 10000MB to 10010MB. |
| Comments |
| Comment by Matt Kangas [ 19/Aug/14 ] |
|
Same underlying issue as |
| Comment by Pavel Surikov [ 07/Sep/12 ] |
|
I've added steps to reproduce the defect: |
| 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. |
| 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. |