home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / misc / 250 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.3 KB

  1. Path: sparky!uunet!olivea!sgigate!odin!fido!knobi.munich.sgi.com!knobi
  2. From: knobi@knobi.munich.sgi.com (Martin Knoblauch)
  3. Newsgroups: comp.sys.sgi.misc
  4. Subject: Re: Why is copying and/or deleting so slow on IRIX
  5. Message-ID: <1iueqiINN6kr@fido.asd.sgi.com>
  6. Date: 12 Jan 93 12:50:26 GMT
  7. References: <1993Jan12.104142.1311@wega.rz.uni-ulm.de>
  8. Organization: Silicon Graphics, Inc.
  9. Lines: 55
  10. NNTP-Posting-Host: knobi.munich.sgi.com
  11.  
  12. In article <1993Jan12.104142.1311@wega.rz.uni-ulm.de>,
  13. huober_r@hal.rz.uni-ulm.de (Reiner Huober) writes:
  14. |> We use a 4D35 with biosym software on it. This software has a
  15. |> help directory with over 3900 file, one or two blocks in size each.
  16. |> If you copy or remove such a directory, then it takes several hours.
  17. |> 
  18. |> Is this specific to IRIX or have other systems the same behaviour
  19. |> if there are many files in one directory.
  20.  
  21.   You are exceeding the disk buffer cache. It is usually not a
  22. good idea to have thousands of files in one directory. The directory
  23. gets so big, that it does not fit into the memory reserved by
  24. the kernel. As a result, each access to any single inode in this
  25. directory will directly go to disk, which is very slow. So if you
  26. want to copy a directory with 3900 files, each file a few inodes,
  27. it can take hours. All OS see this effect more or less drastic.
  28. The limit is about 1000 files for a "normal" IRIX kernel. When
  29. you exceed this limit, you will see the performance degradation
  30. that you describe. If you have 'sar', the system activity reporter,
  31. installed, you can try to monitor the system using 'sar -u' and
  32. 'sar -b'. If the former shows high percentages of %wio and %wfs,
  33. this indicates a disk buffer cache problem. If 'sar -b' also
  34. shows low utilisation of 'rcache' and 'wcache', you have another
  35. indicator.
  36.  
  37.   To improve your situation, you can try to build a new kernel with
  38. an increased disk buffer cache. To do so, log in as 'root' and
  39. cd into '/usr/sysgen/master.d'. Edit file 'kernel'. Look for a
  40. line containing '#define NBUF'. Under IRIX 4.0.x NBUF is set to
  41. 0 for autoconfiguration. Replace 0 by some large nuber like 1024
  42. (I believe the maximum is 1500). Then rebuild the kernel using the
  43. 'autoconfig' command and reboot.
  44.  
  45.   Be aware that increasing NBUF increases the permament memory
  46. usage of the kernel. If you are low on memory anyway, you will
  47. hurt your overall system performance. You might want to play with
  48. the NBUF parameter to get the best result ("acceptable" performance
  49. at lowest possible NBUF value). As a final remark, don't expect the
  50. resulting performance on your "monster" directory to be to good.
  51. It will be better, but not impressive. The best way to overcome
  52. your problem is to restructure the directory.
  53.  
  54.   Hope this helps.
  55.  
  56. Martin
  57. -- 
  58. +---------------------------------+----------------------------------+
  59. |Martin Knoblauch                 | Silicon Graphics GmbH            |
  60. |Application Support              | Am Hochacker 3 - Technopark      |
  61. |Silicon Graphics Computer Systems| W-8011 Grasbrunn-Neukeferloh, FRG|
  62. |                                 | Phone: (+int) 89 46108-179 or -0 |
  63. |                                 | Fax:   (+int) 89 46108-222       |
  64. +---------------------------------+----------------------------------+
  65. |Network: <knobi@sgi.com>         | V-Mail: 8935   | M/S: IMU-315    |
  66. +--------------------------------------------------------------------+
  67.