I have a golang program that uploads a ton of data to OpenStack Object Storage over https. It relies on the golang standard library "net/http" to do the work. I would like to use trickle to rate-limit the upload of the data, but running my code using trickle does not seem to have any effect (as though I'm not using trickle at all).
Why does this happen? Is there some limitation to trickle or golang that prevents them from working together? Is there some gotcha that I haven't considered?
This is my setup:
I know that trickle only works on dynamically-linked executables (see first paragraph of trickle documentation), so I've compiled my code with go build -compiler gccgo mycode.go and the output of ldd myexecutable is:
linux-vdso.so.1 => (0x00007ffee27b8000)
libgo.so.9 => /usr/lib/x86_64-linux-gnu/libgo.so.9 (0x00007f46062bf000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46060a9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4605cdf000)
/lib64/ld-linux-x86-64.so.2 (0x000055aa4d0a4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4605ac2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46057b9000)
I'm running this on Ubuntu Linux 16.04. I use slurm to view the network traffic as my command runs. The machine isn't running any other network-intensive jobs, so I'm confident that I'm seeing the traffic generated by my code.
When I run
trickle -s -v -u2500 myexecutable ...args
I see my TX network traffic spike to about 12000KB/s (the maximum that the network can handle) instead of respecting my limit of 2500KB/s.
Can anyone think of why this might happen or what I could try to fix it?
Trickle relies on using LD_PRELOAD to replace all network related calls through libc with its own implementation. This is why trickle doesn't work with static binaries.
Go makes all its own syscalls directly and does not use the libc interface, so the inter-positioned functions provided by trickle are not used.