- The developerWorks article "Porting applications to Linux for System z" provides more technical details, especially on the differences between 31bit and 64bit and of course the endianess problem. So before you start porting your C/C++ program take a look at this.
- Open Source packages not yet integrated in a distribution are usually pretty easy. Most of the time a simple ./configure, make, make install sequence does the job. You probably need to install a few development libraries before. Sometimes small changes to the make file are required to recognize s390x as a big-endian 64 bit architecture. Usually you can take a look at the ppc64 implementation.
- Java workloads usually run just out of the box.
- Don't forget to download and install the latest service pack though.
- Due to the 31bit addressing the heap of the 31bit JVM on System z can't be as large as the heap on a 32bit JVM. So for e.g. a 3 GB heap you need to switch to the 64 bit JVM on zLinux. If you then use the -Xcompressedrefs option you can keep the additional memory reasonable.
- For ISVs there is at IBM Partnerworld a special roadmap called "Porting your UNIX or Linux on x86 solution to Linux for IBM System z mainframe server platforms".
- Also hosted on Partnerworld is the "IBM Systems Application Advantage for Linux (Chiphopper)". Which is an offering from IBM to help porting ISV applications.
June 18, 2013
Porting to Linux on System z
The recently released overview paper "Porting applications to Linux on IBM System z" prompted a few questions about porting in principal that I'll try to answer here in this blog entry.
June 3, 2013
New white paper: HyperPAV setup with z/VM and Red Hat Linux on zSeries
Parallel Access Volume (PAV) allow you on System z to have more than one I/O outstanding per volume. However it's not so easy to set up and maintain, so this is why there is HiperPAV, which is quite easy to install and maintain. And it's supported by all in service Linux distributions now.
The new white paper / howto "HyperPAV setup with z/VM and Red Hat Linux on zSeries" describes the step by step setup for HyperPAV for z/VM and zLinux. So if you are using ECKD disks and have any I/O performance problems - make sure you've implemented this.
The new white paper / howto "HyperPAV setup with z/VM and Red Hat Linux on zSeries" describes the step by step setup for HyperPAV for z/VM and zLinux. So if you are using ECKD disks and have any I/O performance problems - make sure you've implemented this.
May 7, 2013
Linux and z/VM Live Virtual Classes 2013
There are regular Live Virtual Classes (LVC) for z/VM and Linux on System z. Watch the site to register for upcoming classes. There are also replays available for the older classes for z/VM, Linux on System z and z/VSE.
Here are the latest classes from 2013. The title links to the charts, the "replay" to the full replay.
Here are the latest classes from 2013. The title links to the charts, the "replay" to the full replay.
- zFCP Performance Analysis - replay
This class covers the details of the ziomon tool suite on zLinux to analyze FCP performance problems. This tooling is the way to go for in depth analysis of problems but it is not intended for everyday monitoring. There the syssstat tool suite is certainly the better approach. - Live Demo - z/VM Live Guest Relocation - replay
- z/VM 6.2 Performance Update - replay
- Running Linux-HA on a IBM System z - replay
May 2, 2013
New performance whitepaper on exploiting System z crypto hardware with WebSphere 8 for Linux on System z
System z offers hardware accelerations for all kinds of cryptographic operations. The new whitepaper "IBM WebSphere Application Server Version 8 for Linux on IBM System z – SSL Setup and Performance Study" shows how to set up WebSphere and Linux.
The performance numbers are quite impressive, especially for RSA 4096.
The performance numbers are quite impressive, especially for RSA 4096.
April 4, 2013
New article: Using Crypto Hardware with Java in Linux on System z
A new article on how to use the System z crypto hardware from Java inside Linux on System z has been published. The authors describe the available hardware for acceleration, the Linux software stack as it relates to Java. clear key and secure key handling.
However the most instructive part from my perspective is the Java example program and the "howto" description.
However the most instructive part from my perspective is the Java example program and the "howto" description.
March 21, 2013
Java for Linux on System z - download and base documentation
There are several ways for getting the IBM JDK for Linux on System z
- It's included with a lot of products like Websphere application server
- It's included with the distributions delivered by SUSE and Red Hat
- It can be downloaded from Developerworks
- Linux User guides for Java 1.4, Java 5 and Java 6
- Diagnosis guides for Java 1.4, Java 5 and Java 6
- Java 7: All in one Java Information Center. For the diagnosis guide choose "IBM User Guide for Java V7 on Linux" --> "Troubleshooting and support"
March 11, 2013
How to limit CPU usage of suspect runaway processes
Have you ever had the problem that a Linux guest under z/VM was using "too much" CPU and when you looked closer you identified a specific process in this guest? But you couldn't reach the application team, so just recycling this process isn't an option? And maybe it's still doing something reasonable, so a
kill -SIGSTOP [pid]
isn't an option.
The first option to solve the impact is to reduce the share from a z/VM perspective for this specific guest. So the usual SET SHARE ... But this will impact all processes in the guest, so if you have more than one application in a guest this isn't really an option.
The second option requires a tool called cpulimit. I've tried it on a SLES 11 SP2+ and here is what's needed to get it going. Download it from github and then build it on System z by calling make. Copy the binary to a default search location e.g. /usr/local/bin. Next find out the PID of the offending process e.g. by using top:
top - 14:58:30 up 11 min, 2 users, load average: 12.38, 3.10, 1.19
Tasks: 109 total, 2 running, 107 sleeping, 0 stopped, 0 zombie
Cpu(s): 91.0%us, 0.1%sy, 0.0%ni, 8.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16124M total, 8645M used, 7479M free, 6M buffers
Swap: 0M total, 0M used, 0M free, 135M cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3487 root 20 0 4724m 90m 11m S 909 0.6 4:41.35 java
Now limit this process to e.g. one CPU (I'm using 10 CPUs on this system) by
cpulimit --limit=100 --lazy --pid=3487
This tells the utility to limit to one CPU and exit if the process ends. I've had vmstat running while I entered this and the reduction is quite ok at the five second interval I've been using:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
12 0 0 7636040 6836 144752 0 0 11 1 88 118 26 0 74 0 0
33 0 0 7635816 6868 146000 0 0 0 2 2161 2634 89 0 11 0 0
34 0 0 7635816 6868 146120 0 0 0 0 2131 2576 89 0 11 0 0
36 0 0 7635816 6868 146236 0 0 0 0 2165 2640 89 0 11 0 0
0 0 0 7635744 6868 146280 0 0 0 6 697 1421 15 0 84 0 0
0 0 0 7635768 6868 146292 0 0 0 0 653 1454 11 0 89 0 0
0 0 0 7635768 6868 146312 0 0 0 0 688 1371 11 0 89 0 0
Note that if you look at this in top, you still see quite some variance. Also don't expect it to be right to the last CPU cycles. But for the purposes here - reducing the CPU consumption down from 9 to 1 without entirely stopping the application - it does do the job.
There is one class of applications for which this doesn't work. Everything that needs an open terminal. As Rob correctly stated in his blog, this approach will disconnect and not reconnect the terminal again.
In newer distributions there is a third option called cgroups. Configured right, you should be able to move the offending PID into a limited group.
Everything should be tested on a test system first before tried on production images!
kill -SIGSTOP [pid]
isn't an option.
The first option to solve the impact is to reduce the share from a z/VM perspective for this specific guest. So the usual SET SHARE ... But this will impact all processes in the guest, so if you have more than one application in a guest this isn't really an option.
The second option requires a tool called cpulimit. I've tried it on a SLES 11 SP2+ and here is what's needed to get it going. Download it from github and then build it on System z by calling make. Copy the binary to a default search location e.g. /usr/local/bin. Next find out the PID of the offending process e.g. by using top:
top - 14:58:30 up 11 min, 2 users, load average: 12.38, 3.10, 1.19
Tasks: 109 total, 2 running, 107 sleeping, 0 stopped, 0 zombie
Cpu(s): 91.0%us, 0.1%sy, 0.0%ni, 8.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16124M total, 8645M used, 7479M free, 6M buffers
Swap: 0M total, 0M used, 0M free, 135M cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3487 root 20 0 4724m 90m 11m S 909 0.6 4:41.35 java
Now limit this process to e.g. one CPU (I'm using 10 CPUs on this system) by
cpulimit --limit=100 --lazy --pid=3487
This tells the utility to limit to one CPU and exit if the process ends. I've had vmstat running while I entered this and the reduction is quite ok at the five second interval I've been using:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
12 0 0 7636040 6836 144752 0 0 11 1 88 118 26 0 74 0 0
33 0 0 7635816 6868 146000 0 0 0 2 2161 2634 89 0 11 0 0
34 0 0 7635816 6868 146120 0 0 0 0 2131 2576 89 0 11 0 0
36 0 0 7635816 6868 146236 0 0 0 0 2165 2640 89 0 11 0 0
0 0 0 7635744 6868 146280 0 0 0 6 697 1421 15 0 84 0 0
0 0 0 7635768 6868 146292 0 0 0 0 653 1454 11 0 89 0 0
0 0 0 7635768 6868 146312 0 0 0 0 688 1371 11 0 89 0 0
Note that if you look at this in top, you still see quite some variance. Also don't expect it to be right to the last CPU cycles. But for the purposes here - reducing the CPU consumption down from 9 to 1 without entirely stopping the application - it does do the job.
There is one class of applications for which this doesn't work. Everything that needs an open terminal. As Rob correctly stated in his blog, this approach will disconnect and not reconnect the terminal again.
In newer distributions there is a third option called cgroups. Configured right, you should be able to move the offending PID into a limited group.
Everything should be tested on a test system first before tried on production images!
March 5, 2013
High Availibility solutions for Websphere MQ and Linux on System z
The standard approach for achieving high availability with Websphere MQ is to use a High Availability Manager and a shared DASD. The following whitepapers describe this for the available options:
- High Availability Solution for WebSphere Message Queue in a single instance queue manager configuration using Tivoli SAfMP and a shared DASD device
- High Availability Solution for WebSphere Message Queue in a Single Instance Queue Manager Configuration using HAE and a Shared DASD Device
- High Availability Solution for WebSphere Message Queue in a Single Instance Queue Manager Configuration Using Linux HA and a Shared DASD Device
February 22, 2013
Red Hat Enterprise Linux 6.4 released
Red Hat has announced the availability of RHEL 6.4. The kernel level is now kernel-2.6.32-358.el6, for the main bug fixes see the kernel update description.
As usual there are the release notes and the technical notes in two separate documents. For System z besides the usual preventive bug fixes also some interesting features have been made available:
As usual there are the release notes and the technical notes in two separate documents. For System z besides the usual preventive bug fixes also some interesting features have been made available:
- FCP end-to-end data checking
- s390utils enhancements
- Storage Class Memory aka Flash Express support
- Support for the Transactional-Execution Facility in zEC12
- Crypto Express 4S (CEX4S) adapter card support in z90crypt
- libica enhancements
- improved compression performance for zlib
- ...
February 12, 2013
Whitepapers for Live Guest Relocation and z/VM 6.2
(updated 3/21/2013)
The Platform Test team for System z has published two new white papers that should help readers to get a smooth start with Live Guest Relocation in z/VM 6.2.
The Platform Test team for System z has published two new white papers that should help readers to get a smooth start with Live Guest Relocation in z/VM 6.2.
- Early Experiences with z/VM 6.2 and Live Guest Relocation: moving from CSE to SSI: This paper describes the installation differences to a classical z/VM installation as experienced by the test team. It's not replacing the product documentation but rather augmenting it.
- z/VM Single System Image Cluster Live Guest Relocation with HiperSockets: Exploitation via Dynamic Routing: Live Guest Relocation and HiperSockets look like a contradiction at the first glance. If you move a z/VM guest off the CEC - what do you do with this network interface? This paper offers a clever approach to this problem, while keeping the solution as flexible as possible.
- z/VM Migration: Migrating the User Directory and RACF Environment: This document describes an automated migration to a new SSI environment using REXX scripts.
- z/VM 6.2 Live Guest Relocation with Linux Middleware: This paper looks at a Java application and the impact and performance for moving it in various scenarios. It also gives recommendations on how to best set up z/VM for Live Guest Relocation
- The z/VM performance update (starting at page 16) at SHARE contains quite some performance results for LGR.
- An Introduction to z/VM Single System Image (SSI) and Live Guest Relocation (LGR): This really is an introduction to the new z/VM functionality
- Using z/VM v 6.2 Single System Image (SSI) and Live Guest Relocation (LGR): This book is a little bit more advanced with concrete examples of moving e.g. an Websphere and a DB2 guest under load.
Subscribe to:
Posts (Atom)