headers
Steve Simitzis | 2 Oct 2002 10:29

tux dies when using a module

hi there.

i've been using tux successfully on a production web server for about
two months. recently i wrote a simple tux module, similar to demo2.c,
that serves files based on whether or not the browser has a particular
cookie set. the purpose is to protect proprietary files, without
rewriting all of apache's htaccess into tux.

anyway, the module worked fine on my test server, but as soon as i ran
it on our busy production server, one of the worker threads sucked up
99% of the CPU, and tux became useless. it was then impossible to kill
any of the tux processes. i had to reboot the machine for it to return
to sanity.

when the machine came back up, i found this in /var/log/messages:

Oct  2 00:58:07 sg1 kernel: Process tux (pid: 2068, stackpage=df649000)
Oct  2 00:58:07 sg1 kernel: [<f89aa006>] flush_request [tux] 0x566 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
Oct  2 00:58:07 sg1 kernel: [<f89a9227>] redirect_request [tux] 0x67 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
Oct  2 00:58:07 sg1 kernel: [<f89a71a8>] tux_schedule_atom [tux] 0x18 
Oct  2 00:58:07 sg1 kernel: [<f89a807b>] process_requests [tux] 0x8b 
Oct  2 00:58:07 sg1 kernel: [<f89c8114>] threadinfo [tux] 0x3b4 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
Oct  2 00:58:07 sg1 kernel: [<f89b2d05>] event_loop [tux] 0x75 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
Oct  2 00:58:07 sg1 kernel: [<f89b4bcb>] __sys_tux [tux] 0x4eb 
Oct  2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alex Kramarov | 2 Oct 2002 13:14
Favicon

Re: tux dies when using a module

I can only remind of the 99% cpu bug, and that it was fixed in the latest
tux patch. redhat's kernel contains much earlier version. maybe your module
triggers the bug much more often then it was manifesting itself in these
versions normally. the simptoms you describe similar to that bug.

-------Original Message-------

From: tux-list <at> redhat.com
Date: éåí øáéòé 02 àå÷èåáø 2002 10:31:55
To: tux-list <at> redhat.com
Subject: tux dies when using a module

hi there.

i've been using tux successfully on a production web server for about
two months. recently i wrote a simple tux module, similar to demo2.c,
that serves files based on whether or not the browser has a particular
cookie set. the purpose is to protect proprietary files, without
rewriting all of apache's htaccess into tux.

anyway, the module worked fine on my test server, but as soon as i ran
it on our busy production server, one of the worker threads sucked up
99% of the CPU, and tux became useless. it was then impossible to kill
any of the tux processes. i had to reboot the machine for it to return
to sanity.

when the machine came back up, i found this in /var/log/messages:

Oct 2 00:58:07 sg1 kernel: Process tux (pid: 2068, stackpage=df649000)
Oct 2 00:58:07 sg1 kernel: [<f89aa006>] flush_request [tux] 0x566
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Simitzis | 2 Oct 2002 12:28

Re: tux dies when using a module

ah! excellent then. i will give that a try.

i am new to this list (and to tux), however, and i don't know the
best source for tux kernel patches.

i'm looking at http://people.redhat.com/mingo/TUX-patches/ but the
latest patch is dated 02-apr-2002. which patch should i use?

On 10/02/02, Alex Kramarov <alex <at> incredimail.com> wrote: 

> I can only remind of the 99% cpu bug, and that it was fixed in the latest
> tux patch. redhat's kernel contains much earlier version. maybe your module
> triggers the bug much more often then it was manifesting itself in these
> versions normally. the simptoms you describe similar to that bug.
>  
> -------Original Message-------
>  
> From: tux-list <at> redhat.com
> Date: éåí øáéòé 02 àå÷èåáø 2002 10:31:55
> To: tux-list <at> redhat.com
> Subject: tux dies when using a module
>  
> hi there.
>  
> i've been using tux successfully on a production web server for about
> two months. recently i wrote a simple tux module, similar to demo2.c,
> that serves files based on whether or not the browser has a particular
> cookie set. the purpose is to protect proprietary files, without
> rewriting all of apache's htaccess into tux.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Kramarov | 2 Oct 2002 13:36
Favicon

Re: tux dies when using a module


> i'm looking at http://people.redhat.com/mingo/TUX-patches/ but the
> latest patch is dated 02-apr-2002. which patch should i use?

that's the one.
Permalink | Reply | 0 comments |
headers
Alex Kramarov | 3 Oct 2002 20:43
Favicon

gzip.c ?

Hi.

I have noticed that tux uses code from the gzip library from 1996 - does
this code suceptible to the latest zlib vurnerability ???
Permalink | Reply | 10 comments |
headers
Kees Hoekzema | 5 Oct 2002 21:10
Favicon

Bad performance

Hello list,

I'm running a Tux 2.0 server, under a high load. The server is a dual Athlon
1400MP w/ 1G ram and serving the files from NFS. The loadaverages are around
4.

When I benchmark this server it is able to almost 3.24 [requests/sec].
On the server Tux is eating up almost all the CPU:
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
#-1        754 93.3  0.0  1612  700 ?        R    Oct04 1308:59 [TUX worker
0]

My startup script configures tux:

    echo "Starting tux:"
    ## tux configuratie:
    echo "1" > /proc/sys/net/tux/threads
    echo "0" > /proc/sys/net/tux/compression
    echo "/mnt/web/tux" > /proc/sys/net/tux/documentroot
    echo "nobody" > /proc/sys/net/tux/cgi_uid
    echo "nobody" > /proc/sys/net/tux/cgi_gid
    echo "1" > /proc/sys/net/tux/virtual_server
    echo "10" > /proc/sys/net/tux/keepalive_timeout
    echo "0" > /proc/sys/net/tux/logging
    echo "1" > /proc/sys/net/tux/generate_cache_control
    echo "/www/logs/tux" > /proc/sys/net/tux/logfile
    echo "tweakers.net" > /proc/sys/net/tux/default_vhost
    echo "http://0.0.0.0:8080" > /proc/net/tux/0/listen/0
    echo "8080" > /proc/sys/net/tux/clientport
    echo "10" > /proc/sys/net/tux/keepalive_timeout
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alex Kramarov | 5 Oct 2002 22:50
Favicon

Re: Bad performance

first i would do the benchmark while serving from local hd and see if that
solves the problem.

That is the exact tux version you are running ?
----- Original Message -----
From: "Kees Hoekzema" <kees <at> tweakers.net>
To: <tux-list <at> redhat.com>
Sent: Saturday, October 05, 2002 9:10 PM
Subject: Bad performance

> Hello list,
>
> I'm running a Tux 2.0 server, under a high load. The server is a dual
Athlon
> 1400MP w/ 1G ram and serving the files from NFS. The loadaverages are
around
> 4.
>
> When I benchmark this server it is able to almost 3.24 [requests/sec].
> On the server Tux is eating up almost all the CPU:
> USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
> #-1        754 93.3  0.0  1612  700 ?        R    Oct04 1308:59 [TUX
worker
> 0]
>
> My startup script configures tux:
>
>     echo "Starting tux:"
>     ## tux configuratie:
>     echo "1" > /proc/sys/net/tux/threads
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kees Hoekzema | 5 Oct 2002 22:18
Favicon

RE: Bad performance

currently i'm running tux-2.2.7

NFS can't be the problem. My apache server can serve the same file with more
than 1000 req/s (still slow, but ok, it is a loaded server ;))

Also I noticed that the peformance decreases in time. When freshly started
tux can do a lot more than the 3 r/s (more than 10.000 when the server is
idle actually).

It could be an NFS bug in 2.4.18 which has bugged me before. I'm now
patching 2.4.19 with tux, hopefully that solves the poblem :)

-kees

-----Original Message-----
From: tux-list-admin <at> redhat.com [mailto:tux-list-admin <at> redhat.com]On Behalf
Of Alex Kramarov
Sent: Saturday, October 05, 2002 10:50 PM
To: tux-list <at> redhat.com
Subject: Re: Bad performance

first i would do the benchmark while serving from local hd and see if that
solves the problem.

That is the exact tux version you are running ?
----- Original Message -----
From: "Kees Hoekzema" <kees <at> tweakers.net>
To: <tux-list <at> redhat.com>
Sent: Saturday, October 05, 2002 9:10 PM
Subject: Bad performance
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Swanson | 5 Oct 2002 22:08

Re: Bad performance

On October 5, 2002 03:10 pm, Kees Hoekzema wrote:
> Hello list,
>
> I'm running a Tux 2.0 server, under a high load. The server is a dual
> Athlon 1400MP w/ 1G ram and serving the files from NFS. The loadaverages
> are around 4.
>
> When I benchmark this server it is able to almost 3.24 [requests/sec].

Er, my dual P100/128MB beats the snot out of that :-)
Are you sleeping for 1000ms after each client request? :-)
Are you running the latest patch?

Oh, I just realized: you said Tux 2.0. It's been so long since I used that - I 
couldn't even comment. IMHO patching to the latest 2.1 will yield great 
results, and staying with 2.0 may yield frustration and wasted time.

http://people.redhat.com/~mingo/TUX-patches/

Also, like I see Alex just posted, I'd benchmark off the hd first.

Cheers.
Permalink | Reply | 0 comments |
headers
Alex Kramarov | 5 Oct 2002 23:42
Favicon

Re: Bad performance

You are forgetting that apache runs in user space, and tux is in kernel
space - so nfs can present dirrent problems to apache and tux.

and 2.2.7 is only the version of the user-space utilities. If you are using
a kernel from some distro, you can find the version by looking at it's
source,

on my machine it's at
 /usr/src/linux-2.4/include/net/tux_u.h ,

the first few lines will tell you the version, like this

#define TUX_MAJOR_VERSION               2
#define TUX_MINOR_VERSION               1
#define TUX_PATCHLEVEL_VERSION          1

this means tux 2.1.1

----- Original Message -----
From: "Kees Hoekzema" <kees <at> tweakers.net>
To: <tux-list <at> redhat.com>
Sent: Saturday, October 05, 2002 10:18 PM
Subject: RE: Bad performance

> currently i'm running tux-2.2.7
>
> NFS can't be the problem. My apache server can serve the same file with
more
> than 1000 req/s (still slow, but ok, it is a loaded server ;))
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane