Significant binary size increase between rc10 -> rc92 #2589
Comments
|
I think at least selinux and apparmor should be exclusive. |
|
Sure it doesn't make sense to include all, but these aren't new tags. |
|
I don't think they reasonably can be exclusive, right? At runtime they would be, but a given binary will end up needing support for both compiled in the same binary because the kernel is a runtime choice (for example, Debian / Ubuntu are in the AppArmor camp but can be ran with SELinux instead by swapping the kernel). There are also cases like static binaries that are expected to work regardless of the host kernel's configuration. |
|
I'm not sure golang/go#6853 is the actual cause here (since you're likely compiling all versions against the same Go 1.13 you referenced), but I think it's worth noting/linking anyhow. |
|
I noticed that we're missing
No, you should build with both unless you're sure it will only ever be used on one distribution with one configuration. We do checks at runtime anyway... (ah, @tianon already said that.)
Depending on the configuration, runc will make a copy of the binary into a memfd -- meaning that an increase in binary size results in increased memory usage. However, these days runc tries to do a read-only bind-mount first -- which shouldn't increase memory usage... |
|
Did some measurements too, with So, for one thing, using go 1.15 helps (and I heard that go 1.16 will be even better). I guess I'll compile each commit to find out which ones to blame. |
|
Found two steps between rc90 and rc92: |
This one is #2268 (update vendor) This one is #2531 (update go.mod) So, it is third-party packages that we use. I guess a smarter linker would help fight this. It was the same before, e.g. for rc8: This is #2029 ("Update dependencies") And the only non-deps one which resulted is a slight but visible increase is: which is #2145 ("cgroup2: port over eBPF device controller from crun") |
|
Since rc92 up to current HEAD, this was the peak: #2675 ("update vendor") |
|
What I did was run something like this: FROM=origin/master
TO=v1.0.0-rc90
OUT=./sz2/
rm -rf $OUT/
mkdir $OUT
git checkout $FROM
while :; do
# v1.0.0-rc90-467-g1b94395c
VER=$(git describe --tags HEAD)
echo $VER
if [ "$VER" == "$TO"* ]; then
echo DONE DONE DONE
exit 0
fi
time make BUILDTAGS="seccomp" GO=go1.15.4 runc
cp runc $OUT/runc-$VER
git reset --hard HEAD~1
doneand then something like this cd sz2
ls -c -1 runc-v1.0.0-rc92-* | xargs size | column --tableand just looked at the numbers in the first and second columns ( |
|
Just got an idea -- we can have a job to compare before/after binary sizes for each PR. |
|
@kolyshkin this article might be interesting for you https://medium.com/@jondot/a-story-of-a-fat-go-binary-20edc6549b97 |
Running some tests between rc10 and rc92 I'm finding the binary size has increased significantly between the two versions.
This is with
BUILDTAGS='seccomp apparmor selinux'in all cases.Compiled with go1.13.15.
The reason I'm investigating this is because we've had a report of users having to increase their memory limits after updating versions.
I have not yet determined what the difference in actual memory consumption is between versions.
If you have an idea on how to instrument this, let me know.
The text was updated successfully, but these errors were encountered: