There is a common perception among developers that system health is strictly an admin role that does not overlap with development. Truth be told though, I have a hard time creating such a strict delineation between these roles. They compliment and rely on each other so much that they cannot be totally separated into strictly black and white jobs. As developers then, we need to have a least an entry level knowledge of system administration so that we can help protect the health of our systems.
Joining us last week on iChime to share both her knowledge and adventures on the IBM i was my dear friend, Dawn May. Agreeing that system health is everyone’s prerogative, she shared some invaluable information that was backed up with some great stories. She started with this one, one that was extremely pertinent to the developer crowd on the call.
“A developer decided that creating objects in QTEMP was a great idea – and not bad, maybe. But if you do this a lot, and it needs to scale, it becomes debilitating,” Dawn shared. The company she was telling us about a bank that eventually grew to a big shop and the object creation was never revisited. Eventually, the performance went down over lunch when bank clientele would go to the ATM and perform a transaction on their break.
“It was just because they were creating message cues in QTEMP in the application. One profile owned every message cue,” Dawn said. When creating or deleting a message the object ownership had to be updated in the user profile object. If the creates and deletes are happening on a single profile, it creates a point of contention and then the system stops working.
“In this case, it was an application decision and the application had to be modified to resolve the problem,” said Dawn. “So, system health and development are intimately related.”
And that story kicked off a fascinating conversation in which Dawn shared a wealth of knowledge, rattling off an amazing number of system message IDs without breaking a sweat, and shared stories of success as well as challenges she’s encountered.
Dawn weighed in on other tools such as Navigator, Performance Data Investigator (PDI), Graph History, Performance Adjuster, and ARE. From the standpoint of a developer, she discussed how they can be utilized to help improve or maintain good system performance. To find information and education about each of these tools, Dawn points us to her i Can blog, webinar replays on her website, and to COMMON events and replays.
From tool talk, we turned to hardware upgrades and increasing memory to solve system performance issues.
“Hardware upgrades can be very nice,” Dawn agreed, “but in the case of the story I told earlier about all the object creates and deletes, you could throw all the hardware you want at that and it wouldn’t help.”
Now, a very common response of many developers to problems with system performance is to increase system memory, expecting that this will fix all system performance issues.
“IBM i loves memory and the more you give it the happier it is!” said Dawn. But this is not always going to solve performance issues. “What’s really nice is that we don’t have to guess anymore when it comes to memory. 10-15 years ago, you had to just guess and it was all smoke and mirrors. But within the Performance Data Investigator, there are actually memory usage charts that will show you your memory pools and how much memory you have allocated and how much is available. You now have data to help make your tuning decisions.”
We could have talked all day with Dawn and this is only a high-level overview of her time with us. To really enjoy this system administration for developers conversation, you’ll really want to listen to the podcast when it is released. It was a truly great conversation that you do not want to miss.