AS/400s Are From Rochester, RS/6000s Are From Austin
October 15, 2007 Doug Mewmaw
|
Last week, I did something that I never thought would happen in my IT life. I am a 19-year AS/400-iSeries-System i veteran, and I had the pleasure of attending my first ever System p Technical Conference, which was hosted in San Antonio, Texas. After one week of sessions and talking with my fellow conference attendees, my wife texted me and asked about the conference. My text messages are normally very wordy, as I admit I’m a bit old fashioned. I think I shocked my wife with this simple response: “OMG–I am in another world.” My daughter taught me the OMG part. Many years ago, my wife gave me a book called Men are from Mars; Women are from Venus, by John Gray, who explained to all of us menfolk the inherent differences between men and women. At first, I thought, “Maybe this is not good; I don’t need a book to know that men and women are different.” After I finished the book, not only did I did feel I understood the opposite sex a little better, but I thought that the title of the book was absolutely perfect. That is, I think all men would agree that sometimes it feels like men and women are truly from two very different worlds. Considering that IBM has more or less merged the System i and System p server divisions in to the new Power Systems division (with the entry System i machines being tossed into a Business Systems division), it is perhaps appropriate to think about how different the AS/400 and RS/6000 lines have been and how their follow-ons continue to be different despite the similar hardware foundation they now share. With the risk of upsetting my new System p friends and colleagues, I felt obligated to share the following observations and ask with some basic questions. First, how can the System p and System i hardware be basically the same, but the approach to performance management be so completely different? This one shocked me. I am blessed that I have been taught by some amazing people in the IT industry. I can’t think of a day when I didn’t learn something new. As a technical support manager for a Fortune 500 company, I was always under constant scrutiny to keep my production systems running efficiently. Performance management was always a priority. As a result, I learned the best practices to keep my systems up and running. That is, on the System i side, there are some critical best practice guidelines to which one must adhere to have the best chance for solid performance. An example is machine pool faulting. While not every single person knows how critical this metric is, I would venture to say that most everyone agrees that it is a platform best practice guideline. No ifs, ands, or buts . . . machine pool faulting has to be low. Period. Since I was a System p rookie and had a lot of experience in performance management, I thought a good approach for me would be: To document the System p best practice performance guidelines. That way, I would have some solid System p fundamentals to start from. During the conference sessions and the like, I talked to a lot of people as I am not shy. To my utter horror, I discovered three things in the p world.
I’ll give you one simple memory parameter example as my proof for statements 1 and 2. In one session, it was explained to me how important the “maxfree” and “minfree” parameters were. I thought, “Finally, I’ll learn some key parameter settings and always remember the guideline.” The parameter was discussed in four different sessions, and to my shock, I was given four different best practice guidelines. After the fourth class, I stopped taking notes. I mean really, how can there be four different settings?!? When I brought it up to some new friends at dinner, to a person they all said, “That’s just the way it is on the System p side of the IBM house.” Here’s the proof for statement 3. Countless sessions, including customer testimonials, “encouraged” users to boot the system to get production systems back up quickly when performance problems occurred. In other words, instead of creating an efficient environment where impeccable service levels exist, it was being taught that downtime is just part of the System p world culture. That’s unreal. I about fell out of my chair when I heard this. But after a week in the System p world, I think I understand why that culture exists, which brings me to my next question. Why does System p performance management have to be done at an archaic level? See the examples below: (Example A) # vmstat 2 5 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 51696 49447 0 0 0 6 36 0 104 188 65 0 1 97 2 0 0 51698 49445 0 0 0 0 0 0 472 1028 326 0 1 99 0 0 0 51699 49444 0 0 0 0 0 0 471 990 327 0 1 99 0 0 0 51700 49443 0 0 0 0 0 0 473 992 330 0 1 99 0 0 0 51701 49442 0 0 0 0 0 0 469 986 329 0 0 99 0 (Example B)
I realize I’m a bit biased because I work for a software company that excels in capacity planning and performance management, but remember I was a customer long before I worked for my current company. My responsibility was to have the systems up and running efficiently. Let’s all be honest. Which is easier to understand? Example A or example B? Hint: There is a saying: A picture is worth a thousand words. Seriously, if I walked into my CIO’s office and gave him a VMSTAT output report, he would roll his eyes and ask me to leave, which brings me to my final question. Isn’t it time for the System p world to embrace the fact that there might be tools out there to help administrators do their jobs better? In my unofficial survey, I asked 20 people if they had an easier way to understand performance on their System p machines, would they change their current methodology? The response was shocking. About 75 percent of those I talked to looked at me like I was from Mars. “We don’t do that on the System p side.” Yes, I know. I got it. It was like a badge of courage that System p system administrators managed performance at an OS command level. While I respect my System p colleagues, I feel I must disagree and list the following things that make our lives easier:
Sure, I can still light a candle, add large numbers with pencil and paper, and even cook my food the old fashioned way, but in 2007, does that make any sense? Of course not. To my fellow System p programmers, I would say that performance management does not have to be so cumbersome and confusing. The AIX platform brags about being so innovative, but yet the majority of the folks using AIX seem to have a 1970s mindset. That just seems silly to me. My old boss had a great philosophy in regard to system administration. He called the knowledge of key OS commands and the expertise of performance management software as having the right tools in your systems tool belt. He was absolutely correct. Remember: Using a performance management tool does not mean you can’t use OS commands in your day to day job. Finally, I wanted to say thanks to my new System p friends. Thanks for being patient with me and answering all my questions. Trust me, we are not perfect in the System i world. We just look at things a little differently. With that thought in mind, I started to chuckle when I was waiting for my plane to begin boarding. I was thinking about the difference of the two worlds and had a realization that made me chuckle. It seemed ironic that the System i world had an open mind in regard to managing systems (i.e., using a tool and OS commands together) while the platform that touts the fact that it’s an “open” platform was very closed-minded in regard to managing performance on the box. Finally, to my new System p brethren, I’ll meet you in the middle. I’ll learn all the important OS performance commands like a veteran AIX systems programmer as long as you do one thing for me. I simply challenge you to come out of the System p performance darkness and see a whole new world. Put down the candle and flip on a light switch. Your performance management world will become a lot clearer and brighter. Doug Mewmaw is an 25-year “jack of all trades” IT veteran who currently is director of Education & Analysis at Midrange Performance Group, an iSeries business partner that specializes in performance management and capacity planning. He can be reached at DMewmaw@mpginc.com. RELATED STORY Why American Employees Are So Unhappy
|
