|
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] I don't seem to have SI05599. I wonder if that would affect the inconsistencies in run time? Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin bdietz@3x.com Sent by: midrange-l-admin@midrange.com 12/06/2002 08:15 PM Please respond to midrange-l To: midrange-l@midrange.com cc: Fax to: Subject: Re: Backup performance issue. Rob you usually seem on top of things when I comes to PTF's. But have you seen these?? SI05856 510 OSP - SAV/RST Performance Enhancements SI05599 520 OSP - SAV/RST Performance Enhancements DESCRIPTION OF PROBLEM FIXED FOR APAR SE07081 : ----------------------------------------------- When saving or restoring a large number of directories, performance of SAV and RST quickly degrades. CORRECTION FOR APAR SE07081 : ----------------------------- When saving or restoring a large number of directories, performance of the SAV and RST commands is enhanced. ------------------------- Bryan Dietz 3X Corporation 614-410-9205 rob@dekko.com Sent by: midrange-l-admin@midrange.com 12/06/2002 05:16 PM Please respond to midrange-l@midrange.com To midrange-l@midrange.com cc Subject Backup performance issue. This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] I have a backup that uses the SAV command to save some Domino IFS files. It should fit in a four hour window between 8pm and 12 midnight. It uses a 3590 tape drive. Most nights it fits fine. However on occasion it takes too long and the next job that needs the tape drive aborts it. I choose the following problem question: How do I determine why the backup takes longer on one night versus others? I looked at the performance data, (iSeries nav, my connections, my400, Configuration and service, Collection services, right click on collection, Performance tools, performance data). Charts: Transaction count: I don't think it ever exceeded 500 Transaction response time: I don't think it ever exceeded 0.5sec. Total CPU utilized: I think it peaked at 10% Interactive CPU: I think it peaked at 0.37% Batch cpu: I think it peaked at 9% High disk utilization: peaked at 19% Machine pool faults: two spikes around 35, 2 around 20 and the rest below that. User pool faults: stayed under 100 Exception CPU utilization: Strange. One peak at 80. Two peaks at 70. The rest all around 0. I checked out SST tape statistics and noticed no temp read or write errors. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.