Sebastian Brings wrote:
In a different thread I read about the largeio mount option for XFS. Now
I wonder if the problems I recently ran in have been caused by this.
After a system uprgade from sles9 sp2 to sp3 one app started
misbehaving. Before the upgrade it used 15% CPU, after the upgrade it
was 90+% and the performance dropped by about 50%. The app is writing a
wave audio file, and for every 3840 bytes of audio samples it appends,
it updates the RIFF header of the file. All of this was done using the
buffered fopen/fwrite/... C library functions.
An strace showed that seeking to the beginning of the file also
triggered a 12MiB read(2) call, and seeking to the end, for example to
13MiB, translated to a seek(2) to offset 1mib and a read(2) of 12 MiB.
Initiall I assumed something very strange had happened to the C lib
defaults. Otoh 12MiB is the swidth of the filesystem, so I assume that
the C lib got the 12 MiB optimal IO size from XFS and therefore behaved
as described above. Could that be?
Unless you specify the largeio mount option, I don't -think- any of this is
exposed.
What does stat -c %o <file> say?
Did this strace behavior change from sp2 to sp3?
-Eric
|