SuPHP Problem

[fettehenne]

Habe ein seltsames Problem:

Sobald der Apache (1.3.xxx) mehr als 250 Prozesse am laufen hat kommt beim Aufruf irgendeiner Webseite kommt der 500er "Internal Server Error".

In der Error Log steht dann:

[Tue May 24 15:37:04 2005] [error] [client 84.58.28.251] (11)Resource temporarily unavailable: couldn't spawn child process: /var/ww
w/web47/html/image1new.php

In der httpd.conf sind folgende Einstellungen:

MaxKeepAliveRequests 120
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 15
StartServers 5
MaxClients 600
MaxRequestsPerChild 200


Woran könnte es liegen, dass er bei genau 250 Prozessen solches Verhalten an den Tag legt?


Für alle Antworten dankbare Fettehenne

[mc5000]

RLIMIT_NPROC oder maximale Anzahl Prozesse?

[Joe User]

Process Creation

Prior to Apache 1.3 the MinSpareServers, MaxSpareServers, and StartServers settings all had drastic effects on benchmark results. In particular, Apache required a "ramp-up" period in order to reach a number of children sufficient to serve the load being applied. After the initial spawning of StartServers children, only one child per second would be created to satisfy the MinSpareServers setting. So a server being accessed by 100 simultaneous clients, using the default StartServers of 5 would take on the order 95 seconds to spawn enough children to handle the load. This works fine in practice on real-life servers, because they aren't restarted frequently. But results in poor performance on benchmarks, which might only run for ten minutes.

The one-per-second rule was implemented in an effort to avoid swamping the machine with the startup of new children. If the machine is busy spawning children it can't service requests. But it has such a drastic effect on the perceived performance of Apache that it had to be replaced. As of Apache 1.3, the code will relax the one-per-second rule. It will spawn one, wait a second, then spawn two, wait a second, then spawn four, and it will continue exponentially until it is spawning 32 children per second. It will stop whenever it satisfies the MinSpareServers setting.

This appears to be responsive enough that it's almost unnecessary to adjust the MinSpareServers, MaxSpareServers and StartServers settings. When more than 4 children are spawned per second, a message will be emitted to the ErrorLog. If you see a lot of these errors then consider tuning these settings. Use the mod_status output as a guide.

In particular, you may need to set MinSpareServers higher if traffic on your site is extremely bursty - that is, if the number of connections to your site fluctuates radically in short periods of time. This may be the case, for example, if traffic to your site is highly event-driven, such as sites for major sports events, or other sites where users are encouraged to visit the site at a particular time.

Related to process creation is process death induced by the MaxRequestsPerChild setting. By default this is 0, which means that there is no limit to the number of requests handled per child. If your configuration currently has this set to some very low number, such as 30, you may want to bump this up significantly. If you are running SunOS or an old version of Solaris, limit this to 10000 or so because of memory leaks.

When keep-alives are in use, children will be kept busy doing nothing waiting for more requests on the already open connection. The default KeepAliveTimeout of 15 seconds attempts to minimize this effect. The tradeoff here is between network bandwidth and server resources. In no event should you raise this above about 60 seconds, as most of the benefits are lost.

[fettehenne]

Alles klar. Vielen Dank. Das war schon mal ein richtiges Stichwort.

The MaxClients directive sets the limit on the number of simultaneous requests that can be supported; not more than this number of child server processes will be created. To configure more than 256 clients, you must edit the HARD_SERVER_LIMIT entry in httpd.h and recompile.

Ich denke bei der Gelegenheit werde ich wohl den Apache auf den 2.0.1 updaten, denn da kann man das anscheinend mit dem mpmworker steuern.