Some very bad decisions in transmission
Posted: Sun Dec 16, 2012 5:41 pm
Let me first say that transmission is definitely the best torrent client out there, and nothing I write below will change that fact.
Now, having said that, I noticed that the client does some incredibly stupid things. Namely, when a torrent download (or verification) is finally completed, and thus the content is perfectly cached in the memory, suddenly the client decides to discard everything and clears the memory of all cached content. What happens next is that the torrent, which is of course still seeded, slowly pulls all the content back from the slow disk, thrashing it immensely. And we all know that disks are at least 100 times slower than RAM. So, why would anyone deliberately discard the cache and slow down the whole system? Well, beats me... It's like a spit in the face of numerous kernel developers that work hard to optimize memory caching. It's like you completely wasted your money when you bought additional RAM to save on disk accesses, because transmission won't use it anyway. Bad, bad, bad!
Here's a little program (shared library, actually) that you can compile to fix the bad behaviour, without the need to recompile or mess with the transmission client itself. The library effectively disables every posix_fadvise() call in the app, and thus enables it to utilize the memory properly. The kernel can make a much better memory management decisions anyway, because the kernel sees a bigger picture. Also, lots of competent people work on improving the kernel memory management subsystem, you can't beat them at their job!
The library has been written and tested on a Linux system, but it should work on any other POSIX system, just the same. Nobody should run without it, because every time you thrash your disk, you use much more energy and kill another flower somewhere in the world. So, this green solution should be used until the transmission client is fixed properly. Or at least we're given a choice, to thrash our disk or not. Some people actually enjoy the sound of a disk arm moving randomly, they don't care about flowers...
Save the code to a file named libdisable_posix_fadvise.c, compile it using the instructions in the comment block, and use it like this:
I guess it will work with all transmission UIs, but I tested it only with transmission-daemon, because that's what I use.
Have fun!
Now, having said that, I noticed that the client does some incredibly stupid things. Namely, when a torrent download (or verification) is finally completed, and thus the content is perfectly cached in the memory, suddenly the client decides to discard everything and clears the memory of all cached content. What happens next is that the torrent, which is of course still seeded, slowly pulls all the content back from the slow disk, thrashing it immensely. And we all know that disks are at least 100 times slower than RAM. So, why would anyone deliberately discard the cache and slow down the whole system? Well, beats me... It's like a spit in the face of numerous kernel developers that work hard to optimize memory caching. It's like you completely wasted your money when you bought additional RAM to save on disk accesses, because transmission won't use it anyway. Bad, bad, bad!
Here's a little program (shared library, actually) that you can compile to fix the bad behaviour, without the need to recompile or mess with the transmission client itself. The library effectively disables every posix_fadvise() call in the app, and thus enables it to utilize the memory properly. The kernel can make a much better memory management decisions anyway, because the kernel sees a bigger picture. Also, lots of competent people work on improving the kernel memory management subsystem, you can't beat them at their job!
The library has been written and tested on a Linux system, but it should work on any other POSIX system, just the same. Nobody should run without it, because every time you thrash your disk, you use much more energy and kill another flower somewhere in the world. So, this green solution should be used until the transmission client is fixed properly. Or at least we're given a choice, to thrash our disk or not. Some people actually enjoy the sound of a disk arm moving randomly, they don't care about flowers...
Code: Select all
#include <fcntl.h>
int posix_fadvise(int fd, off_t offset, off_t len, int advice) {
return 0;
}
/*
* gcc -fPIC -rdynamic -c libdisable_posix_fadvise.c
* gcc -shared -o libdisable_posix_fadvise.so libdisable_posix_fadvise.o -lc -ldl
*/
Code: Select all
LD_PRELOAD=/path/to/libdisable_posix_fadvise.so transmission-daemon
Have fun!