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