fix documentation mentions of session_settings to refer to settings_pack. clean out some outdated disk instrumentation docs
This commit is contained in:
arvidn
parent
d5b32a80b3
commit
85f615132b
|
|
@ -10,10 +10,6 @@ DOCS_IMAGES = \
|
|||
docs/cwnd_thumb.png \
|
||||
docs/delays.png \
|
||||
docs/delays_thumb.png \
|
||||
docs/disk_access.png \
|
||||
docs/disk_buffer_before_optimization.png \
|
||||
docs/disk_buffer.png \
|
||||
docs/disk_buffer_sample.png \
|
||||
docs/disk_io.png \
|
||||
docs/hacking.html \
|
||||
docs/im_thumb.jpg \
|
||||
|
|
@ -28,8 +24,6 @@ DOCS_IMAGES = \
|
|||
docs/write_disk_buffers.png \
|
||||
docs/write_disk_buffers.diagram \
|
||||
docs/ziptorrent_thumb.gif \
|
||||
docs/disk_access_elevator.png \
|
||||
docs/disk_access_no_elevator.png\
|
||||
docs/ip_id_v4.png \
|
||||
docs/ip_id_v6.png \
|
||||
docs/hash_distribution.png \
|
||||
|
|
|
|||
|
|
@ -385,7 +385,7 @@ namespace
|
|||
allow_threading_guard guard;
|
||||
s.start_upnp();
|
||||
}
|
||||
#endif
|
||||
#endif // TORRENT_NO_DEPRECATE
|
||||
|
||||
#ifndef TORRENT_NO_DEPRECATE
|
||||
boost::shared_ptr<alert>
|
||||
|
|
@ -792,7 +792,7 @@ void bind_session()
|
|||
.def("settings", &session_get_settings)
|
||||
.def("get_settings", &session_get_settings)
|
||||
#endif
|
||||
.def("set_settings", &session_set_settings)
|
||||
.def("apply_settings", &session_set_settings)
|
||||
#ifndef TORRENT_NO_DEPRECATE
|
||||
#ifndef TORRENT_DISABLE_ENCRYPTION
|
||||
.def("set_pe_settings", allow_threads(<::session::set_pe_settings))
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.2 KiB |
|
|
@ -129,7 +129,7 @@ disk caching
|
|||
------------
|
||||
|
||||
All disk I/O in libtorrent is done asynchronously to the network thread, by the
|
||||
disk io thread. When a block is read, the disk io thread reads all subsequent
|
||||
disk io threads. When a block is read, the disk io thread reads all subsequent
|
||||
blocks from that piece into the read cache, assuming that the peer requesting
|
||||
the block will also request more blocks from the same piece. This decreases the
|
||||
number of syscalls for reading data. It also decreases delay from seeking.
|
||||
|
|
@ -155,62 +155,6 @@ The largest contiguous algorithm is the default and flushes the largest contiguo
|
|||
block of buffers, instead of flushing all blocks belonging to the piece which was
|
||||
written to least recently.
|
||||
|
||||
For version 0.15 a lot of work went into optimizing the cache algorithm, trying
|
||||
to increase the cache hit rate and utilization. The graph to the left shows the
|
||||
memory utilization in 0.14. This cache is a straight forward, fairly naive, implementation.
|
||||
Every block read will also read all subsequent blocks in that piece into the cache.
|
||||
Whenever we need more space, the entire oldest piece is evicted from the cache. Caching
|
||||
writes always takes presedence over the read cache. Whenever a piece is fully downloaded,
|
||||
it is flushed to disk.
|
||||
|
||||
.. image:: disk_buffer_before_optimization.png
|
||||
:width: 49%
|
||||
|
||||
.. image:: disk_buffer.png
|
||||
:width: 49%
|
||||
|
||||
The left graph shows the problem of evicting entire pieces at a time, and waiting until
|
||||
an entire piece is downloaded until flushing it. These graphs were generated for a torrent
|
||||
with fairly large pieces. This means that granularity was poor in 0.14, since it only
|
||||
dealt with entire pieces. In 0.15, the granularity problem has been fixed by evicting one
|
||||
block at a time from the read cache. This maximizes the read cache utilization. The write
|
||||
cache is also flushed when a sufficient number of contiguous blocks have been downloaded
|
||||
for a piece, which is not tied to the piece size anymore. This way the cache scales a lot
|
||||
better with piece sizes.
|
||||
|
||||
The graph to the right shows the same download but with the new optimized disk cache
|
||||
algorithm. It clearly shows an increased utilization, which means higher read hit rates
|
||||
or smaller caches with maintained hit rate.
|
||||
|
||||
high performance disk subsystem
|
||||
-------------------------------
|
||||
|
||||
In some circumstances, the disk cache may not suffice to provide maximum performance.
|
||||
One such example is high performance seeding, to a large number of peers, over a fast
|
||||
up-link. In such a case, the amount of RAM may simply not be enough to cache disk
|
||||
reads. When there's not enough RAM to cache disk reads, the disk throughput would
|
||||
typically degrade to perform as poorly as with no cache at all, with the majority
|
||||
of the time spent waiting for the disk head to seek.
|
||||
|
||||
To solve this problem, libtorrent sorts read requests by their physical offset on the
|
||||
disk. They are processed by having the disk read head sweep back and forth over the drive.
|
||||
|
||||
This makes libtorrent very suitable for large scale, high-throughput seeding.
|
||||
|
||||
.. image:: disk_access_no_elevator.png
|
||||
:width: 49%
|
||||
|
||||
.. image:: disk_access_elevator.png
|
||||
:width: 49%
|
||||
|
||||
These plots illustrates the physical disk offset for reads over time. The left plot
|
||||
is of a run where disk operation re-ordering is turned off and the righ is when it's
|
||||
turned on. The right one has a relatively smooth sine wave shape whereas the left
|
||||
one is more random and involves much longer seeks back and forth over the disk.
|
||||
|
||||
True physical disk offset queries are only supported on newer linux kernels, Mac OS X and
|
||||
Windows 2000 and up.
|
||||
|
||||
network buffers
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ libtorrent starts 3 to 5 threads.
|
|||
* The third thread is the SHA-1 hash thread. By default there's only one hash thread,
|
||||
but on multi-core machines downloading at very high rates, libtorrent can be configured
|
||||
to start any number of hashing threads, to take full use of multi core systems.
|
||||
(see ``session_settings::hashing_threads``).
|
||||
(see ``settings_pack::hashing_threads``).
|
||||
|
||||
* The fourth and fifth threads are spawned by asio on systems that don't support
|
||||
asynchronous host name resolution, in order to simulate non-blocking ``getaddrinfo()``.
|
||||
|
|
|
|||
|
|
@ -98,13 +98,12 @@ a list of entries.
|
|||
``create_torrent::add_node()`` takes two arguments, one string and one integer,
|
||||
instead of a pair. The string is the address and the integer is the port.
|
||||
|
||||
``session::set_settings()`` not only accepts a ``session_settings`` object, but also
|
||||
a dictionary with keys matching the names of the members of the ``session_settings`` struct.
|
||||
When calling ``set_settings``, the dictionary does not need to have every settings set,
|
||||
keys that are not present, are set to their default value.
|
||||
``session::apply_settings()`` accepts a dictionary with keys matching the names
|
||||
of settings in settings_pack.
|
||||
When calling ``apply_settings``, the dictionary does not need to have every settings set,
|
||||
keys that are not present are not updated.
|
||||
|
||||
For backwards compatibility, ``session::settings()`` still returns a ``session_settings``
|
||||
struct. To get a python dictionary of the settings, call ``session::get_settings``.
|
||||
To get a python dictionary of the settings, call ``session::get_settings``.
|
||||
|
||||
.. _`library reference`: reference.html
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ digraph no_download {
|
|||
node_upload_mode [label="Is the torrent in upload mode?\n(torrent_status::upload_mode)"];
|
||||
node_bwstate [label="What is the peer read_state set to?\n(peer_info::read_state)"];
|
||||
|
||||
node_dl_limit [label="There is a download rate limit in affect on your peers.\nDo you have a download rate limit set?\n(session_settings::download_rate_limit)"];
|
||||
node_dl_limit [label="There is a download rate limit in affect on your peers.\nDo you have a download rate limit set?\n(settings_pack::download_rate_limit)"];
|
||||
|
||||
node_dl_disk [label="Peers are blocked waiting on the disk.\nThis typically means your disk is overloaded"];
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ digraph no_download {
|
|||
|
||||
// end states
|
||||
|
||||
node_end_queued [label="This means the torrent is 'queued'. i.e. it will\nbe started once the torrents in front of it\ncompletes downloading. To know the queue\norder, see torrent_status::queue_position. To\nconfigure the number of simultaneous downloads,\nsee session_settings::active_limit and\nsession_settings::active_downloads."];
|
||||
node_end_queued [label="This means the torrent is 'queued'. i.e. it will\nbe started once the torrents in front of it\ncompletes downloading. To know the queue\norder, see torrent_status::queue_position. To\nconfigure the number of simultaneous downloads,\nsee settings_pack::active_limit and\nsettings_pack::active_downloads."];
|
||||
|
||||
node_end_stopped [label="This means the torrent is\n'stopped'. To start it call\ntorrent_handle::resume()."];
|
||||
|
||||
|
|
|
|||
174
docs/tuning.rst
174
docs/tuning.rst
|
|
@ -12,8 +12,8 @@ libtorrent manual
|
|||
tuning libtorrent
|
||||
=================
|
||||
|
||||
libtorrent expose most constants used in the bittorrent engine for
|
||||
customization through the ``session_settings``. This makes it possible to
|
||||
libtorrent expose most parameters used in the bittorrent engine for
|
||||
customization through the ``settings_pack``. This makes it possible to
|
||||
test and tweak the parameters for certain algorithms to make a client
|
||||
that fits a wide range of needs. From low memory embedded devices to
|
||||
servers seeding thousands of torrents. The default settings in libtorrent
|
||||
|
|
@ -27,7 +27,7 @@ reducing memory footprint
|
|||
=========================
|
||||
|
||||
These are things you can do to reduce the memory footprint of libtorrent. You get
|
||||
some of this by basing your default ``session_settings`` on the ``min_memory_usage()``
|
||||
some of this by basing your default ``settings_pack`` on the ``min_memory_usage()``
|
||||
setting preset function.
|
||||
|
||||
Keep in mind that lowering memory usage will affect performance, always profile
|
||||
|
|
@ -58,9 +58,9 @@ disable disk cache
|
|||
|
||||
The bulk of the memory libtorrent will use is used for the disk cache. To save
|
||||
the absolute most amount of memory, you can disable the cache by setting
|
||||
``session_settings::cache_size`` to 0. You might want to consider using the cache
|
||||
``settings_pack::cache_size`` to 0. You might want to consider using the cache
|
||||
but just disable caching read operations. You do this by settings
|
||||
``session_settings::use_read_cache`` to false. This is the main factor in how much
|
||||
``settings_pack::use_read_cache`` to false. This is the main factor in how much
|
||||
memory will be used by the client. Keep in mind that you will degrade performance
|
||||
by disabling the cache. You should benchmark the disk access in order to make an
|
||||
informed trade-off.
|
||||
|
|
@ -94,8 +94,8 @@ connection, and might be worth considering if you have a very large number of
|
|||
peer connections. This memory will not be visible in your process, this sets
|
||||
the amount of kernel memory is used for your sockets.
|
||||
|
||||
Change this by setting ``session_settings::recv_socket_buffer_size`` and
|
||||
``session_settings::send_socket_buffer_size``.
|
||||
Change this by setting ``settings_pack::recv_socket_buffer_size`` and
|
||||
``settings_pack::send_socket_buffer_size``.
|
||||
|
||||
peer list size
|
||||
--------------
|
||||
|
|
@ -109,7 +109,7 @@ large number of paused torrents (that are popular) it will be even more
|
|||
significant.
|
||||
|
||||
If you're short of memory, you should consider lowering the limit. 500 is probably
|
||||
enough. You can do this by setting ``session_settings::max_peerlist_size`` to
|
||||
enough. You can do this by setting ``settings_pack::max_peerlist_size`` to
|
||||
the max number of peers you want in a torrent's peer list. This limit applies per
|
||||
torrent. For 5 torrents, the total number of peers in peerlists will be 5 times
|
||||
the setting.
|
||||
|
|
@ -117,7 +117,7 @@ the setting.
|
|||
You should also lower the same limit but for paused torrents. It might even make sense
|
||||
to set that even lower, since you only need a few peers to start up while waiting
|
||||
for the tracker and DHT to give you fresh ones. The max peer list size for paused
|
||||
torrents is set by ``session_settings::max_paused_peerlist_size``.
|
||||
torrents is set by ``settings_pack::max_paused_peerlist_size``.
|
||||
|
||||
The drawback of lowering this number is that if you end up in a position where
|
||||
the tracker is down for an extended period of time, your only hope of finding live
|
||||
|
|
@ -132,7 +132,7 @@ The send buffer watermark controls when libtorrent will ask the disk I/O thread
|
|||
to read blocks from disk, and append it to a peer's send buffer.
|
||||
|
||||
When the send buffer has fewer than or equal number of bytes as
|
||||
``session_settings::send_buffer_watermark``, the peer will ask the disk I/O thread
|
||||
``settings_pack::send_buffer_watermark``, the peer will ask the disk I/O thread
|
||||
for more data to send. The trade-off here is between wasting memory by having too
|
||||
much data in the send buffer, and hurting send rate by starving out the socket,
|
||||
waiting for the disk read operation to complete.
|
||||
|
|
@ -156,7 +156,7 @@ the whole piece in one read call, then hashes it.
|
|||
The second option is to optimize for memory usage instead, where a single buffer
|
||||
is allocated, and the piece is read one block at a time, hashing it as each
|
||||
block is read from the file. For low memory environments, this latter approach
|
||||
is recommended. Change this by settings ``session_settings::optimize_hashing_for_speed``
|
||||
is recommended. Change this by settings ``settings_pack::optimize_hashing_for_speed``
|
||||
to false. This will significantly reduce peak memory usage, especially for
|
||||
torrents with very large pieces.
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ processes that might be of higher importance to the end-user, you can introduce
|
|||
between the disc accesses. This is a direct tradeoff between how fast you can check a
|
||||
torrent and how soft you will hit the disk.
|
||||
|
||||
You control this by setting the ``session_settings::file_checks_delay_per_block`` to greater
|
||||
You control this by setting the ``settings_pack::file_checks_delay_per_block`` to greater
|
||||
than zero. This number is the number of milliseconds to sleep between each read of 16 kiB.
|
||||
|
||||
The sleeps are not necessarily in between each 16 kiB block (it might be read in larger chunks),
|
||||
|
|
@ -221,7 +221,7 @@ purpose of this is because of anti-virus software that hooks on file-open and fi
|
|||
scan the file. Anti-virus software that does that will significantly increase the cost of
|
||||
opening and closing files. However, for a high performance seed, the file open/close might
|
||||
be so frequent that it becomes a significant cost. It might therefore be a good idea to allow
|
||||
a large file descriptor cache. Adjust this though ``session_settings::file_pool_size``.
|
||||
a large file descriptor cache. Adjust this though ``settings_pack::file_pool_size``.
|
||||
|
||||
Don't forget to set a high rlimit for file descriptors in your process as well. This limit
|
||||
must be high enough to keep all connections and files open.
|
||||
|
|
@ -230,33 +230,33 @@ disk cache
|
|||
----------
|
||||
|
||||
You typically want to set the cache size to as high as possible. The
|
||||
``session_settings::cache_size`` is specified in 16 kiB blocks. Since you're seeding,
|
||||
the cache would be useless unless you also set ``session_settings::use_read_cache``
|
||||
``settings_pack::cache_size`` is specified in 16 kiB blocks. Since you're seeding,
|
||||
the cache would be useless unless you also set ``settings_pack::use_read_cache``
|
||||
to true.
|
||||
|
||||
In order to increase the possibility of read cache hits, set the
|
||||
``session_settings::cache_expiry`` to a large number. This won't degrade anything as
|
||||
``settings_pack::cache_expiry`` to a large number. This won't degrade anything as
|
||||
long as the client is only seeding, and not downloading any torrents.
|
||||
|
||||
There's a *guided cache* mode. This means the size of the read cache line that's
|
||||
stored in the cache is determined based on the upload rate to the peer that
|
||||
triggered the read operation. The idea being that slow peers don't use up a
|
||||
disproportional amount of space in the cache. This is enabled through
|
||||
``session_settings::guided_read_cache``.
|
||||
``settings_pack::guided_read_cache``.
|
||||
|
||||
In cases where the assumption is that the cache is only used as a read-ahead, and that no
|
||||
other peer will ever request the same block while it's still in the cache, the read
|
||||
cache can be set to be *volatile*. This means that every block that is requested out of
|
||||
the read cache is removed immediately. This saves a significant amount of cache space
|
||||
which can be used as read-ahead for other peers. To enable volatile read cache, set
|
||||
``session_settings::volatile_read_cache`` to true.
|
||||
``settings_pack::volatile_read_cache`` to true.
|
||||
|
||||
SSD as level 2 cache
|
||||
--------------------
|
||||
|
||||
It is possible to introduce a second level of cache, below the RAM disk cache. This is done
|
||||
by setting ``session_settings::mmap_cache`` to a file path pointing to the SSD drive, and
|
||||
increasing the ``session_settings::cache_size`` to the number of 16 kiB blocks would fit
|
||||
by setting ``settings_pack::mmap_cache`` to a file path pointing to the SSD drive, and
|
||||
increasing the ``settings_pack::cache_size`` to the number of 16 kiB blocks would fit
|
||||
on the drive (or less).
|
||||
|
||||
This will allocate disk buffers (for reading and writing) from a memory region that has
|
||||
|
|
@ -280,7 +280,7 @@ throttle TCP to avoid it taking over all bandwidth. This balances the bandwidth
|
|||
between the two protocols. When running on a network where the bandwidth is in such an
|
||||
abundance that it's virtually infinite, this algorithm is no longer necessary, and might
|
||||
even be harmful to throughput. It is adviced to experiment with the
|
||||
``session_setting::mixed_mode_algorithm``, setting it to ``session_settings::prefer_tcp``.
|
||||
``session_setting::mixed_mode_algorithm``, setting it to ``settings_pack::prefer_tcp``.
|
||||
This setting entirely disables the balancing and unthrottles all connections. On a typical
|
||||
home connection, this would mean that none of the benefits of uTP would be preserved
|
||||
(the modem's send buffer would be full at all times) and uTP connections would for the most
|
||||
|
|
@ -299,7 +299,7 @@ enough to not draining the socket's send buffer before the disk operation comple
|
|||
The watermark is bound to a max value, to avoid buffer sizes growing out of control.
|
||||
The default max send buffer size might not be enough to sustain very high upload rates,
|
||||
and you might have to increase it. It's specified in bytes in
|
||||
``session_settings::send_buffer_watermark``.
|
||||
``settings_pack::send_buffer_watermark``.
|
||||
|
||||
peers
|
||||
-----
|
||||
|
|
@ -311,30 +311,30 @@ infinite, ``session::set_upload_rate_limit()``, passing 0 means infinite.
|
|||
When dealing with a large number of peers, it might be a good idea to have slightly
|
||||
stricter timeouts, to get rid of lingering connections as soon as possible.
|
||||
|
||||
There are a couple of relevant settings: ``session_settings::request_timeout``,
|
||||
``session_settings::peer_timeout`` and ``session_settings::inactivity_timeout``.
|
||||
There are a couple of relevant settings: ``settings_pack::request_timeout``,
|
||||
``settings_pack::peer_timeout`` and ``settings_pack::inactivity_timeout``.
|
||||
|
||||
For seeds that are critical for a delivery system, you most likely want to allow
|
||||
multiple connections from the same IP. That way two people from behind the same NAT
|
||||
can use the service simultaneously. This is controlled by
|
||||
``session_settings::allow_multiple_connections_per_ip``.
|
||||
``settings_pack::allow_multiple_connections_per_ip``.
|
||||
|
||||
In order to always unchoke peers, turn off automatic unchoke
|
||||
``session_settings::auto_upload_slots`` and set the number of upload slots to a large
|
||||
``settings_pack::auto_upload_slots`` and set the number of upload slots to a large
|
||||
number via ``session::set_max_uploads()``, or use -1 (which means infinite).
|
||||
|
||||
torrent limits
|
||||
--------------
|
||||
|
||||
To seed thousands of torrents, you need to increase the ``session_settings::active_limit``
|
||||
and ``session_settings::active_seeds``.
|
||||
To seed thousands of torrents, you need to increase the ``settings_pack::active_limit``
|
||||
and ``settings_pack::active_seeds``.
|
||||
|
||||
SHA-1 hashing
|
||||
-------------
|
||||
|
||||
When downloading at very high rates, it is possible to have the CPU be the bottleneck
|
||||
for passing every downloaded byte through SHA-1. In order to enable calculating SHA-1
|
||||
hashes in parallel, on multi-core systems, set ``session_settings::hashing_threads``
|
||||
hashes in parallel, on multi-core systems, set ``settings_pack::hashing_threads``
|
||||
to the number of threads libtorrent should start to do SHA-1 hashing. This defaults
|
||||
to 1, and only if that thread is close to saturating one core does it make sense to
|
||||
increase the number of threads.
|
||||
|
|
@ -390,19 +390,7 @@ the disk I/O. The following table is an overview of these files and what they me
|
|||
+--------------------------+--------------------------------------------------------------+
|
||||
| filename | description |
|
||||
+==========================+==============================================================+
|
||||
| ``disk_io_thread.log`` | This is a log of which operation the disk I/O thread is |
|
||||
| | engaged in, with timestamps. This tells you what the thread |
|
||||
| | is spending its time doing. |
|
||||
| | |
|
||||
+--------------------------+--------------------------------------------------------------+
|
||||
| ``disk_buffers.log`` | This log keeps track of what the buffers allocated from the |
|
||||
| | disk buffer pool are used for. There are 5 categories. |
|
||||
| | receive buffer, send buffer, write cache, read cache and |
|
||||
| | temporary hash storage. This is key when optimizing memory |
|
||||
| | usage. |
|
||||
| | |
|
||||
+--------------------------+--------------------------------------------------------------+
|
||||
| ``disk_access.log`` | This is a low level log of read and write operations, with |
|
||||
| ``file_access.log`` | This is a low level log of read and write operations, with |
|
||||
| | timestamps and file offsets. The file offsets are byte |
|
||||
| | offsets in the torrent (not in any particular file, in the |
|
||||
| | case of a multi-file torrent). This can be used as an |
|
||||
|
|
@ -412,106 +400,12 @@ the disk I/O. The following table is an overview of these files and what they me
|
|||
| | |
|
||||
+--------------------------+--------------------------------------------------------------+
|
||||
|
||||
|
||||
disk_io_thread.log
|
||||
''''''''''''''''''
|
||||
|
||||
The structure of this log is simple. For each line, there are two columns, a timestamp and
|
||||
the operation that was started. There is a special operation called ``idle`` which means
|
||||
it looped back to the top and started waiting for new jobs. If there are more jobs to
|
||||
handle immediately, the ``idle`` state is still there, but the timestamp is the same as the
|
||||
next job that is handled.
|
||||
|
||||
Some operations have a 3:rd column with an optional parameter. ``read`` and ``write`` tells
|
||||
you the number of bytes that were requested to be read or written. ``flushing`` tells you
|
||||
the number of bytes that were flushed from the disk cache.
|
||||
|
||||
This is an example excerpt from a log::
|
||||
|
||||
3702 idle
|
||||
3706 check_fastresume
|
||||
3707 idle
|
||||
4708 save_resume_data
|
||||
4708 idle
|
||||
8230 read 16384
|
||||
8255 idle
|
||||
8431 read 16384
|
||||
|
||||
The script to parse this log and generate a graph is called ``parse_disk_log.py``. It takes
|
||||
the log file as the first command line argument, and produces a file: ``disk_io.png``.
|
||||
The time stamp is in milliseconds since start.
|
||||
|
||||
You can pass in a second, optional, argument to specify the window size it will average
|
||||
the time measurements over. The default is 5 seconds. For long test runs, it might be interesting
|
||||
to increase that number. It is specified as a number of seconds.
|
||||
|
||||
.. image:: disk_io.png
|
||||
|
||||
This is an example graph generated by the parse script.
|
||||
|
||||
disk_buffers.log
|
||||
''''''''''''''''
|
||||
|
||||
The disk buffer log tells you where the buffer memory is used. The log format has a time stamp,
|
||||
the name of the buffer usage which use-count changed, colon, and the new number of blocks that are
|
||||
in use for this particular key. For example::
|
||||
|
||||
23671 write cache: 18
|
||||
23671 receive buffer: 3
|
||||
24153 receive buffer: 2
|
||||
24153 write cache: 19
|
||||
24154 receive buffer: 3
|
||||
24198 receive buffer: 2
|
||||
24198 write cache: 20
|
||||
24202 receive buffer: 3
|
||||
24305 send buffer: 0
|
||||
24305 send buffer: 1
|
||||
24909 receive buffer: 2
|
||||
24909 write cache: 21
|
||||
24910 receive buffer: 3
|
||||
|
||||
The time stamp is in milliseconds since start.
|
||||
|
||||
To generate a graph, use ``parse_disk_buffer_log.py``. It takes the log file as the first
|
||||
command line argument. It generates ``disk_buffer.png``.
|
||||
|
||||
.. image:: disk_buffer_sample.png
|
||||
|
||||
This is an example graph generated by the parse script.
|
||||
|
||||
disk_access.log
|
||||
file_access.log
|
||||
'''''''''''''''
|
||||
|
||||
*The disk access log is now binary*
|
||||
|
||||
The disc access log has three fields. The timestamp (milliseconds since start), operation
|
||||
and offset. The offset is the absolute offset within the torrent (not within a file). This
|
||||
log is only useful when you're downloading a single torrent, otherwise the offsets will not
|
||||
be unique.
|
||||
|
||||
In order to easily plot this directly in gnuplot, without parsing it, there are two lines
|
||||
associated with each read or write operation. The first one is the offset where the operation
|
||||
started, and the second one is where the operation ended.
|
||||
|
||||
Example::
|
||||
|
||||
15437 read 301187072
|
||||
15437 read_end 301203456
|
||||
16651 read 213385216
|
||||
16680 read_end 213647360
|
||||
25879 write 249036800
|
||||
25879 write_end 249298944
|
||||
26811 read 325582848
|
||||
26943 read_end 325844992
|
||||
36736 read 367001600
|
||||
36766 read_end 367263744
|
||||
|
||||
The disk access log does not have any good visualization tool yet. There is however a gnuplot
|
||||
file, ``disk_access.gnuplot`` which assumes ``disk_access.log`` is in the current directory.
|
||||
|
||||
.. image:: disk_access.png
|
||||
|
||||
The density of the disk seeks tells you how hard the drive has to work.
|
||||
The disk access log is a binary file that can be parsed and converted to human
|
||||
readable by the script ``tools/parse_access_log.py``. This tool produces a
|
||||
graphical representation of the disk access and requires ``gnuplot``.
|
||||
|
||||
understanding the disk threads
|
||||
==============================
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ namespace libtorrent
|
|||
// priorities for torrents in share mode, it will make it not work.
|
||||
//
|
||||
// The share mode has one setting, the share ratio target, see
|
||||
// ``session_settings::share_mode_target`` for more info.
|
||||
// ``settings_pack::share_mode_target`` for more info.
|
||||
flag_share_mode = 0x008,
|
||||
|
||||
// determines if the IP filter should apply to this torrent or not. By
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ POSSIBILITY OF SUCH DAMAGE.
|
|||
// alerts (warnings, messages and errors from libtorrent). If no alerts have
|
||||
// been posted by libtorrent pop_alerts() will return an empty list.
|
||||
//
|
||||
// By default, only errors are reported. session_settings::alert_mask can be
|
||||
// By default, only errors are reported. settings_pack::alert_mask can be
|
||||
// used to specify which kinds of events should be reported. The alert mask is
|
||||
// comprised by bits from the category_t enum.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -865,7 +865,7 @@ namespace libtorrent
|
|||
|
||||
// this is the limit on the number of outstanding requests
|
||||
// we have to this peer. This is initialized to the settings
|
||||
// in the session_settings structure. But it may be lowered
|
||||
// in the settings_pack. But it may be lowered
|
||||
// if the peer is known to require a smaller limit (like BitComet).
|
||||
// or if the extended handshake sets a limit.
|
||||
// web seeds also has a limit on the queue size.
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ namespace libtorrent
|
|||
|
||||
// the number of seconds until the current front piece request will time
|
||||
// out. This timeout can be adjusted through
|
||||
// ``session_settings::request_timeout``.
|
||||
// ``settings_pack::request_timeout``.
|
||||
// -1 means that there is not outstanding request.
|
||||
int request_timeout;
|
||||
|
||||
|
|
@ -317,7 +317,7 @@ namespace libtorrent
|
|||
|
||||
// the number of bytes this peer has pending in the disk-io thread.
|
||||
// Downloaded and waiting to be written to disk. This is what is capped
|
||||
// by ``session_settings::max_queued_disk_bytes``.
|
||||
// by ``settings_pack::max_queued_disk_bytes``.
|
||||
int pending_disk_bytes;
|
||||
|
||||
// number of outstanding bytes to read
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ namespace libtorrent
|
|||
// saved when calling save_state().
|
||||
enum save_state_flags_t
|
||||
{
|
||||
// saves settings (i.e. the session_settings)
|
||||
// saves settings (i.e. the settings_pack)
|
||||
save_settings = 0x001,
|
||||
|
||||
// saves dht_settings
|
||||
|
|
@ -844,7 +844,7 @@ namespace libtorrent
|
|||
// aren't working or fail, will automatically be disabled and packets
|
||||
// will flow without using any proxy. If you want to enforce using a
|
||||
// proxy, even when the proxy doesn't work, enable anonymous_mode in
|
||||
// session_settings.
|
||||
// settings_pack.
|
||||
TORRENT_DEPRECATED
|
||||
void set_proxy(proxy_settings const& s);
|
||||
TORRENT_DEPRECATED
|
||||
|
|
@ -957,7 +957,7 @@ namespace libtorrent
|
|||
// The alert queue in the session will not grow indefinitely. Make sure
|
||||
// to pop periodically to not miss notifications. To control the max
|
||||
// number of alerts that's queued by the session, see
|
||||
// ``session_settings::alert_queue_size``.
|
||||
// ``settings_pack::alert_queue_size``.
|
||||
//
|
||||
// Some alerts are considered so important that they are posted even when
|
||||
// the alert queue is full. Some alerts are considered mandatory and cannot
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ namespace libtorrent
|
|||
//
|
||||
// Since this setting sets a hard upper limit on cache usage, it
|
||||
// cannot be combined with
|
||||
// ``session_settings::contiguous_recv_buffer``, since that feature
|
||||
// ``settings_pack::contiguous_recv_buffer``, since that feature
|
||||
// treats the ``cache_size`` setting as a soft (but still pretty hard)
|
||||
// limit. The result of combining the two is peers being disconnected
|
||||
// after failing to allocate more disk buffers.
|
||||
|
|
|
|||
|
|
@ -598,7 +598,7 @@ namespace libtorrent
|
|||
// Explicitly sets the upload mode of the torrent. In upload mode, the
|
||||
// torrent will not request any pieces. If the torrent is auto managed,
|
||||
// it will automatically be taken out of upload mode periodically (see
|
||||
// ``session_settings::optimistic_disk_retry``). Torrents are
|
||||
// ``settings_pack::optimistic_disk_retry``). Torrents are
|
||||
// automatically put in upload mode whenever they encounter a disk write
|
||||
// error.
|
||||
//
|
||||
|
|
@ -1101,7 +1101,7 @@ namespace libtorrent
|
|||
// ``set_download_limit`` works the same way but for download bandwidth
|
||||
// instead of upload bandwidth. Note that setting a higher limit on a
|
||||
// torrent then the global limit
|
||||
// (``session_settings::upload_rate_limit``) will not override the global
|
||||
// (``settings_pack::upload_rate_limit``) will not override the global
|
||||
// rate limit. The torrent can never upload more than the global rate
|
||||
// limit.
|
||||
//
|
||||
|
|
@ -1170,7 +1170,7 @@ namespace libtorrent
|
|||
// at the same time on this torrent. If you set this to -1, there will be
|
||||
// no limit. This defaults to infinite. The primary setting controlling
|
||||
// this is the global unchoke slots limit, set by unchoke_slots_limit in
|
||||
// session_settings.
|
||||
// settings_pack.
|
||||
//
|
||||
// ``max_uploads()`` returns the current settings.
|
||||
void set_max_uploads(int max_uploads) const;
|
||||
|
|
@ -1182,7 +1182,7 @@ namespace libtorrent
|
|||
// must be at least 2. The default is unlimited number of connections. If
|
||||
// -1 is given to the function, it means unlimited. There is also a
|
||||
// global limit of the number of connections, set by
|
||||
// ``connections_limit`` in session_settings.
|
||||
// ``connections_limit`` in settings_pack.
|
||||
//
|
||||
// ``max_connections()`` returns the current settings.
|
||||
void set_max_connections(int max_connections) const;
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ EXTRA_DIST = Jamfile \
|
|||
parse_dht_log.py \
|
||||
parse_dht_rtt.py \
|
||||
parse_dht_stats.py \
|
||||
parse_disk_access.py \
|
||||
parse_access_log.py \
|
||||
parse_disk_buffer_log.py\
|
||||
parse_disk_log.py \
|
||||
parse_memory_log.py \
|
||||
|
|
|
|||
|
|
@ -1,102 +0,0 @@
|
|||
#!/usr/bin/env python
|
||||
|
||||
import os, sys, time
|
||||
|
||||
lines = open(sys.argv[1], 'rb').readlines()
|
||||
|
||||
# logfile format:
|
||||
# <time(us)> <key>: <value>
|
||||
# example:
|
||||
# 16434 read cache: 17
|
||||
|
||||
keys = ['read', 'write', 'head movement', 'seek per read byte', 'seek per written byte',
|
||||
'read operations per second', 'write operations per second']
|
||||
colors = ['305030', '503030', '3030f0', '10a010', 'a01010', 'd0d040', 'd040d0']
|
||||
style = ['dots', 'points', 'lines', 'lines', 'lines', 'lines', 'lines']
|
||||
axis = ['x1y1', 'x1y1', 'x1y2', 'x1y2', 'x1y2', 'x1y2', 'x1y2']
|
||||
plot = [True, False, False, False, False, True, False]
|
||||
|
||||
out = open('disk_access_log.dat', 'w+')
|
||||
|
||||
time = 1000000
|
||||
|
||||
last_pos = 0
|
||||
last_t = 0
|
||||
cur_movement = 0
|
||||
cur_read = 0
|
||||
cur_write = 0
|
||||
cur_read_ops = 0
|
||||
cur_write_ops = 0
|
||||
|
||||
for l in lines:
|
||||
try:
|
||||
# strip newline
|
||||
l = l[0:-1].split(' ')
|
||||
t = int(l[0])
|
||||
k = l[1]
|
||||
n = int(l[2])
|
||||
except:
|
||||
print l
|
||||
continue
|
||||
|
||||
read = '-'
|
||||
write = '-'
|
||||
movement = '-'
|
||||
amount_read = '-'
|
||||
amount_write = '-'
|
||||
read_ops = '-'
|
||||
write_ops = '-'
|
||||
if k == 'read':
|
||||
read = '%d' % n
|
||||
cur_read_ops += 1
|
||||
if k == 'write':
|
||||
write = '%d' % n
|
||||
cur_write_ops += 1
|
||||
if k == 'read_end': cur_read += n - last_pos
|
||||
if k == 'write_end': cur_write += n - last_pos
|
||||
|
||||
cur_movement += abs(last_pos - n)
|
||||
last_pos = n
|
||||
|
||||
if last_t + time <= t:
|
||||
movement = '%d' % cur_movement
|
||||
if cur_read > 0:
|
||||
amount_read = '%d' % (cur_movement / cur_read)
|
||||
if cur_write > 0:
|
||||
amount_write = '%d' % (cur_movement / cur_write)
|
||||
read_ops = '%d' % cur_read_ops
|
||||
write_ops = '%d' % cur_write_ops
|
||||
cur_movement = 0
|
||||
cur_read = 0
|
||||
cur_write = 0
|
||||
last_t = t
|
||||
cur_read_ops = 0
|
||||
cur_write_ops = 0
|
||||
|
||||
print >>out, '%d\t%s\t%s\t%s\t%s\t%s\t%s\t%s' % (t, read, write, movement, amount_read, amount_write, read_ops, write_ops)
|
||||
|
||||
out.close()
|
||||
|
||||
out = open('disk_access.gnuplot', 'wb')
|
||||
print >>out, "set term png size 1200,700"
|
||||
print >>out, 'set output "disk_access.png"'
|
||||
print >>out, 'set xrange [*:*]'
|
||||
#print >>out, 'set y2range [0:*]'
|
||||
print >>out, 'set xlabel "time (us)"'
|
||||
print >>out, 'set ylabel "drive offset"'
|
||||
#print >>out, 'set y2label "bytes / %d second(s)"' % (time / 1000)
|
||||
print >>out, "set key box"
|
||||
print >>out, "set tics nomirror"
|
||||
print >>out, "set y2tics auto"
|
||||
print >>out, 'plot',
|
||||
count = 1
|
||||
for k in keys:
|
||||
count += 1
|
||||
if not plot[count-2]: continue
|
||||
print >>out, ' "disk_access_log.dat" using 1:%d title "%s" with %s lt rgb "#%s" axis %s,' \
|
||||
% (count, k, style[count-2], colors[count-2], axis[count-2]),
|
||||
print >>out, 'x=0'
|
||||
out.close()
|
||||
|
||||
os.system('gnuplot disk_access.gnuplot')
|
||||
|
||||
Loading…
Reference in New Issue