Good points Kees. The original question didn't indicate a paging "problem", just an increase in page DS use and demand paging. So yes, tuning the paging subsystem is certainly a valid approach. I was speaking mainly from a DFSORT perspective on ways to minimize paging. Usually a small amount of demand paging isn't a problem, but then again it depends on what workload is doing it.
IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> wrote on 01/15/2010 03:47:26 AM: > > Dave, > > I would have expected you to also mention a different approach: check > the paging configuration. > > During the years I have become quite confident about the intelligence > DFSORT has developped to use the available system resources, without > causing problems in the system. One of the presumptions is the > installation has a adequate paging configuration. We had a similar > situation lately where we had paging performance problemns during DFSORT > jobs. We have ample storage and the large DFSORT jobs decided to take a > couple of GB central storage for its sort. This caused a large page out > activity (like you described above) with I/O problems. > > After investigating the situation, the conclusion could only be that > either DFSORT miscalculated the amount of available storage *or* the > paging subsystem was not able to handle a substantial page-out load. We > looked at our paging configuration and the spreading of the volumes over > the internal ESS ranks and concluded that it contained several hotspots. > We reconfigured the paging volumes and never saw the problem again. > > Everybody has read many years ago the recommandation for his/her paging > configuration to spread it over as many volumes, channels and control > units as possible, said "yes, of course", and continued with other > things. A under-optimal paging configuration works well most of the time > except in special situations like large dumps and yes, large DFSORTs. > > I think that also in Rez's case, both sides of the problem should be > examined and if the paging configuration is insufficient *and* he is not > able to correct this, the other option is to limit DFSORT's use of > storage. > > Kees. > ********************************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ********************************************************************** > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
