Franz Josef: It would be easier to handle some of the technical details off-list. Please open an incident through the normal support structure for FLEX-ES resellers and we will be happy to pursue.
On Mon, 18 Dec 2006 21:01:51 +0100, Pohlen (Mailinglist) <[EMAIL PROTECTED]> wrote: >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 fou nd >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. Ther e I >also see the I/Os which Kris told me is no paging but the real DB i/o. I n >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 th e >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, bu t >for sure it is much more than 32MB. The machine has physically 2 GB stor age. > >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 syste m >with relative high i/o rate the processor eats too much from its capacit y >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 wron g 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 migrat ion >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 u s >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 de f >ined >>there is obviously no xstore paging. Would it make sense to define Xsto r >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 hav e > >been accomplished on the old mainframe, on a FLEX-ES system using intern a >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 long e >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 to k >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 whi c >h I >did not see an answer posted. >-- >Gary Eheman >Fundamental Software, Inc >http://www.funsoft.com >======================== ========================= ========================
