Very bad performance on disk with a lot of files and directories

[Robert Gezelter]

Rene,

Re Volker's comment. Do a DIRECTORY/FILE_ID on some of these directories and see if his observation is correct.

One of the more general limitations of caches (at all levels) is that they dramatically increase performance in many BUT NOT ALL (emphasis mine) cases. In particular, caches are very effective at improving sequential operations, in either direction.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Rene,

in case you are still interested, LDdriver and info are to be found at
http://www.digiater.nl/lddriver

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

In the monitor statistics I see that there are 5 drives working harder than the ICR drive. These statistics don't prove much.

If I do the same dir on a disk on a GS160 with 91K files, it takes about 5 minutes (2000 blocks header cache) and cache hit rate is 10% too. So for 4M this wouild be about 200 min or more than 3 hours.

Wim

[Hein van den Heuvel]

Volker> "Now I wonder, how DFU would be able to change this ?!"

DFU can only solve one problem Rene mentions:
" gave the following command:
directory icr$disk:[000000...] /size=all/gra"

It solves that by reading INDEXF.SYS in large chunks.

It can not solve the backup problem.

Hein.

[Wim Van den Wyngaert]

One thing : on my GS160 the cpu tick rate (% cpu used for file operations) is 3.6% for 340 reads per sec. In your case it's 85% for 180 IOs.

Wim

[Volker Halle]

Wim,

this high CPU tick rate seems to indicate, that maybe even the CPU has become the bottleneck ! There is also a quite substantial Window Turn rate (about 12/sec).

If we assume nothing else was going on on the ICR disk, a file system read rate of 180 and an IO rate of 176 on that disk seem to match pretty well.

Volker.

[Wim Van den Wyngaert]

Volker,

And where are the about 2000 IO's to the other disks ? Solved by xfc ?

Wim

[Volker Halle]

Wim,

MONI FCP only shows IOs issued by the File System (XQP). All the other IOs on all the other disks will be application IOs not involving the XQP.

Volker.

[Rene Heeres]

Thank you all for your replies.

I have tried to put all the information you have asked for in the attached textfile.

Both disks are on the same system. They are howeven on 2 different HSG's

We initially initialized this disk in a way that it could accomodate a whole lot of files.

init/nohigh /block=/headers=/maximum_files=

The degree of changes on this disk is not very great, about 2000-3000 files are added monthly.

I don't think LD would help, when using LD, I have to make a full backup of the whole every day, this also takes a lot of time (size=300GB). We also thought about making a physical backup of this disk, but that has the same drawbacks.

I however am willing to try both options.

When I look at the File-ID's, they seem quite sequential.

It is true that DFU is much faster in reading the directories, that is because DFU accesses the directories in a intelligenter way. This doesn't my solve my backup problem, which was the reason I started this thread.

I am still a bith lost in solving this problem. Is there any solution to this problem. Could ODS-5 be an option.

I also have the option to migrate this disk to an EVA5000 storage system. It is nog a problem to do this, but I would like to be sure that things will get better doing that.

[Jan van den Ende]

Rene,

Backup 300Gb in one (or some small numer) of files (and LD containers ARE just 1 file) should be done at about the max speed of your driev (tape or disk - the slower is determining).
That should beat the MANY,MANY, directory and header Lookups by a considerable factor!

hth

Proost.

Have one on me.

jpe