home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / sysv386 / 13891 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.3 KB
  1. Xref: sparky comp.unix.sysv386:13891 biz.sco.general:3124
  2. Newsgroups: comp.unix.sysv386,biz.sco.general
  3. Path: sparky!uunet!usc!sdd.hp.com!uakari.primate.wisc.edu!caen!destroyer!ncar!csn!cherokee!lookout.it.uswc.uswest.com!rreitzig
  4. From: rreitzig@lookout.it.uswc.uswest.com (Rolf Reitzig)
  5. Subject: SCO ODT performance
  6. Message-ID: <1992Sep1.154529.454@advtech.uswest.com>
  7. Sender: news@advtech.uswest.com (Radio Free Boulder)
  8. Nntp-Posting-Host: lookout.it.uswc.uswest.com
  9. Organization: U S WEST Information Technologies
  10. Date: Tue, 1 Sep 1992 15:45:29 GMT
  11. Lines: 38
  12.  
  13.  
  14. I am posting a description of a problem I am experiencing with SCO ODT V1.1.
  15. Any replies are greatly appreciated.
  16.  
  17. I am running SCO ODT V1.1 on a DEC 433MP computer with 24 MB memory and 1 
  18. processor.  This is DEC's modified version of ODT, but the same problem has 
  19. occurred on true SCO ODT.
  20.  
  21. Recently, I upgraded a site from a 486 computer with IDE drives running SCO 
  22. Xenix to the aforementioned DEC/ODT system.  ALL applications are the same,
  23. so the only changes have been the computer, and OS.
  24.  
  25. After the switchover had been performed, the users (approximately 15 on dumb
  26. terminals) noticed that their response time has decreased severely.  The users
  27. are running the same applications as before, and NO X-Terminals are involved
  28. as of now.
  29.  
  30. Using sar and vmstat, the CPU usage shows > 80% idle, and no swapping or
  31. paging is occurring.  Basically, the computer says it is running fine.
  32.  
  33. After speaking to DEC technical support, I decided to try some benchmarks on
  34. disk access time.  I found the following:  copying a 25 MB file from fileA to
  35. fileB took 13 minutes on the Xenix computer, and 2.5 minutes on the DEC 
  36. computer.  Not bad.  However, vmstat reported that the CPU was 93% idle, with
  37. 7% system useage on the Xenix computer, while the DEC computer was 0% idle, with
  38. 100% system useage.  While the copying was taking place, a user could login to
  39. the Xenix computer with no delay, while a login on the DEC computer was
  40. insufferable slow.  These tests were performed with 2 root users logged in, no
  41. users on the system at all.
  42.  
  43. Basically, I have concluded that disk access operates at very high priority in
  44. ODT, and this is the cause of the performance problems.  
  45.  
  46. Am I on the right track?  Any suggestions?
  47.  
  48. Post, or mail replies to rreitzig@uswest.com
  49.  
  50. Thank you in advance.
  51.