ADSM-L

Re: Performance problems with large number of files

1999-05-11 10:00:19
Subject: Re: Performance problems with large number of files
From: "Allen S. Rout" <asr AT NERSP.NERDC.UFL DOT EDU>
Date: Tue, 11 May 1999 10:00:19 -0400
=> On Mon, 10 May 1999 16:43:02 -0400, Chuck Mattern <Chuck_Mattern AT 
HOMEDEPOT DOT COM> said:

> I have an AIX server (ADSM client) that has some large filesystems (~80
> gigs) and a large number of files (~3 million).  [ ... ]  Has anyone dealt
> with a situation like this in the past (hopefully with success)?

We have had similar problems with a client which posessed several filesystems
with directories of the form

/some/path/[00-99]/[00-99]/[00-99]/some-file.foo

yeilding over 1,010,100 directories per FS. :)

We never got backups of the whole filesystem to function in reasonable times.

You don't say much about the directory structure that holds these files; this
could be a major issue.  We had, at one time, to deal with a directory so full
of files that it required about 45 minutes just to get a ls; understandably,
backup times for that filesystem were slow.  Watch for log directories that
your applications people have forgotten to clean up.


My suggestions include:

virtual mount points, to chop up the size of the database that must be
consulted and updated as you do your incremental

Carefully considering your filesystem structure, and weighing the application
configuration vs. the applications' backup needs.

  An AIX-specific note here: it's easily possible to model whatever heirarchy
  you want, with a larger number of smaller filesystems.  Say, for instance,
  your application is Usenet News (unlikely to be critical, and certainly not
  needing backup, but it's something many might be familiar with)

  You might have a filesystem /spool, with structure like

  /spool/sci/...
  /spool/comp/...
  /spool/alt/...
  [ ... ]

  At the cost of keeping an eye on the relative sizes of the filesystems, you
  can build a separate filesystem for the /alt directory, and back it up
  separately.

  This lets you get smaller FS granularity without modifying application
  configuration.

  If your application doesn't do much moving of data from one place in it's
  storage to another, and if various areas of disk don't expand and contract a
  lot, it could be a solution.

If your business has a week/week-end schedule, try incrementals by date during
the week, and full incremental on friday night; this of course doesn't solve
your long-incremental problem, but it could dodge it.


Allen S. Rout
<Prev in Thread] Current Thread [Next in Thread>