Hi all, We are running CentOS 5.2 64bit as our file server. Currently, we used GFS (with CLVM underneath it) as our filesystem (for our multiple 2TB SAN volume exports) since we plan to add more file servers (serving the same contents) later on. The issue we are facing at the moment is we found out that command such as 'ls' gives a very slow response.(e.g 3-4minutes for the outputs of ls to be printed out, or in certain cases, 20minutes or so) This is completely true especially in directories containing "large number" of small files (e.g 90000+ of 1-4kb files). The thing is, most of system users are generating these small files frequently as part of their workflow. We tried emulating the same scenario (90000+ of small files) on a ext3 partition and it gives almost the same result. I believe most of the CLVM/GFS settings done are using the defaults parameters. Additionally, we would prefer to stick to GFS (or at least ext3) as it is part of CentOS / RHEL distribution rather than changing into other small-files 'friendly' filesystems (such as XFS, ReiserFS). I'm exploring whether is there anyway we can tune the GFS parameters to make the system more responsive? I have read that we can apply 'dir_index' option to ext3 partition to speedup things, but I'm not so sure about GFS. Below are the output from "gfs_tool gettune /export/gfs" : ilimit1 = 100 ilimit1_tries = 3 ilimit1_min = 1 ilimit2 = 500 ilimit2_tries = 10 ilimit2_min = 3 demote_secs = 300 incore_log_blocks = 1024 jindex_refresh_secs = 60 depend_secs = 60 scand_secs = 5 recoverd_secs = 60 logd_secs = 1 quotad_secs = 5 inoded_secs = 15 glock_purge = 0 quota_simul_sync = 64 quota_warn_period = 10 atime_quantum = 3600 quota_quantum = 60 quota_scale = 1.0000 (1, 1) quota_enforce = 1 quota_account = 1 new_files_jdata = 0 new_files_directio = 0 max_atomic_write = 4194304 max_readahead = 262144 lockdump_size = 131072 stall_secs = 600 complain_secs = 10 reclaim_limit = 5000 entries_per_readdir = 32 prefetch_secs = 10 statfs_slots = 64 max_mhc = 10000 greedy_default = 100 greedy_quantum = 25 greedy_max = 250 rgrp_try_threshold = 100 statfs_fast = 0 TIA. .ikmal
Hi, independently from the results you have seen it might be always reasonable to tune a gfs filesystem as follows: http://kbase.redhat.com/faq/docs/DOC-6533 specially mount with noatime and gfs_tool settune <fs> glock_purge 50 Regards Marc. On Wednesday 29 April 2009 13:01:17 Hairul Ikmal Mohamad Fuzi wrote:> Hi all, > > We are running CentOS 5.2 64bit as our file server. > Currently, we used GFS (with CLVM underneath it) as our filesystem > (for our multiple 2TB SAN volume exports) since we plan to add more > file servers (serving the same contents) later on. > > The issue we are facing at the moment is we found out that command > such as 'ls' gives a very slow response.(e.g 3-4minutes for the > outputs of ls to be printed out, or in certain cases, 20minutes or so) > This is completely true especially in directories containing "large > number" of small files (e.g 90000+ of 1-4kb files). The thing is, most > of system users are generating these small files frequently as part of > their workflow. > > We tried emulating the same scenario (90000+ of small files) on a ext3 > partition and it gives almost the same result. > > I believe most of the CLVM/GFS settings done are using the defaults > parameters. Additionally, we would prefer to stick to GFS (or at least > ext3) as it is part of CentOS / RHEL distribution rather than changing > into other small-files 'friendly' filesystems (such as XFS, ReiserFS). > > I'm exploring whether is there anyway we can tune the GFS parameters > to make the system more responsive? > I have read that we can apply 'dir_index' option to ext3 partition to > speedup things, but I'm not so sure about GFS. > > Below are the output from "gfs_tool gettune /export/gfs" : > > ilimit1 = 100 > ilimit1_tries = 3 > ilimit1_min = 1 > ilimit2 = 500 > ilimit2_tries = 10 > ilimit2_min = 3 > demote_secs = 300 > incore_log_blocks = 1024 > jindex_refresh_secs = 60 > depend_secs = 60 > scand_secs = 5 > recoverd_secs = 60 > logd_secs = 1 > quotad_secs = 5 > inoded_secs = 15 > glock_purge = 0 > quota_simul_sync = 64 > quota_warn_period = 10 > atime_quantum = 3600 > quota_quantum = 60 > quota_scale = 1.0000 (1, 1) > quota_enforce = 1 > quota_account = 1 > new_files_jdata = 0 > new_files_directio = 0 > max_atomic_write = 4194304 > max_readahead = 262144 > lockdump_size = 131072 > stall_secs = 600 > complain_secs = 10 > reclaim_limit = 5000 > entries_per_readdir = 32 > prefetch_secs = 10 > statfs_slots = 64 > max_mhc = 10000 > greedy_default = 100 > greedy_quantum = 25 > greedy_max = 250 > rgrp_try_threshold = 100 > statfs_fast = 0 > > > TIA. > > .ikmal > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos-- Gruss / Regards, Marc Grimme Phone: +49-89 452 3538-14 http://www.atix.de/ http://www.open-sharedroot.org/ ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss
On Wed, 2009-04-29 at 19:01 +0800, Hairul Ikmal Mohamad Fuzi wrote:> Hi all, > > We are running CentOS 5.2 64bit as our file server. > Currently, we used GFS (with CLVM underneath it) as our filesystem > (for our multiple 2TB SAN volume exports) since we plan to add more > file servers (serving the same contents) later on. > > The issue we are facing at the moment is we found out that command > such as 'ls' gives a very slow response.(e.g 3-4minutes for the > outputs of ls to be printed out, or in certain cases, 20minutes or so) > This is completely true especially in directories containing "large > number" of small files (e.g 90000+ of 1-4kb files). The thing is, most > of system users are generating these small files frequently as part of > their workflow.One thing to keep in mind is that ls must sort the file list. If the system load is high and memory is short, you may be getting into a swap situation. I suggest trying the test when the system is lightly loaded to see if the results differ. This might be especially significant if you have a large number of concurrent users doing lots of things. As well (I believe this is not FUD), 64 bit systems use more memory inherently so memory shortage problems could be exacerbated.> <snip>You might want to check and see if swap is heavily used (if not root, /sbin/swapon -s). That might be helpful, or not.> TIA. > > .ikmal > <snip sig stuff>HTH -- Bill
On Wed, Apr 29, 2009 at 07:01:17PM +0800, Hairul Ikmal Mohamad Fuzi wrote:> > Hi all, > > We are running CentOS 5.2 64bit as our file server. > Currently, we used GFS (with CLVM underneath it) as our filesystem > (for our multiple 2TB SAN volume exports) since we plan to add more > file servers (serving the same contents) later on. > > The issue we are facing at the moment is we found out that command > such as 'ls' gives a very slow response.(e.g 3-4minutes for the > outputs of ls to be printed out, or in certain cases, 20minutes or so) > This is completely true especially in directories containing "large > number" of small files (e.g 90000+ of 1-4kb files). The thing is, most > of system users are generating these small files frequently as part of > their workflow. > > We tried emulating the same scenario (90000+ of small files) on a ext3 > partition and it gives almost the same result.This is likely related to the size of the "ls" process growing. To sort by date etc. "ls" pulls all the meta data into memory then reports.> > I believe most of the CLVM/GFS settings done are using the defaults > parameters. Additionally, we would prefer to stick to GFS (or at least > ext3) as it is part of CentOS / RHEL distribution rather than changing > into other small-files 'friendly' filesystems (such as XFS, ReiserFS). > > I'm exploring whether is there anyway we can tune the GFS parameters > to make the system more responsive?With 'gobs' of files you may find that find, xargs and stat are the tools of choice.> I have read that we can apply 'dir_index' option to ext3 partition to > speedup things, but I'm not so sure about GFS.Do look at "ls" with strace, top or a debugger. -- T o m M i t c h e l l Found me a new hat, now what?