At WAVV 2006, users had an interesting discussion about z/VSE’s ability to run either as a virtual or a real storage system. The consensus was z/VSE running real should out perform z/VSE running as a virtual storage system, since it should consume fewer CPU and I/O resources. I say “consensus” because no one seemed to be running z/VSE as a real memory system, and therefore, no one had quantified any advantages or disadvantages.
So, with time on hand and a dedicated z/VSE, let’s explore the issue. A word of caution: Since we’ll be testing a single user system on a relatively inactive system with plenty of memory and CPU cycles, our findings may result in smaller improvements than in a true production environment.
Test Setup and Procedures
As a test bed, let’s use the z/VSE 3.1 base as the installed system. The VSIZE on the base system is 264MB, so we’ll use that as real size for all testing for both the virtual and real systems. So, if you’re running with as much real as virtual, is there any advantage to running real?
The base setup of the virtual system for testing was just install and run the test, since z/VSE is delivered as a virtual storage system.
The alterations steps for the real storage system are easy:
- Go into the Interactive User Interface (IUI) fast path 243 “TAILOR IPL PROCEDURE.”
- Select the IPL procedure that will be changed and enter a 1 on “Supervisor Modify console, supervisor- and storage option.”
- Change PAGE DATA SET.....2 Do you want to use a page data set? 1=yes, 2=no.
- Blank out VSIZE.... .. ____ Virtual address space; in M or G.
- Then PF5 Process until saved and submitted.
Make sure you have available to the system at least as much real storage as was specified for VSIZE before IPLing the changed procedure. Once the system is IPLed, it’s running as a real storage system; in other words, no Page Data Set, no pageins or pageouts, and no page waits.
Whether the system is running as real or virtual is transparent to the users and operations staff. Should operations initiate too many dynamic partitions and exhaust storage, the same message is produced on the console: “1Q3FI DYNAMIC CLASS(ES) SUSPENDED - NO ALLOCATION SPACE.” Displays of resources on the console also look the same except at IPL. The first IPL message will say NOPDS instead of VSIZE=264M and there will no Page Data Set allocation messages. For example:
BG 0000 $$A$SUPX,VSIZE=264M,VIO=512K,VPOOL=64K,LOG BG 0000 $$A$SUPX,NOPDS,VIO=512K,VPOOL=64K,LOG
Running z/VSE with real storage vs. virtual storage does in fact improve performance; even in a single-user, test-only system we see measurable results. For a production environment, where some resources (i.e., disk I/O, memory and CPU) are constrained and certainly used more often, the improvements should be greater. But even if they aren’t, when was the last time you changed two parameters, re-IPLed, and gained up to a 4 percent performance improvement using the same resources?
If z/VSE was running virtual with less real than virtual, you should experience a greater performance improvement, depending on how much paging is actually being done.
In all cases, you gain the Page Data Set disk area for production files and reduce Disk I/O—that has to be worth something!
CICS start-up times improved from 17.34 to 16.67 seconds (about 4 percent). Overall system start-up, including POWER, VTAM, CICS, TCP/IP, VSE Connectors, FAQS and BIMEdit, improved from 55.4 to 54.3 seconds (about 2 percent).
The improvements appear to be due to fewer operating system instructions being executed. The instruction count for full start-up was reduced by 15 million instructions, a less than 2 percent overall reduction.
If you have enough real memory on your processor, then running real appears to have no downside except improved performance.
Thanks for reading the column; see you all in the next issue.