Re: Strange write starvation on 2.6.17 (and other) kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In article <[email protected]>,
Andrzej Szymanski  <[email protected]> wrote:
>I've encountered a strange problem - if an application is sequentially 
>writing a large file on a busy machine, a single write() of 64KB may 
>take even 30 seconds. But if I do fsync() after each write() the maximum 
>time of write()+fsync() is about 0.5 second (the overall performance is, 
>of course, degraded).

I'm seeing something similar.

I upgraded one of our newsrouters from 2.6.14.2 to 2.6.17.8 because
I needed ethernet bonding with vlan support.

It performs quite a bit worse now that before. The nightly report
that the INN software writes, tells me that the average write()
time (of the single threaded innd process to news storage) went
up from min/avg/max  0.942/1.716/2.337 ms to min/avg/max
2.952/4.553/5.658 ms.

The innd process writes to a simple filesystem I wrote myself that
shows a blockdevice as a single large file. It's a bit more efficient
than using the blockdevice directly.

So I don't see large write delays, but the average write() time
has gone up significantly (bad in my case, since it starves the
innd process).

Since I've also had several unexplained hangs I'm going back
to 2.6.14.x for now, since this machine is too important .. as
soon as I've got some more redundancy I'll experiment some more.

Mike.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux