IBM i Global

IBM i Global

Connect, learn, share, and engage with IBM Power.

 View Only
  • 1.  Generic memory performance guidelines?

    Posted 23 days ago

    Hello,

    I've been wondering about observing, tuning and actually understanding the situation when it comes to memory performance on the IBM i. Generally I was able to find the "rules of thumb" that when it comes to performance, you should  investigate CPU, memory and disk together - but when it comes to memory, how can I actually see if the values set manually and the values calculated by Performance Adjuster are correctly reflecting the overall system size and workload currently processed by the system? During peak hours, could I expect increased page faults per second (hundreds?) just because the system is large with hundreds of GB of memory and the hundreds of page faults is kind of expected? Or in any case the page faults should not go above the values calculated by the Performance Adjuster, because it takes into account the system size and workload?

    Thank you all for explaining.



    ------------------------------
    Michal Simanek
    Lead Technical Specialist
    Tietoevry Czechia
    ------------------------------


  • 2.  RE: Generic memory performance guidelines?

    Posted 22 days ago
    Edited by Satid S 22 days ago
      |   view attached

    Dear Michal

    The "performance penalty" in each memory faulting event in IBM i is substantially less than that in Unix/Linux/Windows (especially when SSD is used in place of HDD) because of different use of memory in IBM i.  IBM i uses main memory more for object cache than for working memory while the opposite is used for Unix. In IBM i. high memory faulting can happen more frequently than in Unix (with the same application running at the same workload amount) but with minimal negative performance impact.  And since OS/400 V5R4 when job wait accounting was delivered in performance data collection, it is now easy to see the cost of memory faulting in the wait component named Disk Page Fault wait time. A bad case is shown in the sample PDI Wait Overview and Waits By Generic Job or Task charts below:

    In many modern IBM i servers (say, as of POWER7 with no legacy IO HW from POWER6), Disk Page Fault wait time can be minimum, if at all, at peak workload periods. 

    In my experience, memory page faulting performance penalty can be reduced more effectively by improving the overall disk response time than increasing memory pool size, especially in servers with large workload (say, workload needing more than 1 or 2 CPU cores at their peak times).  Another non-system effective way of reducing page faulting penalty is to reduce the faulting rate itself from the application, for example use Index Advisor to create useful DB indexes for SQL/Query jobs..

    >>>>  Or in any case the page faults should not go above the values calculated by the Performance Adjuster, because it takes into account the system size and workload? <<<<

    If I understand your question correctly, the value of page fault per job you see in IBM i Performance Adjuster (WRKSHRPOOL screen) is not about performance guideline. It is a criteria for the Adjuster to start trying to increase the memory pool size to help reduce the average faulting rate in that pool.   

    I attach herewith an article published in 2000 by an IBM Rochester expert discussing memory use and Performance Adjuster for you to study.  But let me tell you that what is discussed there is not of utmost importance now when all HW components of the server are much improved compared to those in 2000.   



    ------------------------------
    Satid S
    ------------------------------

    Attachment(s)



  • 3.  RE: Generic memory performance guidelines?

    Posted 22 days ago

    Hi

    In these cases, I usually look at the "Memory Available by Pool" graph in the PDI in Navigator.

    The graph could show you if the system requires more memory or if youu need to change something in memory pools.



    ------------------------------
    Carlos Martín
    ------------------------------