All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Mark Steele <mark@zango.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: strange caching behavior
Date: Fri, 08 Jul 2005 14:17:48 -0400	[thread overview]
Message-ID: <42CEC34C.6040204@redhat.com> (raw)
In-Reply-To: <3C7A1801D550F14B96C2EB6D2C8B989B08350CCD@seaex01.180solutions.com>

Mark Steele wrote:

>I've got a quick question for you NFS gurus. I'll try to keep
>this short but it's a bit complicated to explain.
>
>I've got an NFS server which exports to about 40 other
>clients. The strangeness has occurred on both 2.4.29 and
>2.6.10.
>
>Clients are all running 2.6.11.8 (nfs utils 1.0.6)
>and are serving http requests using Apache 1.3. 
>
>The majority of requests are for php scripts, and the 
>client machines use an opcode cache which compiles the 
>scripts into shared memory and caches them using the 
>filesystem timestamp as a reference to when to update 
>the cached copy.
>
>During normal operations, I'm using about 6 mbits/sec
>of bandwidth for my nfs server (pushing out 60 mbits/sec
>to the internet). However, if I update the files on the NFS
>server, it looks like all client caching goes out the
>window and suddenly start pulling 60-80 mbits/sec from
>the nfs server (still pushing out the same quantity of
>traffic to the internet).
>
>If I shutdown my web servers, and remount them all, traffic
>drops back down to 6 mbits/sec (until the next update on
>my php scripts).
>
>Anyone have an idea on what could be causing this? (or if
>this is expected behavior)
>

It seems to me that it will depend upon how this opcode cache on the client
really works and maybe whether or not you delete the old versions of the php
scripts when you install the new ones.

When the php scripts change on the server, do the clients flush this opcode
cache and then refill the opcode cache from the current versions of the
scripts again?

    Thanx...

       ps


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-07-08 18:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-08 16:28 strange caching behavior Mark Steele
2005-07-08 18:17 ` Peter Staubach [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-08 20:20 Mark Steele
2005-07-08 20:34 ` Peter Staubach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42CEC34C.6040204@redhat.com \
    --to=staubach@redhat.com \
    --cc=mark@zango.com \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.