I know SQL/DS uses a magic number to tell what it should do with pages of dataspaces that are in storage: The number varies from 1 to 5. SQL/DS compares its working set with the TARGETWS set at startup. If it is higher, SQLDS will start telling CP it no longer needs some pages, depending on that these magic numbers whose name I can't remember now, nor the exact sequence. It is something like: 1= keep index and data, forever 2= keep index, remove data 3= 4= 5=remove index and data directly after LUW end
Maybe with the extra storage you have to set the TARGETWS much higher. There is indeed a problem: when DB2 sees it has too muich, it will tell CP to remove the pages it knows it just touched. So, pages that are -maybe useless- resident since much longer are not removed unless CP decides to do that. Therefore my customer does the following (since many years) - the TARGETWS is set very high, so DB2 never cleans up. CP will, and CP has en LRU mechanism that seems to work better. - as our DB2 severs have a very high ABSOLUTE share, CP might keep too many pages. So, every now and then, a service machine lowers DB2's share to REL 1, locks many of its pages to create a paging demand and almost everything of DB2 gets kicked out. Kris, IBM Belgium, VM customer support "Pohlen (Mailinglist)" <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 2006-12-18 21:01 Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: problem with an old vm/esa environment after migration to a flex-estserver Hi Gary and Ed, the answer why I have not answered the questions of Ed is simple. For whatever reason I haven't got them into my outlook. The other posts have all reached me. But following your hint I have searched the archives and found the questions. Here are the answers What release is SQL/DS? I don't know currently. The system status is from approx. 1993 - 1994 Is the SQL/DS server using VM dataspaces? There is the dataspace MAP0000000000 which I can see on IND SPACES. There I also see the I/Os which Kris told me is no paging but the real DB i/o. In fact there is currently no paging. I only didn't know that the database i/o is handled like paging and was misleaded from the high paging rate. Was their expanded storage on the old box? If so, how much? no, on the old box they had configured only 193 MB central storage on the tserver they have 768 MB Is the Tserver configured with expanded storage? If so, how much? no Did the old system have cached DASD? it was a multiprise 2000 or 2003 with 32MB cache defined Are you using enough cache for the DASD on the Tserver? I don't know how much cache is on the raid controller of the tserver, but for sure it is much more than 32MB. The machine has physically 2 GB storage. Are you paging on Unix/Linux at all on the Tserver? no Meanwhile after we have figured out that the high paging rate is DASD i/o I don't think that memory is the problem. If I substract those i/os from paging there is zero paging. Gary, now one question to you. On a real mainframe there is the separate system assist processor to do the i/o. On an intel machine the i/o has to be done by the normal processor. We have sized the machine to a nearly equivalent mips rate of the old machine. Is it possible, that on a system with relative high i/o rate the processor eats too much from its capacity for i/o handling which is then on the other hand missing for the non-i/o work? In other words, can the equavalent sizing of the mips rate be wrong on systems with high i/o AND high cpu, so that we need more mips on the tserver? regards Franz Josef ----- Original Message ----- From: "Gary Eheman" <[EMAIL PROTECTED]> To: <IBMVM@LISTSERV.UARK.EDU> Sent: Saturday, December 16, 2006 5:18 PM Subject: Re: [IBMVM] problem with an old vm/esa environment after migration to a flex-estserver On Fri, 15 Dec 2006 15:30:38 +0100, Pohlen (Mailinglist) <[EMAIL PROTECTED]> wrote: >Kris, > >I have now figured out from the IND SPACE every minute that the SQLDS us er >has only DASD paging between 300 and 700 pages per second in spaceid >MAP0000000000. The BASE spaceid has no paging. Because Xstore is not def ined >there is obviously no xstore paging. Would it make sense to define Xstor e? >I'm not sure if a CMS user uses it. > >Franz Josef > The paradigm is different on a FLEX-ES system than on a conventional IBM mainframe with respect to xstore. Whereas paging to xstore may have been faster than I/O to disk could have been accomplished on the old mainframe, on a FLEX-ES system using interna l dasd, with a cache hit we can satisfy an I/O from control unit cache in micro seconds under ideal conditions. The path length for xstore is longe r. The "Oooooh, xstore is faster" paradigm does not fit well at all in the FLEX-ES world. I do not generally recommend xstore in a VM environment, other than a tok en amount due to an idiosyncracy of the CP paging algorithms in VM that may function slightly better with a token amount available. And I never recommend MDC to xstore on a FLEX-ES system in light of the speed that I/ O can be satisfied from controller cache. Ed Zell asked some excellent and pertinent questions in his post for whic h I did not see an answer posted. -- Gary Eheman Fundamental Software, Inc http://www.funsoft.com
