XSTORE is recommended for system paging. In 5.2.0 systems you generally need 2G or less.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Pohlen (Mailinglist) Sent: Friday, December 15, 2006 9:31 AM To: [email protected] Subject: Re: problem with an old vm/esa environment after migration to a flex-estserver Kris, I have now figured out from the IND SPACE every minute that the SQLDS user has only DASD paging between 300 and 700 pages per second in spaceid MAP0000000000. The BASE spaceid has no paging. Because Xstore is not defined there is obviously no xstore paging. Would it make sense to define Xstore? I'm not sure if a CMS user uses it. Franz Josef ----- Original Message ----- From: Kris Buelens To: Pohlen (Mailinglist) Sent: Tuesday, December 12, 2006 8:48 PM Subject: Re: problem with an old vm/esa environment after migration to a flex-estserver Here's my EXEC. Kris, IBM Belgium, VM customer support "Pohlen (Mailinglist)" <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <[email protected]> 2006-12-12 17:45 Please respond to The IBM z/VM Operating System <[email protected]> To [email protected] cc Subject Re: problem with an old vm/esa environment after migration to a flex-es tserver Hi Kris, it seems to be dasd paging, because there is also heavy i/o on one paging dasd. I have found your "data in memory techniques" document, but there is no exec for checking ind spaces only qnssmap exec is listed there. But it was a good hint. I have created a small exec which does the ind spaces user xxx every minute and writes the result with a timestamp into a file. This I will let the customer run a few hours and check the results. I will not parse the command now because I have zVM 5.2 and I'm not sure if the command output is the same on VM/ESA 2.2. If I have the results available I will contact you again. regards Franz Josef ----- Original Message ----- From: "Kris Buelens" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, December 12, 2006 3:44 PM Subject: Re: [IBMVM] problem with an old vm/esa environment after migration to a flex-es tserver Do you know if this paging is "real paging" or "Dataspace I/O": when using VM dataspace support in DB2, all DB2 I/O is done by CP paging, hence high page rates. Quite some years ago, I created a document to explain the difference. It is called "Data in memory techniques" or alike and available on the VM web page. If you search for EXECLOAD, NUCXLOAD and, BUELENS you should quickly find it back. It contains an EXEC that you can run in a server every x minutes and that then will report how many real page in/out happend and how many dataspace read/writes (based on counts reported by CP IND SPACES) If you've got RTM/ESA, its DISPLAY SYSDASD command also reports the dataspace "paging I/O" Kris, IBM Belgium, VM customer support "Pohlen (Mailinglist)" <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <[email protected]> 2006-12-12 14:54 Please respond to The IBM z/VM Operating System <[email protected]> To [email protected] cc Subject problem with an old vm/esa environment after migration to a flex-es tserver Hi listers, I have a customer with a really old VM/ESA 2.2, VSE/ESA 2.3 and SQLDS database. Now after migration to the tserver he complains about performance problems. What I have figured out that he has massive paging only on SQLDS service machine (300-500 pages/s). This I cannot understand, because first he has more memory available as before on multiprise (193 MB vs. 768 MB now) and second we haven't changed the system layout compared to the multiprise. We have migrated the system by dump/restoring the volumes with DDR. So what can cause only the sqlds machine to page so heavily? I have already doubled the virtual memory to 96 MB but this had no effect on the behaviour. Does anybody have an idea, where I can search for the problem? Mit freundlichen Grüßen / best regards Franz Josef Pohlen -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------
