<font><font face="verdana,sans-serif">Hi Ben,</font></font><div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">Thanks for the expert advice.<br></font></font><br><div class="gmail_quote">
On Fri, Aug 3, 2012 at 2:35 PM, Ben England <span dir="ltr"><<a href="mailto:bengland@redhat.com" target="_blank">bengland@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4. Re: kernel parameters for improving gluster writes on millions of small writes (long) (Harry Mangalam)<br>
<br>
Harry, You are correct, Glusterfs throughput with small write transfer sizes is a client-side problem, here are workarounds that at least some applications could use.<br></blockquote><div><br></div><div>Not to be impertinent nor snarky, but why is the gluster client written in this way and is that a high priority for fixing? It seems that caching/buffering is one of the great central truths of computer science in general. Is there a countering argument for not doing this?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) NFS client is one workaround, since it buffers writes using the kernel buffer cache.<br></blockquote><div><br></div><div>Yes, I tried this and I find the same thing. One thing I am unclear about tho is whether you can set up and run 1 NFS server per gluster server node. ie my glusterfs runs on 4 servers - could I connect clients to each one using a round robin selection or other load/bandwidth balancing approach? I've read opinions that seem to support both yes and no.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) If your app does not have a configurable I/O size, but it lets you write to stdout, you can try piping your output to stdout and letting dd aggregate your I/O to the filesystem for you. In this example we triple single-thread write throughput for 4-KB I/O requests in this example.</blockquote>
<div><br></div><div>I agree again - I wrote up this for the gluster 'hints' <<a href="http://goo.gl/NyMXO">http://goo.gl/NyMXO</a>> using gzip (other utilities seem to work as well, as do named pipes for handling more complex output options.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[nice examples deleted]<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) If your program is written in "C" and it uses stdio.h, you can probably do setvbuf() "C" RTL call to increase buffer size to something greater than 8 KB, which is the default in gcc-4.4.<br></blockquote>
<div><br></div><div>Most of our users are not programmers and so this is not an option in most cases. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://en.cppreference.com/w/c/io/setvbuf" target="_blank">http://en.cppreference.com/w/c/io/setvbuf</a><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://gluster.org/cgi-bin/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<br>[m/c 2225] / 92697 Google Voice Multiplexer: <a href="tel:%28949%29%20478-4487" value="+19494784487" target="_blank">(949) 478-4487</a><br>
415 South Circle View Dr, Irvine, CA, 92697 [shipping]<br>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<br><br>
</div>