qBittorrent and disk performance
-
fusk
Re: qBittorrent and disk performance
I guess you can do that with such a large cache, my drives aren't usually inactive even with 16gb cache. But seeding with 80mb/s doesn't seem to be a problem with little drive activity. But i guess that makes sense as my total size loaded in qbit right now is about 600/700gb & i'd need a 1tb drive if i wanted to cache all of my torrents.
-
fusk
Re: qBittorrent and disk performance
Just out of curiosity, now that libtorrent 1.0 has been released and the work on 1.1.x probably has increased. Will we see an unofficial build ?
-
sledgehammer_999
- Administrator
- Posts: 2443
- Joined: Sun Jan 23, 2011 1:17 pm
Re: qBittorrent and disk performance
I have tested 1.1.0 locally but it crashes upon writing the first data to disk. I need to report this upstream sometime...
-
fusk
Re: qBittorrent and disk performance
Hopefully the development on 1.1.0 increases enough for an unofficial build to be possible in the near future.
-
Switeck
Re: qBittorrent and disk performance
[quote="fusk"]@pentium100
I know your feeling man. I my self have 800+ mbit and it just kills any harddrive almost instantly with too many i/o operations. I have 2 sshd's in raid0 and 15/20 mb/s is max.
However, that is on multifiled torrents, on singlefiled torrents 50 mb/s is not a problem.
Need a big ass raid to keep up on multifiled torrents, i'd probably have to add 1 or 2 more sshd's to get there, and i'm not really willing to do that. But 4x1TB/8GB would be nice.[/quote]As you have correctly surmised, multi-file torrents download and upload much slower than single file torrents.
The reason why is because the end of each file in a multi-file torrent probably doesn't line up exactly with the end of a torrent piece.
The end of the 1st file probably shares a piece with the 2nd file. When that piece gets written to the drive, the drive has to do 2 separate writes -- writing out the end of the 1st file and then writing the start of the 2nd. The next piece of the 2nd file is also likely misaligned with the start of that file's cluster location on the drive -- so once again multiple writes are needed to commit it to disk. Even the 16 KB chunk size may be misaligned at the end of a file and beginning of the next! End result -- a multi-file torrent uses at least 2 times as many disk writes as a single file torrent of the same total size.
You pretty much end up with misaligned data somewhat like described here:
http://www.percona.com/blog/2011/06/09/ ... he-theory/
It would be even worse to use BitTorrent to download many multi-file torrents at once on a spinning platter HDD RAID 0 array that's misaligned, because that's closer to what the article was talking about. You'd end up with severe fragmentation on top of misalignment.
http://vmdamentals.com/?p=2246
"The impact of a misaligned write on a RAID stripe can be ...an absolute performance-killer."
...And worse still to do it on a SSD RAID 0 array because of write amplification:
http://en.wikipedia.org/wiki/Write_amplification
"Because flash memory must be erased before it can be rewritten, the process to perform these operations results in moving (or rewriting) user data and metadata more than once. This multiplying effect increases the number of writes required over the life of the SSD which shortens the time it can reliably operate. The increased writes also consume bandwidth to the flash memory which mainly reduces random write performance to the SSD.[1][2] Many factors will affect the write amplification of an SSD; some can be controlled by the user and some are a direct result of the data written to and usage of the SSD."
...
"Even after the OS and SSD are configured to support the TRIM command, other conditions might prevent any benefit from TRIM. As of early 2010[update], databases and RAID systems are not yet TRIM-aware and consequently will not know how to pass that information on to the SSD. In those cases the SSD will continue to save and garbage collect those blocks until the OS uses those LBAs for new writes."
So running 2 SSDs in a RAID 0 striped array may be very bad for them if using older RAID controllers and/or lacking latest drivers and OS.
Better to run the SSDs separately and put torrents on both for seeding.
If torrents are small enough, download them to a "scratch" drive:
http://en.wikipedia.org/wiki/Scratch_space
...and then move them to their final storage location on a second drive to almost eliminate file fragmentation.
In qBitTorrent's menu -- Tools, Options, Downloads can be set to do this for you automatically.
Set where to save incomplete downloads to another drive and have it move/copy them when done.
I don't recommend doing this from 1 SSD to another though, because:
http://en.wikipedia.org/wiki/Temporary_folder
"A Flash-based solid-state drive is less suitable as a temporary-storage device for reading and writing due to the asymmetric read/write duration and due to wear. (See wear leveling.)"
Even downloading to a ramdrive (as the temp folder, then having qBT auto-move the completed torrent/s to the SSDs) can work if you have crazy amounts of ram and/or don't download giant torrents. Some ramdrive software backs up the ramdrive's contents to hdd/ssd on shutdown and reloads it on startup, though this can slow down rebooting. But if power goes out while you're downloading...you lose the whole download.
I know your feeling man. I my self have 800+ mbit and it just kills any harddrive almost instantly with too many i/o operations. I have 2 sshd's in raid0 and 15/20 mb/s is max.
However, that is on multifiled torrents, on singlefiled torrents 50 mb/s is not a problem.
Need a big ass raid to keep up on multifiled torrents, i'd probably have to add 1 or 2 more sshd's to get there, and i'm not really willing to do that. But 4x1TB/8GB would be nice.[/quote]As you have correctly surmised, multi-file torrents download and upload much slower than single file torrents.
The reason why is because the end of each file in a multi-file torrent probably doesn't line up exactly with the end of a torrent piece.
The end of the 1st file probably shares a piece with the 2nd file. When that piece gets written to the drive, the drive has to do 2 separate writes -- writing out the end of the 1st file and then writing the start of the 2nd. The next piece of the 2nd file is also likely misaligned with the start of that file's cluster location on the drive -- so once again multiple writes are needed to commit it to disk. Even the 16 KB chunk size may be misaligned at the end of a file and beginning of the next! End result -- a multi-file torrent uses at least 2 times as many disk writes as a single file torrent of the same total size.
You pretty much end up with misaligned data somewhat like described here:
http://www.percona.com/blog/2011/06/09/ ... he-theory/
It would be even worse to use BitTorrent to download many multi-file torrents at once on a spinning platter HDD RAID 0 array that's misaligned, because that's closer to what the article was talking about. You'd end up with severe fragmentation on top of misalignment.
http://vmdamentals.com/?p=2246
"The impact of a misaligned write on a RAID stripe can be ...an absolute performance-killer."
...And worse still to do it on a SSD RAID 0 array because of write amplification:
http://en.wikipedia.org/wiki/Write_amplification
"Because flash memory must be erased before it can be rewritten, the process to perform these operations results in moving (or rewriting) user data and metadata more than once. This multiplying effect increases the number of writes required over the life of the SSD which shortens the time it can reliably operate. The increased writes also consume bandwidth to the flash memory which mainly reduces random write performance to the SSD.[1][2] Many factors will affect the write amplification of an SSD; some can be controlled by the user and some are a direct result of the data written to and usage of the SSD."
...
"Even after the OS and SSD are configured to support the TRIM command, other conditions might prevent any benefit from TRIM. As of early 2010[update], databases and RAID systems are not yet TRIM-aware and consequently will not know how to pass that information on to the SSD. In those cases the SSD will continue to save and garbage collect those blocks until the OS uses those LBAs for new writes."
So running 2 SSDs in a RAID 0 striped array may be very bad for them if using older RAID controllers and/or lacking latest drivers and OS.
Better to run the SSDs separately and put torrents on both for seeding.
If torrents are small enough, download them to a "scratch" drive:
http://en.wikipedia.org/wiki/Scratch_space
...and then move them to their final storage location on a second drive to almost eliminate file fragmentation.
In qBitTorrent's menu -- Tools, Options, Downloads can be set to do this for you automatically.
Set where to save incomplete downloads to another drive and have it move/copy them when done.
I don't recommend doing this from 1 SSD to another though, because:
http://en.wikipedia.org/wiki/Temporary_folder
"A Flash-based solid-state drive is less suitable as a temporary-storage device for reading and writing due to the asymmetric read/write duration and due to wear. (See wear leveling.)"
Even downloading to a ramdrive (as the temp folder, then having qBT auto-move the completed torrent/s to the SSDs) can work if you have crazy amounts of ram and/or don't download giant torrents. Some ramdrive software backs up the ramdrive's contents to hdd/ssd on shutdown and reloads it on startup, though this can slow down rebooting. But if power goes out while you're downloading...you lose the whole download.
Re: qBittorrent and disk performance
Well explained, thanks for your input Switeck 
.
.-
fusk
Re: qBittorrent and disk performance
Indeed, nice article, even i understood most of it.
But as i understand it, there's not really anything we can do about misalignment with multi-file torrents.
But as i understand it, there's not really anything we can do about misalignment with multi-file torrents.
-
Michaelfum
qBittorrent and disk performance
Maybe i could add that in soon
to be honest i just wanted to go the easiest and basic way to get around to doing it, i find the boot discs are pretty quick anyway. But Ii go edit the boot disk section to state that a USB boot drive can be used
edit added the USB tutorial to section A.1
to be honest i just wanted to go the easiest and basic way to get around to doing it, i find the boot discs are pretty quick anyway. But Ii go edit the boot disk section to state that a USB boot drive can be used
edit added the USB tutorial to section A.1
-
Robertomcat
Re: qBittorrent and disk performance
Hello good afternoon. I recently opened a post to explore the possibility of an advanced configuration for qBT from the hardware mentioned.
https://qbforums.shiki.hu/index.php/topic,6540.0.html
Since in this post you talk about the issue of RAID, I wanted to tell you about a configuration that I am currently using in a RAID 5 8x6TB. In this case all discs are identical, so there is no difference between write/read rates and IOPS. Currently, this RAID is used entirely for the tasks of qBT, in which 80% is dedicated exclusively to reading. The band size that I am using is the one I show below in the photo:
This is not the default size configured by the hardware controller when the RAID is made from the beginning, but I have modified it due to the information that I have been able to read through different blogs, which say that a larger band size is better for write / read loads in large files (everything you stored there today is multimedia). Once the RAID is created from the HP software, then you have to assign a volume and sector size to the volume, so Windows is of a very large size, and it automatically assigns 64k to the sectors.
Any additional recommendation?
https://qbforums.shiki.hu/index.php/topic,6540.0.html
Since in this post you talk about the issue of RAID, I wanted to tell you about a configuration that I am currently using in a RAID 5 8x6TB. In this case all discs are identical, so there is no difference between write/read rates and IOPS. Currently, this RAID is used entirely for the tasks of qBT, in which 80% is dedicated exclusively to reading. The band size that I am using is the one I show below in the photo:
This is not the default size configured by the hardware controller when the RAID is made from the beginning, but I have modified it due to the information that I have been able to read through different blogs, which say that a larger band size is better for write / read loads in large files (everything you stored there today is multimedia). Once the RAID is created from the HP software, then you have to assign a volume and sector size to the volume, so Windows is of a very large size, and it automatically assigns 64k to the sectors.
Any additional recommendation?
Last edited by Robertomcat on Sun Jan 13, 2019 3:27 pm, edited 1 time in total.
-
Switeck
Re: qBittorrent and disk performance
When qBitTorrent is downloading from lots of peers+seeds at once, it may be trying to write to disk in 16 KB chunks that are not sequential on top of not being aligned with a sector or underlying disk cluster.
Using fewer peers+seeds at once will at least make some of download sequential -- at least at the piece level, if the speeds per peer/seed is >500 KiB/sec.
This requires typically downloading only 1 torrent at a time and a lower max peer limit PER torrent and a lower upload slot max per torrent... like 20-50 max connections per torrent and 10-20 max upload slots per torrent.
For full benefit even from that requires a HDD format that has write-in-place and maybe also doesn't do journaling.
Otherwise, only downloading to another drive and then copying to final destination will almost totally avoid file fragmentation...which should at least make seeding from the destination drive/s quicker.
The CPU and disk I/O crunch when copying to the final drive/s can be nasty though!
Using fewer peers+seeds at once will at least make some of download sequential -- at least at the piece level, if the speeds per peer/seed is >500 KiB/sec.
This requires typically downloading only 1 torrent at a time and a lower max peer limit PER torrent and a lower upload slot max per torrent... like 20-50 max connections per torrent and 10-20 max upload slots per torrent.
For full benefit even from that requires a HDD format that has write-in-place and maybe also doesn't do journaling.
Otherwise, only downloading to another drive and then copying to final destination will almost totally avoid file fragmentation...which should at least make seeding from the destination drive/s quicker.
The CPU and disk I/O crunch when copying to the final drive/s can be nasty though!
-
Robertomcat
Re: qBittorrent and disk performance
[quote="Switeck"]
When qBitTorrent is downloading from lots of peers+seeds at once, it may be trying to write to disk in 16 KB chunks that are not sequential on top of not being aligned with a sector or underlying disk cluster.
Using fewer peers+seeds at once will at least make some of download sequential -- at least at the piece level, if the speeds per peer/seed is >500 KiB/sec.
This requires typically downloading only 1 torrent at a time and a lower max peer limit PER torrent and a lower upload slot max per torrent... like 20-50 max connections per torrent and 10-20 max upload slots per torrent.
For full benefit even from that requires a HDD format that has write-in-place and maybe also doesn't do journaling.
Otherwise, only downloading to another drive and then copying to final destination will almost totally avoid file fragmentation...which should at least make seeding from the destination drive/s quicker.
The CPU and disk I/O crunch when copying to the final drive/s can be nasty though!
[/quote]
I've been testing on a mechanical hard drive to put it in the temporary folder, but the write/read speeds, plummet, can't withstand the double load.
What I'm going to do, is get Windows to defragment the RAID5 as much as it can, and look for some solid-state disk that has a good TBW or PBW and incorporate it into the temporary folder.
So you recommend that the band size be changed to KiB? How could it benefit the disks to be more efficient in both reading and writing?
When qBitTorrent is downloading from lots of peers+seeds at once, it may be trying to write to disk in 16 KB chunks that are not sequential on top of not being aligned with a sector or underlying disk cluster.
Using fewer peers+seeds at once will at least make some of download sequential -- at least at the piece level, if the speeds per peer/seed is >500 KiB/sec.
This requires typically downloading only 1 torrent at a time and a lower max peer limit PER torrent and a lower upload slot max per torrent... like 20-50 max connections per torrent and 10-20 max upload slots per torrent.
For full benefit even from that requires a HDD format that has write-in-place and maybe also doesn't do journaling.
Otherwise, only downloading to another drive and then copying to final destination will almost totally avoid file fragmentation...which should at least make seeding from the destination drive/s quicker.
The CPU and disk I/O crunch when copying to the final drive/s can be nasty though!
[/quote]
I've been testing on a mechanical hard drive to put it in the temporary folder, but the write/read speeds, plummet, can't withstand the double load.
What I'm going to do, is get Windows to defragment the RAID5 as much as it can, and look for some solid-state disk that has a good TBW or PBW and incorporate it into the temporary folder.
So you recommend that the band size be changed to KiB? How could it benefit the disks to be more efficient in both reading and writing?
-
Switeck
Re: qBittorrent and disk performance
Leave the band size as it is for now.
qBitTorrent v4.1.5 should be far less hard on them than qBitTorrent v4.1.0 and earlier, due to supporting coalesce reds/writes.
(You may have noticed that already.)
I use a ramdrive for a temp folder, but I typically download small torrents of less than 4 GB size each.
The few larger torrents I have to download straight to my hard drives...but I can move them from one to another to defragment them that way.
qBitTorrent v4.1.5 should be far less hard on them than qBitTorrent v4.1.0 and earlier, due to supporting coalesce reds/writes.
(You may have noticed that already.)
I use a ramdrive for a temp folder, but I typically download small torrents of less than 4 GB size each.
The few larger torrents I have to download straight to my hard drives...but I can move them from one to another to defragment them that way.
-
Robertomcat
Re: qBittorrent and disk performance
[quote="Switeck"]
Leave the band size as it is for now.
qBitTorrent v4.1.5 should be far less hard on them than qBitTorrent v4.1.0 and earlier, due to supporting coalesce reds/writes.
(You may have noticed that already.)
I use a ramdrive for a temp folder, but I typically download small torrents of less than 4 GB size each.
The few larger torrents I have to download straight to my hard drives...but I can move them from one to another to defragment them that way.
[/quote]
Well, for now, I'll leave the band size as it is.
Yes, it is interesting to use ramdrive, but sometimes I download files from 20 to 70GB. I will have to investigate the read and write speeds of SSD disks connected via USB 3.0. Have you had experiences with the read/write speeds of SSDs via USB?
Leave the band size as it is for now.
qBitTorrent v4.1.5 should be far less hard on them than qBitTorrent v4.1.0 and earlier, due to supporting coalesce reds/writes.
(You may have noticed that already.)
I use a ramdrive for a temp folder, but I typically download small torrents of less than 4 GB size each.
The few larger torrents I have to download straight to my hard drives...but I can move them from one to another to defragment them that way.
[/quote]
Well, for now, I'll leave the band size as it is.
Yes, it is interesting to use ramdrive, but sometimes I download files from 20 to 70GB. I will have to investigate the read and write speeds of SSD disks connected via USB 3.0. Have you had experiences with the read/write speeds of SSDs via USB?