<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi<br>
Turning off debuging made it much better.<br>
It went from 1m54 down to 25 seconds, but still 85% of system
processing...<br>
I really think you should turn off debuging by default, or make it
appear as a BIG warning message.<br>
People who are trying lustre for the first time are not going to debug
lustre...<br>
Also, looking in the documentation, though the debugging was
documented, it was not clear that removing it would improve performance
so much.<br>
<br>
I will now make more tests and see how the coherency is...<br>
Thanks for your support.<br>
<br>
Andreas Dilger a écrit :
<blockquote cite="mid:20080229194602.GL2997@webber.adilger.int"
type="cite">
<pre wrap="">On Feb 29, 2008 15:37 +0100, Joe Barjo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We have a (small) 30 node sge based cluster with centos4 which will be
growing to maximum 50 core duos.
We use custom software that is based on gmake to launch parallel
compilation and computations with lot of small files and some large files.
We actualy use nfs and have a lot of problems with incoherencies between
nodes.
I'm currently evaluating lustre and have some questions about lustre
overhead with small files.
I succesfully installed the rpms on a test machine and launched the
local lmount.sh script.
</pre>
</blockquote>
<pre wrap=""><!---->
Note that if you are using the unmodified llmount.sh script this is running
on loopback files in /tmp, so the performance is likely quite bad. For
a realistic performance measure, put the MDT and OST on separate disks.
</pre>
<blockquote type="cite">
<pre wrap="">The first thing I tried is to make a svn checkout into it. (lot of small
files...)
It takes 1m54 from our local svn server versus 15s into a local ext3
filesystem and 50s over nfs network.
During the checkout, the processor (amd64 3200) is busy with 90% system.
How come is there so much system process?
</pre>
</blockquote>
<pre wrap=""><!---->
Have you turned off debugging (sysctl -w lnet.debug=0)?
Have you increased the DLM lock LRU sizes?
for L in /proc/fs/lustre/ldlm/namespaces/*/lru_size; do
echo 10000 > $L
done
In 1.6.5/1.8.0 it will be possible to use a new command to set
this kind of parameter easier:
lctl set_param ldlm.namespaces.*.lru_size=10000
</pre>
<blockquote type="cite">
<pre wrap="">Is there something to tweak to lower this overhead?
Is there a specific tweak for small files?
</pre>
</blockquote>
<pre wrap=""><!---->
Not really, this isn't Lustre's strongest point.
</pre>
<blockquote type="cite">
<pre wrap="">Using multiple server nodes, will the performance be better?
</pre>
</blockquote>
<pre wrap=""><!---->
Partly. There can only be a single MDT per filesystem, but it can
scale quite well with multiple clients. There can be many OSTs,
but it isn't clear whether you are IO bound. It probably wouldn't
hurt to have a few to give you a high IOPS rate.
Note that increasing OST count also by default allows clients to
cache more dirty data (32MB/OST). You can change this manually,
it is by default tuned for very large clusters (000's of nodes).
for C in /proc/fs/lustre/osc/*/max_dirty_mb
echo 256 > $C
done
Similarly, in 1.6.5/1.8.0 it will be possible to do:
lctl set_param osc.*.max_dirty_mb=256
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
</pre>
</blockquote>
<br>
</body>
</html>