* Cy Schubert - ITSD Open Systems Group <[EMAIL PROTECTED]> [001013 05:03]
wrote:
>
> Is there a reason why the kernel might hold on to mbufs for "too long a
> time" (I take that to mean longer than it should)?
There are many reasons, one is that you may be sending data that
hasn't been ack'd
In message <199907240405.aaa04...@cs.rpi.edu> "David E. Cross" writes:
: Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters?
: I have a feeling that seeing the data in them would speak volumes of
: information. Preferably a way to see them without DDB/panic would be ideal.
I'v
In message <[EMAIL PROTECTED]> "David E. Cross" writes:
: Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters?
: I have a feeling that seeing the data in them would speak volumes of
: information. Preferably a way to see them without DDB/panic would be ideal.
I've also seen pr
Well, it doesn't appear to be commit() :(.
Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters?
I have a feeling that seeing the data in them would speak volumes of
information. Preferably a way to see them without DDB/panic would be ideal.
--
David Cross
Well, it doesn't appear to be commit() :(.
Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters?
I have a feeling that seeing the data in them would speak volumes of
information. Preferably a way to see them without DDB/panic would be ideal.
--
David Cross
Well, backing out now is not really an option... But given my past history
with NFS, and knowledge of this site I think I have a fair idea where the
leak is... I think it is in the nfsv3 "commit" handler.
Why do I think this? Simple, this problem started when a user started running
a large jo
I'd say that there is a definite leak somewhere. The question is where.
I'll run some buildworld tests w/ the latest current to see if I can
cause mbufs to leak. I suspect that the problem may be related to a
specific situation, though, such as a particular type of FS op failure.
Well, backing out now is not really an option... But given my past history
with NFS, and knowledge of this site I think I have a fair idea where the
leak is... I think it is in the nfsv3 "commit" handler.
Why do I think this? Simple, this problem started when a user started running
a large j
I'd say that there is a definite leak somewhere. The question is where.
I'll run some buildworld tests w/ the latest current to see if I can
cause mbufs to leak. I suspect that the problem may be related to a
specific situation, though, such as a particular type of FS op failure
Ok, here are some real stats
"w" is the read-only machine, it services everything that "s" (the
read-write machine) does... in fact it services more.
*w crossd $ strings -a /kernel | grep \^___maxusers
___maxusers 96
*w crossd $ uname -a
FreeBSD w.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE
Ok, here are some real stats
"w" is the read-only machine, it services everything that "s" (the
read-write machine) does... in fact it services more.
*w crossd $ strings -a /kernel | grep \^___maxusers
___maxusers 96
*w crossd $ uname -a
FreeBSD w.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE
:>
:> I do not think those changes have been backported to -STABLE.
:
:julian 1999/06/30 15:05:20 PDT
:
: Modified files:(Branch: RELENG_3)
:sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c
: nfsm_subs.h
: Log:
: MFC: Bring in NFS cleanup
On Fri, Jul 23, 1999 at 09:06:01AM -0700, Matthew Dillon wrote:
> There is a good chance the leakage is in nfs_serv.c, which I fixed for
> -current.
>
> I do not think those changes have been backported to -STABLE.
julian 1999/06/30 15:05:20 PDT
Modified files:(Branch
:"David E. Cross" wrote:
:>
:> Well, I just -STABLED the server to see if it fixed it, but I was certainly
:> running out. the server had only 3000-ish mbuf chains, and it would go
through
:> them all in a day.
:
: Well, have you tried increasing the number of available mbufs and see if
:y
:>
:> I do not think those changes have been backported to -STABLE.
:
:julian 1999/06/30 15:05:20 PDT
:
: Modified files:(Branch: RELENG_3)
:sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c
: nfsm_subs.h
: Log:
: MFC: Bring in NFS cleanu
On Fri, Jul 23, 1999 at 09:06:01AM -0700, Matthew Dillon wrote:
> There is a good chance the leakage is in nfs_serv.c, which I fixed for
> -current.
>
> I do not think those changes have been backported to -STABLE.
julian 1999/06/30 15:05:20 PDT
Modified files:(Branc
:"David E. Cross" wrote:
:>
:> Well, I just -STABLED the server to see if it fixed it, but I was certainly
:> running out. the server had only 3000-ish mbuf chains, and it would go through
:> them all in a day.
:
: Well, have you tried increasing the number of available mbufs and see if
:y
"David E. Cross" wrote:
>
> Well, I just -STABLED the server to see if it fixed it, but I was certainly
> running out. the server had only 3000-ish mbuf chains, and it would go
> through
> them all in a day.
Well, have you tried increasing the number of available mbufs and see if
you re
"David E. Cross" wrote:
>
> Well, I just -STABLED the server to see if it fixed it, but I was certainly
> running out. the server had only 3000-ish mbuf chains, and it would go through
> them all in a day.
Well, have you tried increasing the number of available mbufs and see if
you reac
Well, I just -STABLED the server to see if it fixed it, but I was certainly
running out. the server had only 3000-ish mbuf chains, and it would go through
them all in a day.
--
David Cross | email: cro...@cs.rpi.edu
Systems Administrator/Research Programmer | Web: h
:I have 2 NFS servers. One is primarily read-only, the other read-write, they
:service the same clients (the read-only services more). They are (were) of
:the same build. I have a problem on the read/write server where it chews
:through mbuf clusters (it goes through about 3k in a day). Especia
I have 2 NFS servers. One is primarily read-only, the other read-write, they
service the same clients (the read-only services more). They are (were) of
the same build. I have a problem on the read/write server where it chews
through mbuf clusters (it goes through about 3k in a day). Especially
Well, I just -STABLED the server to see if it fixed it, but I was certainly
running out. the server had only 3000-ish mbuf chains, and it would go through
them all in a day.
--
David Cross | email: [EMAIL PROTECTED]
Systems Administrator/Research Programmer | Web:
:I have 2 NFS servers. One is primarily read-only, the other read-write, they
:service the same clients (the read-only services more). They are (were) of
:the same build. I have a problem on the read/write server where it chews
:through mbuf clusters (it goes through about 3k in a day). Especi
I have 2 NFS servers. One is primarily read-only, the other read-write, they
service the same clients (the read-only services more). They are (were) of
the same build. I have a problem on the read/write server where it chews
through mbuf clusters (it goes through about 3k in a day). Especially
25 matches
Mail list logo
