[SERVER-6806] [journal] warning assertion failure a <= 256*1024*1024 src/mongo/util/alignedbuilder.cpp 90 message in secondary servers logs Created: 20/Aug/12 Updated: 26/Feb/14 Resolved: 21/Aug/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 2.2.0-rc1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Vladimir Poluyaktov | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
All servers are EC2 hosts, Ubuntu 11.04 (GNU/Linux 2.6.38-13-virtual x86_64) |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | Linux | ||||||||
| Participants: | |||||||||
| Description |
|
We found a log of strange warning messages in mongodb.log files on both of our secondary servers: Sat Aug 11 00:18:30 [rsHealthPoll] warning assertion failure d.size() < 1024 src/mongo/util/concurrency/task.cpp 122 Tue Aug 14 22:35:52 [rsSync] local.oplog.rs warning assertion failure _intents.size() < 2000000 src/mongo/db/dur_commitjob.h 101 Fri Aug 17 17:38:46 [rsSync] local.oplog.rs warning assertion failure _intents.size() < 2000000 src/mongo/db/dur_commitjob.h 101 Fri Aug 17 17:38:53 [journal] warning assertion failure a <= 256*1024*1024 src/mongo/util/alignedbuilder.cpp 90 Here is a full stack trace from one of such messages: Sat Aug 18 23:21:26 [conn17351] end connection 10.13.34.150:50228 (17 connections now open) Full mongodb.log file attached to this issue. |
| Comments |
| Comment by Eric Milkie [ 26/Feb/14 ] |
|
Hi Mark. |
| Comment by Mark Callaghan [ 26/Feb/14 ] |
|
I just got this crash from 2.5.5 while running compact on a collection that uses ~2G of space. Do you want a new report or details posted here? |
| Comment by Eric Milkie [ 21/Aug/12 ] |
|
With the new multithreaded batch replication oplog application code, it's now possible to queue up a lot of work for the journaling subsystem. While this would be a bad thing on a primary node, it's less important on a secondary where nothing can be committed to the journal until an entire batch of operations is complete. You can safely ignore these messages and they should be suppressed in a future release. |