you must remeber to subtract 2 from that number
a good program to see whats going on is top
also
what irc server do you admin? :)
--Jon Torrez
.signature starts here.
-------------------------------------------------------------------------------
\|/ ____ \|/
"@'/ ,. \`@"
/_| \__/ |_\ Jon Torrez
\__U_/ jon@stac.org
On Sun, 15 Dec 1996, Joel Boring wrote:
>
> We just purchased a Cyrix686-133 system for a mail server. I estimate this
> machine handles in excess of 20 thousand messages a day. We are having little
> trouble with the system, but there are a few things we are looking for. I
> found your email addresses in various related (hopefully) source trees, and
> was wondering if you might be able to help.
>
> It seems we finally have the process limit and fd limit bumped up enough to
> handle the load, but we have been looking for a linux utility similar to sun's
> "pstat" that will count the current running processes, open descriptors, and
> memory usage, and print it out. We are currently using "ps ax | wc -l" to get
> the process total, but have not yet found a way to count total open files.
> Sun's "pstat" looks like this:
>
> ~ (/dev/ttyud) dwild@eskimo> pstat -T
> 1013/4500 files
> 1951/4000 inodes
> 445/1500 processes
> 299860/1165040 swap
> ~ (/dev/ttyud) dwild@eskimo>
>
> It would be much appreciated if you could point me to something like this, even
> if it is alpha code. This way if it's already started we won't need to spend
> time re-writing it.
>
> Another problem we are having is with NIS lookups through libc. It appears,
> when using the "getpwnam" and "getpwuid" calls, the system is returning
> incorrect data on the first hit, but correct data when it reads from the cache
> (for NIS records only). This was causing sendmail to bounce messages to users
> who exist on the system; when the load on the system was high, mail was being
> delivered to the wrong users. There appears to be no pattern to the
> misdeliveries, I havn't really looked at the libc code yet but it appears there
> is some garbage somewhere that is being cast or wrapped to a random UID. We
> have worked around this problem temporarily by keeping a local copy of the
> password file on the system.
>
> If any of you could help us out with this, or possibly point me to a linux
> developers' list, it would be much appreciated.
>
> Thanks!
>
> --
> Joel Boring (aka Derek Wildstar) Eskimo North
> dwild@eskimo.com, DWildstar@IRC Seattle, WA
> IRC Admin / Assistant Sysadmin / Tech Support (206) 361-1161
>
>
>
>