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
