2

Summary

  • From a traditional (spinning platters) hard disk
  • read one big file, get good performance
  • read another big file simultaneously, get total throughput divided by 5 to 10. Quite a performance drop!

Plus the disk head mechanically moving back and forth several times per second can be heard and felt with the hand. Also after a few hours temperature was observed to be higher.

If this happens rarely or for a short amount of time, that's ok. If this is often or for an extended period of time, not only performance is bad and it announces shorter lifespan.

Example

  • Disk: a 2 terabyte Western Digital disk.
  • Throughput when reading one big file can be 50-100MB/s.
  • Effect most extreme with big files: video files (example 1GB to 13GB in size). Also happens when reading raw photo (~25MB) files.
  • As soon as another program reads another file simultaneously, total throughput drops to 5-10MB/s.

Additional information

It's not a matter of file fragmentation. If files were fragmented, throughput would be slow (much slower than nominal 50-100MB/s) even when reading only one file.

Question

Can something be done to get total throughput reasonably high when reading several big files simultaneously?

2 Answers 2

2

Quick answer

  • (1) Figure out what is the correct block device (for example with mount).
  • (2) Get root permission.
  • (3) Tune read_ahead_kb for the device.

In my case, issuing this command:

echo 100000 > /sys/block/sdb/queue/read_ahead_kb

brought back performance and mechanical relief in a matter of seconds.

What does this parameter change mean concretely?

TL;DR: it causes the kernel to read big files in one go, which means only one back-and-forth mechanical motion instead of many, solving the problem.

More precisely, this parameter tells the kernel that when it opens a file, you allow it to read in advance a lot of data (in this case, up to 100MB, from the default 128kB) even before knowing if the process requesting the read will actually need that much data. As a result, with an example of a process opening a 30MB file (typical raw photo) while another process already reads as much as possible other file(s), then instead of having the mechanical head move back and forth at least (30000/128)=234 times guaranteed, the kernel knows you allow it to possibly read all the file at once, making just one back-and-forth mechanical motion.

The downside is, if you only need part of the file (e.g. a 100kB thumbnail from a 30MB file), the kernel might (or might decide to not) read too much data. Also, the data being read will occupy some RAM pages which increases memory pressure. Linux being made for general purpose, including servers with lot of parallel activity and memory pressure, it certainly has a number of heuristics to guess what to do. The truth is in the kernel source code.

Why this value?

Default value is 128. I observed some effect increasing it to other values first, like 4096, and got satisfied at 100000, but I guess (1) most of the effect is obtained with initial increase, (2) most ill-effects (if any depending on the situation, like memory pressure) are proportional to the value and (3) there might be some value above which increasing does not actually change anything.

But what about your situation?

Details

Or you might as well use the source, luke:

0

Spoiler: There will be a YES answer at the bottom of the post

Short answer:
NO.

Medium-sized answer:
NO, because
there are 2 processes that want to access one ressource (the hard disk) at the same time. Each process will read different data, so the head needs to jump to the place where the process needs data from the platter. This jumps take a lot of time and decrease the total throughput of your hard-disk a lot!

Long answer,
because you seem to lack some (basic) understanding of the working principle of a hard disk:
NO, because
your spinning platters hard drive behaves like a book.

Imagine that you have a book with only empty pages. That's your hard disk when you buy it. No data stored on it.
Then you put it into your computer (let's say as a 2nd drive, so we don't have to deal with the operating system here).
When you write a long text document (called 'text A') and save it on the disk, then it's like writing the first 10 pages (pages 1 to 10) in your book. Then you copy a jpg picture onto the disk, that's like make a drawing of your house on the next 5 free pages in your book (p. 11-15).
The table of content of your book now has 2 entries:

  • text A: p. 1-10
  • pic of house: p. 11-15

All data on your hard disk can be erased again, that's why you have written and drawn everything with a pencil, and not a ball-pen.
Now you write a shopping list into your book: p. 16-17.
Next, you don't like or need that drawing any more and want to erase it, so you remove it with a rubber. Pages 11-15 are blank.
Your TOC looks like:

  • text A: p. 1-10
  • shopping list: p. 16-17

Now you want to draw an image of the local supermarket, which is bigger than your house. So you need 12 pages. You could start at page 11, which means you'd have not enough consecutive pages and you need to continue at 18, or you could start at 18 and have enough space to draw it in one go.
Most or all operating systems are smart enough to choose a chunk of free space that is large enough for the whole data, but if there is no sufficiently large free space, it will have to divide the file into smaller pieces that fit into the existing free areas. This is called Fragmentation.
Let's imagine you also need to do that. Your TOC looks like:

  • text A: p. 1-10
  • pic of supermarket, fragment 1 of 2: p. 11-15
  • shopping list: p. 16-17
  • pic of supermarket, fragment 2 of 2: p. 18-24

Now we start READING the book.
You want to know the items on your shopping list. The TOC tells you to go to page 16. You start reading until you reach the bottom of p.17. Done.
Next: you want to see how the supermarket looks like where you want to go shopping. The TOC tells you to go to p.11 (you are on p.18 (= end of p.17) and have to browse 7 pages back. On a hard disk the read-write head needs to do a jump. Then you start reading until you reach end of p.15, then you browse to p.18 (head jumps again) and continue.

Browsing in a book takes less time than reading, but on a hard-disk it's almost the other way round. The head cannot just move to the next track/cylinder, but has to 'search' the correct cylinder (acceleration, motion, deceleration, settling time). See Wikipedia. So due to fragmentation your reading takes longer than if the file was stored consecutively.

And now, we do READING WITH 2 PEOPLE:
You want to see the supermarket image and I want to read your text A.
You browse to page 11 and start reading.
When you have read p.11, I browse to p.1 and start reading.
When I have read. p.1, you browse to p.12 and continue reading.
When you have read. p.12, I browse to p.2 and continue reading.
...
you can imagine that it takes a lot longer to read the pages just because the many browsing takes so long.
Same with your hard-disk. You can't do nothing about it but avoiding simultaneous access as this always makes it slower.

Now, finally, the YES answer:
YES: Buy a SSD.
This is a electronic disk and it operates like RAM, so you have almost no seek times and the total throughput is always close to the maximum possible throughput (if there are no other bottlenecks elsewhere).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .