![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: System1: Production, OpenVMS 6.2, Alpha 2100 Model A500MP, 2 CPUs, 768 MB Memory, RAID5 w/ parity - not mirrored System2: Development, OpenVMS 6.2, Alpha 2100 Model 5/250, 1 CPU, 512 MB Memory, Not RAID - normal disk Our customer runs our application on both of these machines (Saturday night in batch with priority 4) but it finishes much faster on System2 than System1 (4 minutes vs. 14 hours) System1 (Production): Charged CPU time: 01:25:26.81 Elapsed time: 14:42:35.11 Direct I/O count: 8175366 Page faults: 1260 Peak page file size: 57616 Buffered I/O count: 10712 System2 (Development): Charged CPU time: 00:04:06.94 Elapsed time: 00:06:16.91 Direct I/O count: 14677 Page faults: 1197 Peak page file size: 79504 Buffered I/O count: 11141 A Wizard could possibly explain this! Any ideas? The faster I can get an answer to the customer the better our customer support would look! Thank you very kindly, Barry Ramin The Answer is : This could be anything from fragmented disks to fragmented RMS index file structures to working set limitations to incorrect system tuning to cache-related problems to incorrect process quotas to system or RMS or cluster locking contention, with a plethoria of other possibilities... Initially, the most likely cause would probably be far more application data on the production computer than that computer can deal with. It is tempting to answer this question by putting the blame on RAID-5 versus RAID-0. However, the DIRECT-IO count of 8 million or more versus 15 thousand suggests that the production system simply has too much work to do. Whether a (writeback cache?) RAID-5 I/O is a little slower would be moot, in other words. As there is insufficient detail on the application, the OpenVMS Wizard cannot particularly assist with specific suggestions. For example, if this is an Oracle application the OpenVMS Wizard would recommend hunting for 'full table scans'. For an RMS indexed file application, the OpenVMS Wizard would search for excessive duplicate chains. Without even an indication whether the application is a data entry style or a report/query style, there is little that can be recommended. Start with the OpenVMS performance management manual, and spend some time learning about the performance and where the extra time is going. Tools of interest could include DECamds (separately installed, likely best to install the V7.1 or V7.2 DECamds kit on V6.2), MONITOR, and various performance and coverage analysis tools. For consulting assistance to help resolve this quickly, please contact the Compaq Customer Support Center.
|