Changes between Initial Version and Version 1 of archive/libtorrent.rakshasa.no/RTorrentPerformanceTuning

Timestamp:

08/08/15 16:33:36 (9 years ago)

Author:

Gabor Hudiczius

Comment:

--

archive/libtorrent.rakshasa.no/RTorrentPerformanceTuning

@@ +1 @@
+[[libtorrentMirror]]
+
+= Performance Tuning =
+
+== Send and receive buffer size ==
+
+The 'send_buffer_size' and 'receive_buffer_size' options can be used to adjust the socket send and receive buffer sizes. Increasing the send buffer size may help reduce disk seeking as more data is buffered each time the socket is written to. On linux you may use "cat /proc/sys/net/ipv4/tcp_wmem" to see the minimum, default and max buffer size, respectively.
+
+== Max memory usage ==
+
+The amount of memory address space used for mapping chunks is limited to "ulimit -m" or 1GB. For fast downloads and/or large number of peers this may quickly be exhausted causing the client to hang while it syncs to disk. You may increase this limit with the "max_memory_usage" option.
+
+== Use of fd_set and epoll ==
+
+Due to libcurl's use of ''fd_set'' for polling, rTorrent cannot at the moment move to a pure ''epoll'' implementation. Currently the ''epoll'' code uses ''select'' based polling if, and only if, libcurl is active. All non-libcurl sockets are still in ''epoll'', but ''select'' is used on the libcurl and the ''epoll''-socket.
+
+== Variable fd_set size ==
+
+By default rTorrent uses variable sized fd_set's depending on the process sysconf(_SC_OPEN_MAX) limit. This is non-portable and is therefor possible to disable by compiling rTorrent with the ''--without-variable-fdset'' flag. Use "ulimit -n" to change the open files limit.
+
+Large fd_set's cause a performance penalty as they must be cleared each time the client polls the sockets. When using ''select'' or ''epoll'' (until libcurl is fixed) based polling use an open files limit that is reasonably low. The widely used default of 1024 is enough for most users and 64 is minimum. Those with embeded devices or older platforms might need to set the limit much lower than the default.
+
+== Hash checking ==
+
+The setting ''hash_read_ahead'' controls how many MB to ask the kernel to read ahead when doing hash checking. If this value is too low it might not fully utilize the possible IO, while too high it might make the kernel give up. This should depend on how much free memory is available and the kernel implementation. Usefull values would probably range from 1 to 10.
+
+== *BSD Notes ==
+I have tweaked the settings i've used in my .rtorrent.rc, and this enables me to hash at about 10Mb/sec.  Listed below are the settings I use.
+
+ * ''hash_read_ahead = 8''
+ * ''hash_max_tries = 5''
+ * ''hash_interval = 10''
+
+The real perfomance boost was the hash_interval change. This was what yielded the almost 10 fold increase in speed over the default settings.
+
+= Notes =
+
+== Disk allocation ==
+
+Opening a torrent causes files to be created and resized with ''ftruncate'' ([ticket:39 ftruncate has problem on vfat filesystem, though].) This does not actually use disk space until data is written, despite what the file sizes are reported as. Use ''du'' without the flag ''--apparent-size'' to see the real disk usage.
+
+== Multiple torrents and performance ==
+
+I usually have several tens of torrents open, but the bittorrent faq says it's a bad idea http://www.bittorrent.com/FAQ.html#simultaneoustorrents
+What should I do?
+
+A: the problem is that if you don't have enough bandwidth to download those torrents in max speed, the performance of the bittorrent system as a whole will degrade, since you are taking up "slots" on the machines that you download from and not downloading at full speed. So if you run lots of torrents there would need to be some way to only activate downloading from one torrent at a time, so you can max out the transfer for that torrent.