Reducing file size of binaries with `strip`

[TmOnlineMapper]

Hello,

as pointed out in the comment https://jira.mongodb.org/browse/SERVER-38389?focusedCommentId=2081264&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-2081264 it is normal that the compiled binaries are huge as they are filled with debug information. It has also been pointed out that strip can be used to reduce the file size.

However I never even knew that program existed. So I was wondering what I can strip without breaking the binary.

I tried strip --strip-unneeded --strip-debug and that seems to work so far. Though as I am absolutely unfamiliar with strip and the MongoDB binaries, I'm wondering if I'm accidentally stripping something that is needed with that call or if I can strip even more. Because since I'll be including the binaries in a custom Debian image I'd like to reduce the file size as much as possible. (Adding unreduced Mongo increased the size from 0.8GiB to 3.2GiB, which is a lot)

Thanks in advance for all helpful posts.

Best regards

BrainStone

[TmOnlineMapper]

So from my first tests, the binaries seem to be working properly and I managed to reduce them significantly using the parameters strip --strip-unneeded --strip-debug:

Before:

357M    mongo
1.0G    mongod
507M    mongos
1.9G    total

After:

34M     mongo

55M     mongod
31M     mongos
119M    total

That's a total reduction of almost 94%! Which worries me a bit that I might have removed too much, so I'd really aprechiate an expert on the matter clearing up some things.

Best Regards

BrainStone

[Andrew Morrow]

Hi, thanks for following up over here on mongodb-dev.

You are using strip correctly. The only risk with what you are doing is that if you have a crash in your stripped mongod binary, it will be very hard to get a symbolized backtrace, because the required debugging information has been entirely removed.

A process which does not suffer from this downside is to copy the debug information out into a different ELF file using objcopy, and then use objcopy again to strip the debug information out of the binary while adding a "debug link" to the debug file. Then you store the separate debug information somewhere so that if you have a crash, you can put it back on the affected system and use it to examine a stack trace (with addr2line) or core (with gdb).

The process for mongod would look like:

objcopy --only-keep-debug mongod mongod.debug

objcopy --strip-debug --add-gnu-debuglink mongod.debug mongod

Then you put the stripped mongod on your deployment platform, and save the associated mongod.debug for investigating crashes or debugging.

There is a supported way to have the MongoDB build system do this for you automatically, but it unfortunately introduces additional complexities, so I'm hesitant to recommend it. There is also an experimental way to do this that does not come with those complexities, but I'm hesitant to recommend it as well since it is likely to change in the future.

Hope this helps.

Thanks,

Andrew

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-dev/93abcb93-9983-4863-85ff-c876fc0d611f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TmOnlineMapper]

I see. For now I think it will be ok to not have debug info available, as I'm not using any development versions or modifying the source in any way. Especially considering there even are official builds for ARM64 (for ubuntu). But it's good to know how I could recustruct backtraces if needed and still have a small file size.

Just out of curiosity, would it make sense to first run strip --strip-unneeded and only then to remove the debug info in the described way?

[Andrew Morrow]

On Thu, Dec 6, 2018 at 11:57 AM TmOnlineMapper <brains...@gmail.com> wrote:

I see. For now I think it will be ok to not have debug info available, as I'm not using any development versions or modifying the source in any way. Especially considering there even are official builds for ARM64 (for ubuntu). But it's good to know how I could recustruct backtraces if needed and still have a small file size.

I appreciate your optimism, but it has happened on occasion that even our stable releases have been found to have defects :)

You should consider holding on to that debug info. You can't get it back once you have destroyed it.

Just out of curiosity, would it make sense to first run strip --strip-unneeded and only then to remove the debug info in the described way?

I actually am not familiar with that particular flag, so I'm not sure. I almost always use the objcopy approach, and I'd advise being conservative about stripping away anything that isn't debug information.

Thanks,

Andrew