Re: server about to crash

Peter T. Breuer (ptb@it.uc3m.es)
Wed, 8 Jul 1998 16:31:33 +0200 (MET DST)


"A month of sundays ago Alan Cox wrote:"
>
> > Both kernels compiled with gcc 2.8.0 (so are 50 others, all fine)
>
> Plonk. 2.8.1 builds wrong 2.0.x kernels as it optimises stuff that wasnt
> correctly volatiled or otherwise marked. gcc 2.8.0 is also buggy to go
> with it

Yes - I know. With lots of respect (and I _mean_ that) I can't and
don't assume that a compiler in which the bugs are not known is
necesarily "better" than one in which they are known. In other words, I
am not prepared to jump to a newer compiler just because it corrects
some bugs in an older compiler! That said, I am currently testing the
same kernel compiled under 2.7.2, to get a baseline.

(Aside: basically, I like 2.8.0. It produces fast code and it hasn't
yet bit me anywhere I didn't see - I found some bugs when I tried to
produce compiled executables of an interpreted language, and discovered
that in 1% of the code cases the outputs of the interpreted and compiled
codes differed ... but, heck, way back when I was a student I found
bugs in the then _fortran_ double precision arithmetic - jeez, what were
we using? JANET hadn't yet started up -- and I keep finding bugs in the
solaris C compiler, the hpux compiler, umpteen dos C compilers, and I
don't believe gcc is much more or less buggy or that I won't see the
bugs)

> > I see nothing anormal in the netstat output.
>
> Do a right-shift scroll-lock and check the number of network buffers in
> use. (see dmesg) - if its not shift its ctrl or alt :)

Thanks. I'll be looking (I have to go down to check). Well .. on 2.0.33
I can't make head or tail of the output. On my own 2.0.25 box (2.8.0
compiled, etc. etc. ..) it's perfectly clear: 19 net buffers in use,
15M total net buffer allocations. On the 2.0.33 that I went and looked
at, the buffers seemed to be referring to the disk buffers, not the
net. Ahhhhhh .. I see what you mean about dmesg. Here is the 2.0.33
output:

Mem-info:
Free pages: 2344kB
( 164*4kB 111*8kB 8*16kB 3*32kB 1*64kB 4*128kB = 2344kB)
Swap cache: add 15/15, delete 5329667/15, find 75/0
Free swap: 144492kB
16384 pages of RAM
600 free pages
619 reserved pages
8669 pages shared
Buffer memory: 6248kB
Buffer heads: 6248
Buffer blocks: 6248
CLEAN: 4291 buffers, 106 used (last=106), 0 locked, 0 protected, 0 dirty
LOCKED: 1857 buffers, 52 used (last=1850), 0 locked, 0 protected, 0 dirty
DIRTY: 39 buffers, 4 used (last=24), 0 locked, 0 protected, 39 dirty
Networking buffers in use : 9674
Network buffers locked by drivers : 0
Total network buffer allocations : 3151586
Total failed network buffer allocs : 0
Total free while locked events : 0
IP fragment buffer size : 0

ptb% free
total used free shared buffers cached
Mem: 63060 61644 1416 34900 7116 17484
-/+ buffers: 37044 26016
Swap: 144544 52 144492

This machine booted at about 10am today. After bootup it registered
19MB used and no swap. 64M total mem. I have since nfs mounted its
root on another machine, and transferred about 8GB via tar to
/dev/null over nfs. As far as I can see nobody has logged in on its
console. It seems to have only doen 3M buffer allocs.

ptb% uptime
4:26pm up 5:37h, 4 users, load average: 0.02, 0.04, 0.01

ptb% uname -a
Linux arpa 2.0.33 #13 Wed Jul 8 10:32:58 MET DST 1998 i586

(yep - this is the one I compiled this morning under 2.7.2). If you
have any good ideas about which stats to collect, I'm all ears. In the
meantime I'll prepare Ingo's leak detection patch.

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu