CODEWITHSUNDEEP
.netwindowsmultithreadingperformanceio
Joppe
Joppe

Reputation: 1524

Is it worth synchronizing I/O intensive threads in order to increase total disk performance?

Our Windows .NET application has several I/O intensive threads that are writing to the disk (rotational media) constantly. A write operation from one thread is done without it being aware of the other thread's write operations, so this means that the write requests hits the Windows I/O manager in the same order that the calls happens to be performed.

There has been a discussion in our project if this is the right way to do it or if we could gain some performance by synchronizing the write operations so that only one (or a few) thread(s) ever perform a write operation to the disk at the same time (maybe by a shared lock). The theory is that this would put less strain on the CPU and also give us better throughput (please note that we are already using asynchronous I/O for all our operations).

I'm a bit skeptical to this whole idea, since I think we would then be doing part of the job that the operating system originally was designed to solve. Have now performed some experimentation and it points in the direction that there are no benefits at all. It is my impression that, as long as the buffer sizes are sufficient, the decision when to write blocks to the disk is better left to the operating system to decide.

So could someone please enlight us? Is it a good idea to synchronize disks access from a multithreaded process in order to gain performance? Are there any differences in this regard between e.g Windows or Linux?

Upvotes: 4

Views: 299

Answers (1)

usr
usr

Reputation: 171246

The theory is that this would put less strain on the CPU

How could it? It's the same number of writes but now with added synchronization. It will create (a little) more CPU load.

we would then be doing part of the job that the operating system originally was designed to solve.

Sadly, Windows is not capable of performing any kind of intelligent IO scheduling. I'm unsure what the disk driver does. With NCQ and SATA there certainly is some degree of reordering of operations. But I have never observed Windows do something intelligent regarding IO (except prefetching which works well).

The main question is whether you want to perform sequential or random IO.

  1. Sequential: Multiple sequential streams result in Windows breaking up the streams into 64KB or 256KB chunks making them highly random. This is truly awful. In this case you can gain orders of magnitude performance by intelligently issuing large IOs.
  2. Random: Issue many IOs at once so that the disk hardware can reorder them. SQL Server for example sometimes issues thousands (and totally blocks out other processes during that time - be aware of that. Windows has no practically working notion of IO fairness.)

I don't know much about Linux but at least it has some kind of IO scheduling. The Windows team does not seem to want to address this.

Upvotes: 3

Related Questions