We're running a web server, hosting several hundred virtualhosts, most of whom use PHP. Since there is so much use of PHP, I've compiled it into Apache, rather than as a loadable module.
Rather frequently, it seems that a httpd process (we've tracked it happening) will go rogue and consume all memory on the server (1 gig RAM, 2 gigs swap) which brings the server to its knees and make it utterly unresponsive. Since it's co-located, it's an utter pain to have to go in and manually reboot the machine. In /etc/profile, I added "ulimit -v 250000", intending that any process should have no more than a rather generous 250 MB of memory available to it, intending the prevention of a rogue httpd process from devouring all the resources. But it seems that the machine was knocked over again this evening, shortly after a reboot (remotely) to test httpd. I was wondering if putting the "ulimit -v" command in /etc/profile was appropriate for a daemon process. Ulimit is an internal bash command and daemons don't necessarily run from the shell. The httpd server is run from the initscript, which is a shell script; this script will have the ulimit constraints imposed upon it and, I presume, so will the parent httpd process started from this script. But what about the child servers launched by the parent httpd process? I would presume that the shell isn't involved in their invocation by the parent httpd process. Will they inherit the same ulimit constraints that applied to the original shell script? Also, from what I understand, the default action of ulimit is to impose soft limits. Would "ulimit -Hv 250000" in /etc/profile better prevent a rogue process incapacitating the machine? Does anyone have a suggestion how I might better handle this situation? Is there a method within Apache itself for constraining the system resource usage by any virtual host? -- Cheers, Rob _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
