Hello, i have the following Problemdescription. I work on an AMD 2000+ with 2*160GB-Disks The Diskperformance tested with bonnie or great filewrites/reads with dd from /dev/zero or /dev/urandom gaves me an Value from 40-55 MBytes/s. Now i have 2 Directories with ~500.000-600.000 files with an size of ~5kByte. by copying the files from one disk to another or an direktory on the same disk (equal behavior), i can see this behavior: on an PIII 866 the first ~100.000 - 150.000 files on an AMDK6II450 the first ~100.000 - 120.000 files on the AMD2000+ the first ~200.000 - 220.000 files are copied with an relative good performance. After this count of files are copied, the system-load get higher, cppustate ist 0,0% idle and the system uses ~80-90%cpu-load, rest goin to intr and user.... As base i use RELENG_4. Can anyone explain me from where this behavior can come? Come thie eventually from the filesytem, or from my disks, so that these are to hot? (I think not) I have tried out following commands to copy: tar -cf - . | ( cd <destdir>; tar -xf .) #the fastest and my lovely :-) find ./ -type f |cpio -pm <destdir> # half-performace as tar rsync -av <sourcedir>/ <destdir>/ # smarter then tar but bad performace mv or any other are not testet while i surely run in to the "too many Arguments" Problem.... thank you for your suggestions regards michael
Sorry not my day, i have forgotten to tell you that not only the system load get higher, also the transferrate run under 500kBytes/s from one to another moment. The first files get copied with 3-9 MBytes/s. Thank you. Michael 2005/5/10, Michael Schuh <michael.schuh@gmail.com>:> Hello, > > i have the following Problemdescription. > I work on an AMD 2000+ with 2*160GB-Disks > The Diskperformance tested with bonnie or great filewrites/reads with dd > from /dev/zero or /dev/urandom gaves me an Value from 40-55 MBytes/s. > > Now i have 2 Directories with ~500.000-600.000 files with an size of ~5kByte. > by copying the files from one disk to another or an direktory on the same disk > (equal behavior), i can see this behavior: > > on an PIII 866 the first ~100.000 - 150.000 files > on an AMDK6II450 the first ~100.000 - 120.000 files > on the AMD2000+ the first ~200.000 - 220.000 files > are copied with an relative good performance. > > After this count of files are copied, the system-load get higher, > cppustate ist 0,0% idle and the system uses ~80-90%cpu-load, > rest goin to intr and user.... > > As base i use RELENG_4. > > Can anyone explain me from where this behavior can come? > Come thie eventually from the filesytem, or from my disks, so that > these are to hot? (I think not) > > I have tried out following commands to copy: > tar -cf - . | ( cd <destdir>; tar -xf .) #the fastest and my lovely :-) > find ./ -type f |cpio -pm <destdir> # half-performace as tar > rsync -av <sourcedir>/ <destdir>/ # smarter then tar but bad performace > > mv or any other are not testet while i surely run in to the "too many > Arguments" Problem.... > > thank you for your suggestions > > regards > > michael >
On May 10, 2005, at 6:46 AM, Michael Schuh wrote:> Now i have 2 Directories with ~500.000-600.000 files with an size of > ~5kByte. > by copying the files from one disk to another or an direktory on the > same disk > (equal behavior), i can see this behavior: > [ ... ] > Can anyone explain me from where this behavior can come? > Come thie eventually from the filesytem, or from my disks, so that > these are to hot? (I think not)Directories are kept as lists. Adding files to the end of a list takes a longer time, as the list gets bigger. There is a kernel option called DIRHASH (UFS_DIRHASH?) which can be enabled which will help this kind of situation out significantly, but even with it, you aren't going to get great performance when you put a half-million files into a single directory. Try breaking this content up into one or two levels of subdirectories. See the way the Squid cache works... -- -Chuck
At 06:46 AM 10/05/2005, Michael Schuh wrote:>Now i have 2 Directories with ~500.000-600.000 files with an size of ~5kByte. >by copying the files from one disk to another or an direktory on the same disk >(equal behavior), i can see this behavior:What value do you have for vfs.ufs.dirhash_maxmem ? Perhaps you are running into this limit ? ---Mike
Michael Schuh schrieb:> I have tried out following commands to copy: > tar -cf - . | ( cd <destdir>; tar -xf .) #the fastest and my lovely :-) > find ./ -type f |cpio -pm <destdir> # half-performace as tar > rsync -av <sourcedir>/ <destdir>/ # smarter then tar but bad performace > > mv or any other are not testet while i surely run in to the "too many > Arguments" Problem....Can you try with pax? (pax -rw ...) That doesn't involve pushing the stuff thru a pipe like with tar. The cpio version is similar but it probably can be sped up a bit if you run the find once before, or feed find into a file and redirect input to cpio from that file (so that it doesn't have to seek all the time.) mkb.