Jeffrey E Burgoyne wrote:

> >
> >>
> >> Actually I think the behavior is the same, but the entry
> >> in the logs
> >> is different. I know in 1.3 it was chronological, which
> >> leads me to
> >> believe it was actually the finish time not the end time.
> >
> > Where is the difference between the finish time and the end time ?
> > Isn't that the same ?
>
> Sorry, finish time not start time.

you mean start time not finish time ?

>
> >
> > I think i've been the victim of a DOS, realised with a SYN
> > Flood. I'm
> > not sure, but if yes, that's the first time.
> > Currently i try to understand what happened. I have an entry in
> > error_log which hit me on that idea:
> > "[Sat Apr 23 15:19:02 2011] [error] server reached
> > MaxClients setting,
> > consider raising the MaxClients setting"
>
> Pretty sure a syn flood would not do that.

does a typ syn on port 80 starts already a new child process ?

>
> I'll bet that for some reason the connections are being kept
> open. Could be anything, even as simple as a bad keep alive session.
>
> Use the server-status page to see where the connections are
> being held open. It has some good diagnostics, including a
> column for how long the request has been served for.
>
>
> >
> > This is strange because this server has very rare visits, normally
> > just my monitoring tool which checks the webserver every
> > two minutes.
> > This tool (ServersAlive, a windows application) never
> > caused any problems.
> > And beginning from saturday 15:30 the tool complains that it can't
> > access the webserver.
> > I had a lot of sockets on the webserver:
> >
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3134
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3370
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3102
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3351
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3083
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3333
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3170
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3152
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3393
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3247
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3218
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3059
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3312
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3293
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3030
>     CLOSE_WAIT
> >  -
> > tcp      133      0 146.107.x.x:80      146.107.135.80:3269
>     CLOSE_WAIT
> >  -
> > ...

And i also had 150 httpd processes running, + the one from root to open port 80.

>
> OK, based on this and what you wrote below there is something
> with the networking, I am pretty sure. Basically you are
> waiting on IO, which can be network, not just disk. Plus all
> those open connections for what looks likes hours doing
> nothing is also a dead give away. And yes that load average
> is very high, just waiting for IO.
>
>
>
> >
> > The IP 146.107.135.80 is the WinBox my monitoring tool is
> running on.
> >
> >
> > Also "top" on the linux box running the apache was very interesting:
> >
> > top - 13:17:45 up 25 days, 23:40,  4 users,  load average: 155.00,
> > 155.01,
> > 155.03
> > Tasks: 587 total,   1 running, 586 sleeping,   0 stopped,   0 zombie
> > Cpu(s):  0.2% us,  0.3% sy,  0.0% ni,  0.0% id, 99.5% wa,
> 0.0% hi,
> > 0.0% si
> > Mem:   2075564k total,  1802740k used,   272824k free,
> > 130936k buffers
> > Swap:  1028152k total,        0k used,  1028152k free,
> > 914700k cached
> >
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > 12820 root      17   0  2028 1236 1540 R  1.0  0.1   0:00.23 top
> >     1 root      16   0   588  240  444 S  0.0  0.0   0:22.23 init
> >     2 root      RT   0     0    0    0 S  0.0  0.0
> > 0:00.00 migration/0
> >     3 root      34  19     0    0    0 S  0.0  0.0
> > 0:00.22 ksoftirqd/0
> >

Bernd

Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671

Reply via email to