<HTML><BODY><BR>
    <BR>
    Harry,<BR>
<BR>
  Just a question but what file system are you using under the gluster system?  You may need to tune that before you continue to try and tune the output system.   I found that by tuning using the xfs file system and tuning it for very large files I was able to improve my performance quite a bit.  In this case though I was working with a lot of big files so my tuning would not help you..but just wanted to make sure you had looked at this detail in your setup.<BR>
<BR>
Bryan<BR>
<BR>
-----Original Message-----<BR>
From: <a href="mailto:gluster-users-bounces@gluster.org">gluster-users-bounces@gluster.org</a> [mailto:gluster-users-bounces@gluster.org] On Behalf Of Harry Mangalam <BR>
Sent: Wednesday, July 25, 2012 8:02 PM<BR>
To: gluster-users<BR>
Subject: [Gluster-users] kernel parameters for improving gluster writes on millions of small writes (long)<BR>
<BR>
This is a continuation of my previous posts about improving write perf<BR>
when trapping millions of small writes to a gluster filesystem.<BR>
I was able to improve write perf by ~30x by running STDOUT thru gzip<BR>
to consolidate and reduce the output stream.<BR>
<BR>
Today, another similar problem, having to do with yet another<BR>
bioinformatics program (which these days typically handle the 'short<BR>
reads' that come out of the majority of sequencing hardware, each read<BR>
being 30-150 characters, with some metadata typically in an ASCII file<BR>
containing millions of such entries).  Reading them doesn't seem to be<BR>
a problem (at least on our systems) but writing them is quite awful..<BR>
<BR>
The program is called 'art_illumina' from the Broad Inst's 'ALLPATHS'<BR>
suite and it generates an artificial Illumina data set from an input<BR>
genome.  In this case about 5GB of the type of data described above.<BR>
Like before, the gluster process goes to &gt;100% and the program itself<BR>
slows to ~20-30% of a CPU.  In this case, the app's output cannot be<BR>
extrnally trapped by redirecting thru gzip since the output flag<BR>
specifies the base filename for 2 files that are created internally<BR>
and then written directly.  This prevents even setting up a named pipe<BR>
to trap and process the output.<BR>
<BR>
Since this gluster storage was set up specifically for bioinformatics,<BR>
this is a repeating problem and while some of the issues can be dealt<BR>
with by trapping and converting output, it would be VERY NICE if we<BR>
could deal with it at the OS level.<BR>
<BR>
The gluster volume is running over IPoIB on QDR IB and looks like this:<BR>
Volume Name: gl<BR>
Type: Distribute<BR>
Volume ID: 21f480f7-fc5a-4fd8-a084-3964634a9332<BR>
Status: Started<BR>
Number of Bricks: 8<BR>
Transport-type: tcp,rdma<BR>
Bricks:<BR>
Brick1: bs2:/raid1<BR>
Brick2: bs2:/raid2<BR>
Brick3: bs3:/raid1<BR>
Brick4: bs3:/raid2<BR>
Brick5: bs4:/raid1<BR>
Brick6: bs4:/raid2<BR>
Brick7: bs1:/raid1<BR>
Brick8: bs1:/raid2<BR>
Options Reconfigured:<BR>
performance.write-behind-window-size: 1024MB<BR>
performance.flush-behind: on<BR>
performance.cache-size: 268435456<BR>
nfs.disable: on<BR>
performance.io-cache: on<BR>
performance.quick-read: on<BR>
performance.io-thread-count: 64<BR>
auth.allow: 10.2.*.*,10.1.*.*<BR>
<BR>
I've tried to increase every caching option that might improve this<BR>
kind of performance, but it doesn't seem to help.  At this point, I'm<BR>
wondering whether changing the client (or server) kernel parameters<BR>
will help.<BR>
<BR>
The client's meminfo is:<BR>
 cat  /proc/meminfo<BR>
MemTotal:       529425924 kB<BR>
MemFree:        241833188 kB<BR>
Buffers:          355248 kB<BR>
Cached:         279699444 kB<BR>
SwapCached:            0 kB<BR>
Active:          2241580 kB<BR>
Inactive:       278287248 kB<BR>
Active(anon):     190988 kB<BR>
Inactive(anon):   287952 kB<BR>
Active(file):    2050592 kB<BR>
Inactive(file): 277999296 kB<BR>
Unevictable:       16856 kB<BR>
Mlocked:           16856 kB<BR>
SwapTotal:      563198732 kB<BR>
SwapFree:       563198732 kB<BR>
Dirty:              1656 kB<BR>
Writeback:             0 kB<BR>
AnonPages:        486876 kB<BR>
Mapped:            19808 kB<BR>
Shmem:               164 kB<BR>
Slab:            1475476 kB<BR>
SReclaimable:    1205944 kB<BR>
SUnreclaim:       269532 kB<BR>
KernelStack:        5928 kB<BR>
PageTables:        27312 kB<BR>
NFS_Unstable:          0 kB<BR>
Bounce:                0 kB<BR>
WritebackTmp:          0 kB<BR>
CommitLimit:    827911692 kB<BR>
Committed_AS:     536852 kB<BR>
VmallocTotal:   34359738367 kB<BR>
VmallocUsed:     1227732 kB<BR>
VmallocChunk:   33888774404 kB<BR>
HardwareCorrupted:     0 kB<BR>
AnonHugePages:    376832 kB<BR>
HugePages_Total:       0<BR>
HugePages_Free:        0<BR>
HugePages_Rsvd:        0<BR>
HugePages_Surp:        0<BR>
Hugepagesize:       2048 kB<BR>
DirectMap4k:      201088 kB<BR>
DirectMap2M:    15509504 kB<BR>
DirectMap1G:    521142272 kB<BR>
<BR>
and the server's meminfo is:<BR>
<BR>
$ cat  /proc/meminfo<BR>
MemTotal:       32861400 kB<BR>
MemFree:         1232172 kB<BR>
Buffers:           29116 kB<BR>
Cached:         30017272 kB<BR>
SwapCached:           44 kB<BR>
Active:         18840852 kB<BR>
Inactive:       11772428 kB<BR>
Active(anon):     492928 kB<BR>
Inactive(anon):    75264 kB<BR>
Active(file):   18347924 kB<BR>
Inactive(file): 11697164 kB<BR>
Unevictable:           0 kB<BR>
Mlocked:               0 kB<BR>
SwapTotal:      16382900 kB<BR>
SwapFree:       16382680 kB<BR>
Dirty:                 8 kB<BR>
Writeback:             0 kB<BR>
AnonPages:        566876 kB<BR>
Mapped:            14212 kB<BR>
Shmem:              1276 kB<BR>
Slab:             429164 kB<BR>
SReclaimable:     324752 kB<BR>
SUnreclaim:       104412 kB<BR>
KernelStack:        3528 kB<BR>
PageTables:        16956 kB<BR>
NFS_Unstable:          0 kB<BR>
Bounce:                0 kB<BR>
WritebackTmp:          0 kB<BR>
CommitLimit:    32813600 kB<BR>
Committed_AS:    3053096 kB<BR>
VmallocTotal:   34359738367 kB<BR>
VmallocUsed:      340196 kB<BR>
VmallocChunk:   34342345980 kB<BR>
HardwareCorrupted:     0 kB<BR>
AnonHugePages:    200704 kB<BR>
HugePages_Total:       0<BR>
HugePages_Free:        0<BR>
HugePages_Rsvd:        0<BR>
HugePages_Surp:        0<BR>
Hugepagesize:       2048 kB<BR>
DirectMap4k:        6656 kB<BR>
DirectMap2M:     2072576 kB<BR>
DirectMap1G:    31457280 kB<BR>
<BR>
Does this suggest any approach?  Is there a doc that suggests optimal<BR>
kernel parameters for gluster?<BR>
<BR>
I guess the only other option is to use the glusterfs as an NFS mount<BR>
and use the NFS client's caching..?  That will help on a single<BR>
process but decrease the overall cluster bandwidth considerably.<BR>
<BR>
-- <BR>
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<BR>
[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487<BR>
415 South Circle View Dr, Irvine, CA, 92697 [shipping]<BR>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<BR>
_______________________________________________<BR>
Gluster-users mailing list<BR>
<a href="mailto:Gluster-users@gluster.org">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>

    <br>
<br>
<font size="1">
NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose.  Any improper use or distribution is prohibited.  If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information.  Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service.
</font>
</BODY></HTML>