tag:blogger.com,1999:blog-4516533711330247058.post4541574762438635903..comments2024-03-28T07:32:09.246-07:00Comments on Robert's Db2 blog: Some zIIP Things of Which DB2 for z/OS People Should be AwareRoberthttp://www.blogger.com/profile/02058625981006623480noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-4516533711330247058.post-14128042336123687622020-08-31T13:59:42.751-07:002020-08-31T13:59:42.751-07:00Hello, Dave.
It's still true that you want to...Hello, Dave.<br /><br />It's still true that you want to avoid zIIP engine contention, both to optimize application performance and to minimize the degree to which zIIP-eligible work "spills over" to general-purpose engines. In terms of my messaging on this topic, what I've generally stopped doing is telling people to keep zIIP engine utilization below some percentage - the fact is, the more zIIP engines an LPAR has, the higher the utilization rate at which they can be run while still minimizing spill-over to general-purpose engines.<br /><br />In an entry I posted a few months after this one (https://robertsdb2blog.blogspot.com/2014/09/db2-for-zos-avoiding-ziip-engine.html), I describe how to use information in a Db2 monitor-generated accounting long report to measure the percentage of zIIP-eligible work that is spilling over to general-purpose engines. My goal would be to keep that spill-over ratio below 1% (great), or at least below 5% (OK). If the zIIP spill-over rate were getting higher than desired on my system, I'd want to address that situation by adding zIIP capacity (if I could not add zIIP engines to an LPAR, I might opt to run zIIPs in SMT2 mode - see https://robertsdb2blog.blogspot.com/2018/02/db2-for-zos-ddf-ziip-engines-and-smt2.html).<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-18696107254590347922020-08-28T08:08:57.975-07:002020-08-28T08:08:57.975-07:00Robert is this still true with zIIP Performance
Do...Robert is this still true with zIIP Performance<br />Don't over-utilize zIIP engines<br /><br />One thing that organizations have long liked about mainframe computers is the fact that you can run general-purpose engines at very high levels of utilization -- like 90% or more -- while still getting excellent application performance and throughput. The story is different for zIIP engines, and here's why: if a zIIP engine is not available when zIIP-eligible work is ready to be dispatched, that work can be directed instead to a general-purpose engine, but such redirection introduces a degree of delay. This delay can affect performance noticeably in a DB2 10 (or later) system, because (as previously noted) starting with DB2 10 prefetch processing became zIIP eligible. If prefetch reads are slowed because of overly high zIIP engine utilization, throughput for prefetch-intensive workloads (think batch, and decision support applications) can be negatively impacted. In a case of that nature, a slowdown in prefetch processing would show up in a DB2 monitor accounting long report (or an online display of thread detail data) as elevated "wait for other read" time (that is one of the so-called class 3 wait time categories).<br /><br />Frankly, I'd start thinking about adding more zIIP capacity to a System z server if I saw zIIP utilization regularly reaching 60% or more.<br />Dave Lawrencehttps://www.blogger.com/profile/11306567235560330289noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-77111396930834156732017-05-14T20:00:57.553-07:002017-05-14T20:00:57.553-07:00The fact that a process uses ODBC in accessing DB2...The fact that a process uses ODBC in accessing DB2 for z/OS does NOT make SQL issued by the process zIIP-eligible. zIIP eligibility of SQL does not depend on the data interface used to access DB2. It depends on the nature of the task under which the process is executing, as explained in my blog entry view-able at http://robertsdb2blog.blogspot.com/2013/11/db2-for-zos-work-tasks-thing.html.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-17648453727608937482017-05-10T21:21:32.948-07:002017-05-10T21:21:32.948-07:00Thanks Robert. this helps. one more question, in o...Thanks Robert. this helps. one more question, in our shop we are using GOLDEN GATE product which SYNCs data from Oracle Database on Linux to DB2 on ZOS. There are millions of SYNC calls happens every hour and as per the documentation this is ODBC connection and this should be zIIP eligible. But the SYNC task (GOLDPROD - Golden Gate Task) shows zero zIIP time and Zero ZIIPONCP. So why this ODBC work is not zIIP eligible?<br /><br />DB2 Version 10<br />Oracle 12c<br />Oracle Golden Gate Anonymoushttps://www.blogger.com/profile/00430919353260676573noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-16838082796788043622017-05-09T21:40:39.494-07:002017-05-09T21:40:39.494-07:00When a DRDA workload gets little zIIP offload even...When a DRDA workload gets little zIIP offload even though zIIP engine utilization is low, in my experience this is usually the result of DRDA requesters calling external DB2 stored procedures. An external stored procedure will get next to nothing in the way of zIIP offload, even when called by a DRDA requester, because it executes under a TCB in a stored procedure address space, and SQL that executes under TCBs is not zIIP-eligible.<br /><br />If a batch job drives a lot of prefetch activity, that will not be reflected in the zIIP CPU time shown for the batch job in DB2 accounting trace data. The reason: the CPU cost of prefetch read activity (and for database write activity) is charged to the DB2 database services address space (aka DBM1) - not to the task of the application process that drove the prefetch requests.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-27893882866008678582017-05-06T17:34:33.220-07:002017-05-06T17:34:33.220-07:00In our mainframe system, ZIIP processor is only 10...In our mainframe system, ZIIP processor is only 10% utilized eventhough DRDA usage GP processor is close to 40%. Also we have conducted a test where one of the batch db2 program issuing millions of prefetch but nothing offloaded to ZIIP processor. Please advise.<br /><br />Processor is 2828-X03<br />3 ZIIPAnonymoushttps://www.blogger.com/profile/00430919353260676573noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-82190508281705549182016-05-09T09:15:46.448-07:002016-05-09T09:15:46.448-07:00Technically speaking, there is nothing called zJav...Technically speaking, there is nothing called zJava (nor is there anything called zLinux - it's just Linux on z Systems). Yes, Java code can run natively in a z/OS system - this has been true for quite some years now. A growing number of organizations run high-volume, mission-critical Java application workloads in z/OS systems.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-69450242623898205452016-04-30T17:16:52.903-07:002016-04-30T17:16:52.903-07:00I'm learning some new "Performance tuning...I'm learning some new "Performance tuning" things about ziip and zaap "as we speak" and Java-zOS or zJava is a "new thing" to me in and of itself. I knew you could run zLinux in a zOS LPAR, but I'm understanding that you can now run zJava executables under zOS without zLinux?? I'm going to google that for some additional reading/study material. The "DB2 zOS [PTS] Performance Assessment and Recommendations" report, that I produced for U.S. Postal Service in 2010 included ziip and zaap but not all of the extended ziip/zaap performance considerations mentioned by Robert above. I may have to call them and see if they need to squeeze a little more performance out of their "Christmas Rush" and "Income Tax Rush" "mail overload" seasons. They were also running zLinux (with Java or zJava?) in an LPAR but I don't believe that had anything to do with the DB2 overloads. That's been 5 years ago and I haven't heard anything more about their seasonal overloads, but that doesn't mean it isn't a concern.Ye Olde Goatehttps://www.blogger.com/profile/17175410788346223833noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-90355661174123611312016-04-27T22:44:31.735-07:002016-04-27T22:44:31.735-07:00Thank you, Robert. I could learn some new things i...Thank you, Robert. I could learn some new things in this post, about zIIP.Anonymoushttps://www.blogger.com/profile/01933351445373401076noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-2853931090028758002015-01-24T09:25:35.605-08:002015-01-24T09:25:35.605-08:00Yes, and the reason for that, as I pointed out in ...Yes, and the reason for that, as I pointed out in another blog entry (http://robertsdb2blog.blogspot.com/2013/11/db2-for-zos-work-tasks-thing.html), would be the fact that the native SQL procedure in your scenario would execute under an enclave SRB in the DB2 DDF address space (aka the DIST address space). If that native SQL procedure were not called by a DRDA requester, it would run under a TCB in the address space of the caller (e.g., a local-to-DB2 batch initiator address space) and would not be zIIP-eligible. Similarly, if your DRDA requester called an external stored procedure, that stored procedure's execution would not be zIIP-eligible because an external stored procedure runs under its own TCB in a stored procedure address space.<br /><br />Robert Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-33583015664922044812015-01-23T20:54:05.498-08:002015-01-23T20:54:05.498-08:00Can I offload to zIIP in the following scenario:
P...Can I offload to zIIP in the following scenario:<br />Process P1 running in LPAR1 issues EXEC SQL CONNECT to a LOC2 on LPAR2. P1 calls a native stored procedure on LOC2. Does the native stored procedure use zIIP?Anonymousnoreply@blogger.com