Remember that when a user page gets written to a PAGE volume it stays there until the user logs off. When your page rate was high lots of user pages got written to PAGE volumes - thus the high page counts from Q ALLO C PAGE. Your page rate dropping low would not reduce the Q ALLOC PAGE counts. If your page rate later increased again it would not neccessaril y mean the Q ALLOC PAGE counts would go up even more - it may just mean you're paging user pages that are already on a PAGE volume. Once a page
is in PAGE space, accessing it frequently doesn't make it take up more space on your PAGE volumes. To re-phrase what was said regarding MDC, your page rate may have been high if too much central storage was in use by MDC. It's all a balance between how much central storage your logged on users require and how muc h central storage is available to CP to hold those user pages at any particular moment. Even with low page rates you may eventually write most user pages to PAGE volumes depending on the particulars of when the variouls users are activ e & dormant over long periods of time. So you do need enough PAGE spac e to handle the long term demand for PAGE space, but the amount of PAGE space is not related to the rate at which you access it. It is related to the sum of your users virtual memory sizes, the amount of storage available t o CP, and partly on the activity patterns of the userids. Brian Nielsen On Mon, 11 Sep 2006 13:20:15 -0000, Dusha, Cecelia Ms. WHS/ITMD <[EMAIL PROTECTED]> wrote: >Are you saying the MDC READS - 142/SEC could be driving the page space used >to 55%? The paging rate itself is 1/SEC... We added 2 paging volumes t o >ensure the system does not run out of paging space. > >Our production system is a guest system under z/VM 5.1. I don't know if >this would matter in the explanation as to why the system had a 55% pagi ng >space utilization... > >ind >AVGPROC-024% 01 >MDC READS-000119/SEC WRITES-000002/SEC HIT RATIO-089% >STORAGE-047% PAGING-0001/SEC STEAL-000% >Q0-00001(00000) DORMANT-00120 >Q1-00000(00000) E1-00000(00000) >Q2-00000(00000) EXPAN-001 E2-00000(00000) >Q3-00001(00000) EXPAN-001 E3-00000(00000) >PROC 0000-024% >LIMITED-00000 >Ready; T=0.01/0.01 09:14:53 > >q alloc page > EXTENT EXTENT TOTAL PAGES HIGH % >VOLID RDEV START END PAGES IN USE PAGE USED >------ ---- ---------- ---------- ------ ------ ------ ---- >510PAG F005 1 3338 600840 333053 443499 55% >PAG002 F008 1 3337 600660 0 0 0% >PAG003 F00A 1 3337 600660 0 0 0% > ------ ------ ---- >SUMMARY 1760K 333053 18% >USABLE 1760K 333053 18% >Ready; T=0.01/0.01 09:15:12 > >Thank you. > >Cecelia Dusha >-----Original Message----- >From: Jim Bohnsack [mailto:[EMAIL PROTECTED] >Sent: Monday, September 11, 2006 9:01 AM >To: IBMVM@LISTSERV.UARK.EDU >Subject: Re: z/VM 5.1 Paging > >Paging rate and page occupancy are not directly related. Do you have an >earlier number for page occupancy? 55% utilization may just be what is >required in a normal, steady state. >Jim > >At 07:57 AM 9/11/2006, you wrote: >>Our production system was migrated from z/VM 3.1 to z/VM 5.1 over the >>weekend. >> >>The paging rate was high this morning on the production system as the >>VM:Backup backups were running. (It was paging over 2000 pages per >second.) >>When I did a Q ALLOC PAGE, it indicated the percentage used was 55%. >> >>Presently (the backups have completed): >>ind >>AVGPROC-015% 01 >>MDC READS-000142/SEC WRITES-000003/SEC HIT RATIO-093% >>STORAGE-000% PAGING-0001/SEC STEAL-000% >>Q0-00001(00000) DORMANT-00077 >>Q1-00001(00000) E1-00000(00000) >>Q2-00000(00000) EXPAN-001 E2-00000(00000) >>Q3-00000(00000) EXPAN-001 E3-00000(00000) >>PROC 0000-015% >>LIMITED-00000 >>Ready; T=0.01/0.01 07:42:42 >> >>q alloc page >> EXTENT EXTENT TOTAL PAGES HIGH % >>VOLID RDEV START END PAGES IN USE PAGE USED >>------ ---- ---------- ---------- ------ ------ ------ ---- >>510PAG F005 1 3338 600840 334304 443511 55% >> ------ ------ ---- >>SUMMARY 600840 334304 55% >>USABLE 600840 334304 55% >>Ready; T=0.01/0.01 07:43:04 >> >>Being the system utilization is still low, I am a bit apprehensive as t o >>what will occur when the system gets busy through the day... Shouldn't the >>Q ALLOC PAGE percentage used have dropped? >> >>Thank you. >> >>Cecelia Dusha > >Jim Bohnsack >Cornell Univ. >(607) 255-1760 >======================== ========================= ========================
