View Full Version : RedHat's limit?
OOagent137
2003-07-29, 10:19 AM
Hello,
Right now our server utilization is always between 1-2%. However, we host several hundred domains. I'm curious, what would force us to purchase another server? The sheer volume of domains (even if we had below 5% server utilization) or the server utilization? Thanks.
Striker
2003-07-29, 11:56 AM
When you say "Server utilization" do you mean CPU Usage/Bandwidth Usage/etc ?
OOagent137
2003-07-30, 23:12 PM
I'm not actually sure. In Plesk, under the statistics tab, I see this:
Load Averages:
Last 1 minute: 0.47
Last 5 minutes: 0.37
Last 15 minutes: 0.47
Striker
2003-07-31, 09:47 AM
Load averages are a strange calculation which I wont explain fully unless you want me to.
Basically, they are the average usage of your cpu (unless over 1). Having a few hundered websites can definitely raise them.
Using PHPsuexec or lots of CGI scripts can raise your load averages by quite a lot as well. If you have many websites, it is probably a good idea to avoid PHPsuexec because even one website can raise load averages when it is enabled.
When your load averages are consistenly over .75 and up, it would probably be a good idea too look into getting another server or finding ways to cut down on cpu usage.
OOagent137
2003-07-31, 13:49 PM
We're hosting a few hundred domains.
I didn't realize that we were that close to needing a new server!
We still have TONS of space/bw left.
What's PHPsuexec?
Tino Didriksen
2003-07-31, 14:25 PM
'PHP suexec' is a program to run PHP scripts as the user who created them. This is useful for security reasons, and chmod issues.
However, 'PHP suexec' can only be run in CGI mode, which is around 10x slower than running it as a module (the difference between execution times of 0.01 and 0.1 sec).
You might want to run top to get a little bit better view of what is going on...
Oh, and why don't you setup a test suite and measure response times? Request certain pages at various times using any number of performance test tools. Collect those stats over a week or two to establish a baseline. Then continue your measurements on an ongoing basis and compare them to your baseline. While getting information from tools like top is helpful, trending your response time data may give you a good idea when compared against top about the overall number of sites you can host, etc. Obviously if the box is pegged, you need to do something.
Measuring response times gives you the ability to see that maybe the server has increased to 65% utilization, but response times are increasing faster than utilization and you need to do something now. The thing about response times and system utilization is that as system utilization increases there often comes a point due to resource contention where the response times and performance degrade rapidly.
The reason to use top is to see that maybe the load is high because you are running out of memory or disk utilization is too high. A faster processor doesn't necessarily fix these issues. It may help cover them up, but it won't fix them.
awsolutions
2003-08-03, 10:12 AM
Hello,
In plesk 5.0 I would not go over 500 domains. Low server intensive domains - Of course with some tweaking you could but heres why:
1) Kernel limit - There is a limit to he number of files Red Hat can have open simultanously. Every domain in plesk has atleast 4 open files - even if no one is viewing a page (error_log error_log_ssl access_log access_log_ssl) So you have a box that isn't even connected to the web with 300 domains you already have 12000 files open.
Now add php scripts in there, we all know php scripts have include() functions so add anywhere from 5-10 more files per php script per user viewing them. E-mail will be running and writing files. Now it's very easy to get your server up to 24000 open files without even having the load being slightly high.
2) Apache FD_SETSIZE is set at 1024 by default. This means that apache is only allowed to access a certain amount of memory before "bugging out" What happens when it reaches this size? CGi and PHP scripts will not execute since they cannot access RAM via apache.
3) Makesock could not bind to port 443 errors. The more clients you have on the box the more they will be in the plesk control area and causing the my_apci_rst utility to be running. Well get a runaway apache child process and have my_apci_rst run at the same time and boom, your server is down until you log in and kill that apache process by doing a ps -aux finding the PID and then a kill, or restart your web server. Restarting is something I try not to do until 100 days of uptime or more have been reached.
4) Lets say your box gets own3d - do you want to be responsible for an outragous amount of domains? (1000+ domains).
But then again your talking to someone who has 752 domains on one of his boxes ;-). These are problems I have run into and have had to do some tweaking to get around. I am sure there are plenty more bugs you could possibly hit - like frontpage not working server wide - which I have been working on for 3 days now and sent to the engineers at plesk and they are stumped. But oh well.
knightfoo
2003-08-03, 14:29 PM
originally posted by awsolutions
2) Apache FD_SETSIZE is set at 1024 by default. This means that apache is only allowed to access a certain amount of memory before "bugging out" What happens when it reaches this size? CGi and PHP scripts will not execute since they cannot access RAM via apache.
FD_SETSIZE actually limits the number of file descriptors that can be opened at once .. this includes log files, listening sockets, CGI scripts, etc. By default it is set to 1024, so in theory you should be able to host about 1000 sites without tweaking, right? (assuming each site has one log file, and a common error log for the whole server). Unfortunately, Plesk creates 2 VirtualHosts for every domain, plus a 3rd one if you are using SSL. So after about 250-300 domains, you start having problems.
If anyone runs into this issue, I or someone else can post instructions on how to fix apache for such circumstances.
awsolutions
2003-08-03, 14:38 PM
Knightfoo,
Exactly right, plesk creates 4 logs for each enabled domain (if ssl is enabled). So about 300+ domains you do start to run into problems. It is very easy to fix though!
Real quick, I have run into articles where a ulimit -n in the start up script was needed. I had to do this to my server but still don't understand what it is.....can you possibly explain?
Thanks,
Brian
knightfoo
2003-08-03, 20:55 PM
By default, the child of any shell process is limited to 1024 file descriptors as well. The ulimit -n increases the number of file descriptors, so if you add this to the top of the /etc/init.d/httpd script, any process spawned by this script (such as httpd) will be able to open that many file descriptors. If you increase FD_SETSIZE in apache but do not put ulimit -n #### in the init script, you will not see any change. Conversely, if you do not want a process using too many resources, you can use ulimit to decrease available resources (man ulimit).
A word of caution though .. it may be tempting to set this to some insane number so you never have to worry about this again, but eventually there is a point where the hardware resources (CPU cycles, RAM, disk I/O) will not be able to support what the software is requesting. Another issue is if you set it too high, it could allow a rogue process to take down your whole system by consuming too many resources.
-knightfoo
OOagent137
2003-08-18, 01:57 AM
Ok, I know I've let this alone for awhile, but I'm slowly getting to everything I've been asking about in the forums. Anyway....
Basically, if we want to host more than 250-300 domains, we need to change 2 things?
1) Change FD_SETSIZE in Apache.
2) add this to the top of the /etc/init.d/httpd scipt:
"unlimit -n ####" (some 4 digit number)
Ok. Now, I plan on setting up RLimits (I think they are called RLimits, I have the links that you gave me knightfoo). If I set these up, do I still need to change the FD_SETSIZE? Does PHP and CGI work under the httpd process?
vBulletin® v3.6.8, Copyright ©2000-2008, Jelsoft Enterprises Ltd.