Re: [Gluster-users] Question regarding write performance issues
First - thanks for taking the time and providing the reply. Due to a bad flu I was unable to verify till now but now saw we use fstream in our apps, to write the files. Assumed the buffer was large, but never tested it. We have increased the fstream buffer to 100MB and will check if this helps (this specific test can only be scheduled for later as the cluster is busy). A related question: I was wondering if there is any magic number as to number of files per directory in Gluster volumes. Some of my directories contain an order of 10^5 files and I'm begininng to suspect this too (when I worked in local FS I didn't see a noticable degradation, though). Thanks again! Ayelet On Thu, Jan 17, 2013 at 5:28 PM, harry mangalam harry.manga...@uci.eduwrote: Just a guess, but how are the writes being done? If they're being written in zillions of tiny writes, then what you may be seeing is described here: http://moo.nac.uci.edu/~hjm/bduc/BDUC_USER_HOWTO.html#writeperfongl and the following stanza on named pipes. This is often the case with the large files being used in NGS/HTS where the fasta/fastq files are composed of millions of short (60-100 char) lines of characters and are typically written line-by-line. hjm On Wednesday, January 16, 2013 02:47:37 PM Ayelet Shemesh wrote: Hi to all Gluster experts, I have a cluster of 10 machines exposing a volume into which 12 other machines do many writes of large files (~100-300MB each). In general I'm very happy with gluster. It's a great solution, and is quite stable (thanks for the great work!). However, I have a problem which I was unable to solve yet, nor find any solution to in the documentation or on this list archive. When the client machines write locally, and then just copy the files they created to the gluster mount - everything works great. When the client machines write directly to the gluster mounted volume I get a huge performance hit. In one specific test case the difference was 20 minutes for the copy and 8 hours for the direct write. I tried to set the iocache attributes of write-behind-window and flush-behind, but to no avail. I will very much appreciate your help in solving this problem. Thanks, Ayelet ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Question regarding write performance issues
Just a guess, but how are the writes being done? If they're being written in zillions of tiny writes, then what you may be seeing is described here: http://moo.nac.uci.edu/~hjm/bduc/BDUC_USER_HOWTO.html#writeperfongl and the following stanza on named pipes. This is often the case with the large files being used in NGS/HTS where the fasta/fastq files are composed of millions of short (60-100 char) lines of characters and are typically written line-by-line. hjm On Wednesday, January 16, 2013 02:47:37 PM Ayelet Shemesh wrote: Hi to all Gluster experts, I have a cluster of 10 machines exposing a volume into which 12 other machines do many writes of large files (~100-300MB each). In general I'm very happy with gluster. It's a great solution, and is quite stable (thanks for the great work!). However, I have a problem which I was unable to solve yet, nor find any solution to in the documentation or on this list archive. When the client machines write locally, and then just copy the files they created to the gluster mount - everything works great. When the client machines write directly to the gluster mounted volume I get a huge performance hit. In one specific test case the difference was 20 minutes for the copy and 8 hours for the direct write. I tried to set the iocache attributes of write-behind-window and flush-behind, but to no avail. I will very much appreciate your help in solving this problem. Thanks, Ayelet --- Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine [m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487 415 South Circle View Dr, Irvine, CA, 92697 [shipping] MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps) --- Something must be done. [X] is something. Therefore, we must do it. Bruce Schneier, on American response to just about anything. ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
