tux on 2.4.27 kernel and referrer checking

William Lovaton williama_lovaton at coomeva.com.co
Thu Oct 28 21:24:59 UTC 2004


Hi,

El jue, 28-10-2004 a las 13:37, Marek Habersack escribió:
> On Thu, Oct 28, 2004 at 10:14:05AM -0500, William Lovaton scribbled:
> > Very interesting discussion...  A question for all of you: How do you
> > define "stable"?  How do you measure it?  Have you seen crashes with 2.6
> That's an interesting question indeed. As a developer, I measure 'stable'
> with the number of fixes and changes (of any kind, not only bugfixes)
> applied to the branch of a software product labelled as 'stable'. That's one
> side of the coin, the flip side is the "real life" stability, i.e. in
> production, there...

Mmmm... I don't see it like you do. Although you might have a point. 
Even stable software needs maintenance.  In fact, "stable" or
"production ready" means that the software is ready to receive _wider_
testing.  Eg: Production.  Which is the ultimate testing environtment.
;-)

Stability, in a developer point of view, is how much the API changes
breaks backwards compatibility.  According to mailing lists, 2.6 doesn't
seem to be that stable in this regard.

> 
> > kernels?  Are they reproducible?
> ...what's important is the number of security vulnerabilities (often being
> result of 'unstable' code in the sense described above) and glitches that
> cause the machine to misbehave in production. I've seen a few 2.6 crashes
> (mostly on desktop), freezes (desktop and fileserver) and spontaneous
> reboots/freezes (on a moderately busy webserver). The desktop crashes/oopses
> very often have to do with preemption, as for the rest, I'm not sure - the
> BIO (which is still stabilizing IIRC) seems likely to be the problem since
> the freezes occur under I/O load.

I haven't use FC2 in desktops that much but I love what I see, feature
wise and stability wise.  In fact, I'm dying to use FC3 in my
workstation (home and office) ASAP.

> As for 2.4, it has serious problems with
> the VM under stress (heavy webserver load with php/sql activity) to the
> point when an OOM kills not only the process(es) but also the machine.

OOM?? May be you have some serious issues with your lack of memory or
software leaking a lot.

Before the server I mentioned in this thread (SPM 4X 700MHz) we were
using another one a little bit smaller (SMP 4X 550MHz).  It used RH9
with 2.4 kernel and tux.  It was rock solid.


> As for your are they reproducible question. It's another interesting issue -
> for me, personally, the reproducible bugs/glitches are the better ones since
> they are easier to spot and fix. If a software product suffers from
> non-reproducible, random crashes which are definitely related (preemption,
> VM for instance) but don't follow a pattern that's easy to reproduce, then
> there is something in state of flux inside the product and it's not
> production quality. I don't really want to name names here, but if you look
> at the sources of the kernel shipped by one major company, you will be
> amazed that it ships with 2.5MB of bzipped diffs and 1.6MB of vendor
> additions. This is not what I consider 'stable'. I might be wrong, of
> course.

Preemption?? I don't think that any sane distributor will ship a kernel
with preemption enabled.  It just works to find latency bugs but it
doesn't work very well for production use.  Ingo has been doing a great
job releasing patches at a furious rate to improve this situation.

Patched kernels from distributors are ok.  In fact that seems to be
right according to the new development model.  kernel.org will be the
most complete and fastest kernel but not neccesarilly the most stable. 
It's up to the distributors to stabilize the kernels they ship.

> > 
> > I'm using Fedora Core 2 (with official updates) in a high loaded, high
> > traffic production server and it is very, very stable.  Right now it has
> > 25 days of uptime.  It could be more by now, but some reboots have
> > prevented it.
> Can you define high load? We've had machines that were over 150 days of
> uptime under heavy load, only to crash suddenly under the same load. They
> are running 2.4 and can, indeed, be considered stable.

In my case high load means 115 requests/sec according to apache
access_log 70% of them are static content, the rest is dynamic (PHP).  I
have seen peaks of 320 req/sec.  This is why TUX is so great.

The load average is between 40 and 80 during peak times without tux. 
The server gets 4.5 millions of requests per day.

> 
> > The only problem I have is TUX (not using it right now) and that's why
> > I'm subscribed to this list.  Anyway TUX is not present in the official
> > kernel anymore.
> What is the problem with TUX?

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125091

And check the mail archives for my previous mails. ;-)


-William





More information about the tux-list mailing list