home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sgi / 13286 < prev    next >
Encoding:
Text File  |  1992-09-04  |  2.4 KB  |  52 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: System Slowdown
  5. Message-ID: <pe7bup4@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <Bu22Jz.D3I@knot.ccs.queensu.ca>
  8. Date: Fri, 4 Sep 1992 14:36:44 GMT
  9. Lines: 41
  10.  
  11. In article <Bu22Jz.D3I@knot.ccs.queensu.ca>, tarun@psyclops.psyc.queensu.ca (Tarun Kripalani) writes:
  12. > I am experiencing a slowdown in our Iris (310GTX) whenever
  13. > we have more than a certain number of files in a directory.
  14. > As soon as I am in a directory that has about 2000 files and 
  15. > I do a mv, cp, ls etc. it takes ages to perform. Everything 
  16. > I do then is slowed down including any other user's processes.
  17. > Why is this happening? What can I do to fix this problem?
  18.  
  19.  
  20. There is some tuning that can be done to help, but it is fundamentally
  21. wrong to put thousands of files in one directory.
  22.  
  23. Consider it from the computer's point of view.  In such a bloated
  24. directory, every time you tell the system to do anything with a file
  25. name, the system must consider all of the other file names.  If you
  26. create a new name, the system must check that the name is not the same
  27. as any other name, and so must examine every one of the other names.
  28. If you open an existing name, the system must search for that name, and
  29. on average examine half of the other names.  When you use `ls`, it must
  30. sort all of the names.
  31.  
  32. A particularly bad requirement is that the system must in principle
  33. examine the disk for each and every name.  In a directory with a few
  34. names, the system can buffer all of the necessary disk information in
  35. main memory and avoid disk operations on second or subsequent
  36. requests.  If you have an eggregiously large file directory, the
  37. system's buffers will not be big enough.  The system will fill the
  38. buffers from the disk with the first hundreds or thousands of names
  39. (and inodes if you use `ls -F`) as it starts working on your request.
  40. Then if necessary, it will read more information from the disk, into
  41. those same buffers.  If you do a second operation, it will have to
  42. re-read everything from the disk from the beginning.  On the other
  43. hand, if your directory is small enough, it would all fit in the
  44. buffers, and second commands would not pay the 1000X or 10000X time
  45. penalty of having to read the disk.
  46.  
  47. The best solution is to use hierarchies.  Spread your files into
  48. sub-directories.
  49.  
  50.  
  51. Vernon Schryver,  vjs@sgi.com
  52.