<br><tt><font size=2>We've narrowed down the problem quite a bit.<br>
<br>
The problematic code snippet is not actually doing any reads or writes;
<br>
it's just doing a massive number of fseek() operations within a couple
<br>
of nested loops.  (Note: The production code is doing some I/O, but
this <br>
snippet was narrowed down to the bare minimum example that exhibited the
<br>
problem, which was how we discovered that fseek was the culprit.)<br>
<br>
The issue appears to be the behavior of the glibc implementation of <br>
fseek().  Apparently, a call to fseek() on a buffered file stream
causes <br>
glibc to flush the stream (regardless of whether a flush is actually <br>
needed).  If we modify the snippet to call setvbuf() and disable <br>
buffering on the file stream before any of the fseek() calls, then it <br>
finishes more or less instantly, as you would expect.<br>
<br>
The problem is that this offending code is actually buried deep within
a <br>
COTS library that we're using to do image processing (the Hierarchical
<br>
Data Format (HDF) library).  While we do have access to the source
code <br>
for this library and could conceivably modify it, this is a large and <br>
complex library, and a change of this nature would require us to do a <br>
large amount of regression testing to ensure that nothing was broken.<br>
<br>
So at the end of the day this is really not a "Lustre problem"
per se, <br>
though we would still be interested in any suggestions as to how we can
<br>
minimize the effects of this glibc "flush penalty".  This
penalty is not <br>
particularly onerous when reading and writing to local disk, but is <br>
obviously more of an issue with a distributed filesystem.</font></tt>
<br><font size=2 face="sans-serif"><br>
Thank you again for the support.</font>
<br>
<br><font size=2 face="sans-serif">Rocky <br>
<br>
</font>
<br>
<br>
<br><tt><font size=2>On Wed, 2010-04-14 at 07:08 -0500, Ronald K Long wrote:<br>
> <br>
> Andreas - Here is a snipet of the strace output. <br>
> <br>
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0<br>
> \0\0"..., 2097152) = 2097152 <br>
<br>
As Andreas suspected, your application is doing 2MB reads every time.<br>
Does it really need 2MB of data on each read?  If not, can you fix
your<br>
application to only read as much data as it actually wants?<br>
<br>
b.<br>
</font></tt>
<br>