Post reply

Lowest PLE value so far

  • August 4, 2016 at 5:08 pm

    #312284

    Hi,

    I have been working in SQL server for last few years. This is for the first time I saw PLE value is at 191. Anyone like to share his/her experience with this kind of low PLE?

    ta

  • August 4, 2016 at 5:43 pm

    #1893964

    well now its <100

  • August 5, 2016 at 2:52 am

    #1893981

    time to put more memory on that machine.

    there can be several reasons for that low value to show up now

    - more data on tables

    - bad sqls processing lots of data - investigate this as it may be easyish to fix

    - more users (hence more sqls being executed and more data being required to be loaded)

  • August 5, 2016 at 3:09 am

    #1893984

    Or maybe you've just done something that drags a lot of data pages in and out of memory, such as index maintenance or a data load?

    John

  • August 5, 2016 at 3:29 am

    #1893989

    It's important how do you do the measurement of the counter.

    You can do it via the perfmon.exe tool. Find the Page life expectancy counter under the Buffer Manager and measure it for a longer period.

    Igor Micev,My blog: www.igormicev.com

  • August 5, 2016 at 4:13 am

    #1893999

    If you using a NUMA machine check the Buffer Node:Page Life Expectancy counter across all your nodes.

    If not using NUMA then ignore me.

  • August 5, 2016 at 8:51 am

    #1894073

    I couldn't care less about PLE, and in fact never check it. What matters is physical IO stalls. Track those via internal DMV and/or using avg disk sec/read and write windows counters. I prefer inside SQL Server because you can see them down to the individual file level.

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • August 5, 2016 at 11:32 am

    #1894119

    I do look at PLE but not for the reason that a lot of others might. It's usually a pretty good indication that there's some seriously inefficient code in the mix that doesn't scale well or has a many-to-many join, questionable database design, or bad index design . Additional memory can certainly help such situations but you'll eventually run into the same problem as data continues to scale up.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply