[PVFS2-developers] CVS pvfs2-server server daemons crashing

[Brian D. Haymore]

Just as a light follow up on this.  We have been running all weekend 
without any additional issue thus far.  I've had a bonnie 1.2 loop 
running modified to write in its "intelligent" parts with a 4MB buffer 
vs the default 16k.  Here is a snip of the bonnie numbers I'm seeing. 
Note all nodes are gigE attached same switch, 1 client for this test and 
4 servers.

Bonnie 1.2: File './Bonnie.11986', size: 17179869184, volumes: 1
Writing with putc_unlocked()...done:  46709 kB/s  35.5 %CPU
Rewriting...                   done:  43023 kB/s  11.3 %CPU
Writing intelligently...       done:  54639 kB/s   6.8 %CPU
Reading with getc_unlocked()...done:  49700 kB/s  51.5 %CPU
Reading intelligently...       done:  93914 kB/s  12.4 %CPU


The only odd thing I've seen, and its not tied to this CVS version as 
I've seen it in all pvfs2 versions so far, is that bonnie 1.2 was 
getting better default performance with the putc/getc operations then it 
did on the default 16k intelligent read/write sections by large amount. 
  This is different then pvfs 1.x where intelligent read/writes where 
better then the putc/getc.  This is not presenting real application 
performance problems for us just an observation to pass you way.

Robert Latham wrote:
> On Thu, Jun 02, 2005 at 05:01:39PM -0400, Pete Wyckoff wrote:
> 
>>robl at mcs.anl.gov wrote on Thu, 02 Jun 2005 15:44 -0500:
>>
>>>Walt and I were talking and we figure there is probably more than one
>>>place with a bug of this class.   Is there a way to gaurantee we zero
>>>out every bit of these decoded requests?
>>
>>To guarantee is kind of tough, you know.  I think we may be approaching
>>the last of the problems, though---as we get more people using native
>>64-bit machines that will take care of it.  
> 
> 
> Ok, I've committed Pete's proposed fix to CVS.  Thanks Walt and Pete
> for all the help understanding what the request encoder/decoder is
> doing. 
> 
> Brian, i've only tested with bonnie++ so far (which is *still*
> creating files sequentially...).  Can you pull from cvs and try some
> of your tests again?  I'm only testing with a single (x86) client and
> single (opteron) server, and only testing through the VFS.   
> 
> ==rob
> 

-- 
Brian D. Haymore
University of Utah
Center for High Performance Computing
155 South 1452 East RM 405
Salt Lake City, Ut 84112-0190
Phone: (801) 558-1150, Fax: (801) 585-5366
http://www.map.utah.edu/umaplink/0019.html