home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / att / 2184 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.2 KB  |  47 lines
  1. Newsgroups: comp.sys.att
  2. Path: sparky!uunet!van-bc!tram!jeffrey
  3. From: jeffrey@squid.tram.com (Jeffrey L Bromberger)
  4. Subject: Virtual memory *NIGHTMARE* on 3B2/400
  5. Organization: Tramway Unix Systems
  6. Date: Sat, 12 Sep 1992 04:27:03 GMT
  7. Message-ID: <1992Sep12.042703.20542@squid.tram.com>
  8. Summary: Why is VM a dog here?
  9. Keywords: SVR3.1 3B2/400 thrashing
  10. Sender: jeffrey@squid.tram.com (Jeffrey L Bromberger)
  11. Lines: 34
  12.  
  13. I dare the wrath of gods, but I must once again ask about some of the
  14. shortcomings of this platform.  Before we start, SVR3.1 on a standard
  15. 3B2/400.  4Mb real memory, with 20Mb of swap space split on the two
  16. internal disks.
  17.  
  18. I am working with a program that eats memory like it's going out of
  19. style.  This program manages a huge linked list, and shuffles the
  20. pointers around quite frequently.  Right now, ther's no way around
  21. this.  My problem is in the systems' way of handling memory accesses.
  22. The machine spends most of it's time paging and thrashing about.  It
  23. seems that there is no easy way to advise the system that VM will be
  24. accessed rather randomly, and in short bits.  Would you believe that
  25. ther's about a 1 minute delay between the time I hit a character and
  26. see it on my screen?  Yes, that bad.
  27.  
  28. The problem is definately memory related, with a bit disk performance
  29. to boot.  A sar report shows 6% user time, 28% system time, 3% idle,
  30. and a whopping 73% waiting for I/O (almost certainly in the swap
  31. partitions).  This is almost unbelievable!  Talk about "sucking mud".
  32. While I realize that I cannot expect the performance of a Cray from my
  33. old /400, I did expect that one program shouldn't bring the machine
  34. down to a point where UUCP traffic is at ~50 characters per second
  35. (over a 2400 baud connection).  Is there any way to make the memory
  36. system behave better?  Would something like BSD's undocumented
  37. vadvise(2) help the situation here?  Maybe SVR3.2?  Was there any work
  38. done on the VM between 3.1 and 3.2?  Should I just resign myself and
  39. buy a Sparc machine?
  40.  
  41. Depressed, and very grateful for a 1K typeahead buffer.
  42.  
  43. j
  44. -- 
  45. Jeffrey L. Bromberger ------- System Manager ------- Tramway Unix Systems
  46. jeffrey@squid.tram.com      Anywhere!{van-bc,limbic,icus}!tram!jeffrey
  47.