lkml.org 
[lkml]   [2002]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.4.19rc2aa1 VM too aggressive?
    From
    Date
    On Fri, 2002-07-19 at 16:03, Johannes Erdfelt wrote:
    > On Fri, Jul 19, 2002, David Rees <dbr@greenhydrant.com> wrote:
    > > On Fri, Jul 19, 2002 at 04:33:50PM -0400, Johannes Erdfelt wrote:
    > > > I recently upgraded a web server I run to a the 2.4.19rc2aa1 kernel to
    > > > see how much better the VM is.
    > > >
    > > > It seems to be better than the older 2.4 kernels used on this machine,
    > > > but there seems to be lots of motion in the cache for all of the free
    > > > memory that exists:
    > > >
    > > > procs memory swap io system cpu
    > > > 3 0 0 106036 502288 10812 67236 0 0 0 0 802 494 46 37 17
    > > > 5 0 2 106032 476188 10844 91496 0 0 4 316 905 573 54 37 8
    > > > 16 0 2 106032 355400 10844 203880 0 0 4 0 909 540 51 49 0
    > > > 10 0 2 106024 340108 10852 221548 0 0 28 0 975 659 36 64 0
    > > > 0 0 0 106024 528340 10852 43572 0 0 4 0 569 426 17 17 67
    > > > 0 1 0 106024 531304 10852 43612 0 0 4 0 542 342 9 14 77
    ...

    > Web server. The only writing is for the log files, which is relatively
    > minimal.

    But IMHO, you are using prefork, and not a threaded model correct?

    >
    > One thing also, is there is lots of process creation in this example.
    > For a variety of reasons, PHP programs are forked often from the Apache
    > server.

    Also, here, even as a DSO, which I think you may not be running PHP as,
    (cgi vs. dso), you will use a bit of memory, on top of apache, every
    time the new child is created by apache to handle incoming requests.

    > The systems running an older kernel (like RedHat's 2.4.9-21) are much
    > more consistent in their usage of memory. There are no 150MB swings in
    > cache utiliziation, etc.

    Hrrmmm....I'd suggest a 2.4.17 or 2.4.19-rc1-aa2 in that case. I promise
    you'll see drastic improvements over that kernel.

    > What's really odd in the vmstat output is the fact that there is no disk
    > I/O that follows these wild swings. Where is this cache memory coming
    > from? Or is the accounting just wrong?

    I think the accounting is quite correct. Let's look real quick.

    <vmstat>
    > > > procs memory swap io system cpu
    > > > 3 0 0 106036 502288 10812 67236 0 0 0 0 802 494 46 37 17
    > > > 5 0 2 106032 476188 10844 91496 0 0 4 316 905 573 54 37 8
    > > > 16 0 2 106032 355400 10844 203880 0 0 4 0 909 540 51 49 0
    > > > 10 0 2 106024 340108 10852 221548 0 0 28 0 975 659 36 64 0
    > > > 0 0 0 106024 528340 10852 43572 0 0 4 0 569 426 17 17 67
    > > > 0 1 0 106024 531304 10852 43612 0 0 4 0 542 342 9 14
    </vmstat>

    Now let's take a closer look....

    <vmstat2>
    > > > 16 0 2 106032 355400 10844 203880 0 0 4 0 909 540 51 49 0
    > > > 10 0 2 106024 340108 10852 221548 0 0 28 0 975 659 36 64 0
    </vmstat2>


    Notice you're memory utilization jumps here as your free is given to
    cache.

    <vmstat3>
    > > > 0 0 0 106024 528340 10852 43572 0 0 4 0 569 426 17 17 67
    > > > 0 1 0 106024 531304 10852 43612 0 0 4 0 542 342 9 14
    </vmstat3>

    And then back again, probably on process termination.

    At that rate, it's all in-memory shuffling going on, and for preforks,
    that very likely is the case.

    > JE
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    --
    Austin Gonyou <austin@digitalroadkill.net>
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.029 / U:0.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site