Contents |
What are Resource Usage Policies?
In a shared hosting environment, a server's resources are what economists would call a common pool resource, meaning that although having plenty of available system resources benefits everyone, no single user has an incentive to ensure that they don't use too many resources themselves. In an effort to protect against the tragedy of the (server) commons, we have placed limits on the amount of a server's resources that any given user may consume.
The Purpose of these Policies
Understand that these policies are in place to protect you, our customers, from poor service quality. Generally, if we need to impose a restriction on an account for resource abuse, that account is in violation of at least two of these policies (or one policy to a very serious degree) and is adversely affecting the other clients on their server. The large, large majority of sites, at least 99.5%, will never even have to take these limits into consideration. That being said, it's good to make yourself aware of them.
Enforcement
It is also important to note that many of these limits can be seen as 'soft' limits. They are not actively enforced, and you can run up to or even over most of them without issue. If, however, you start to affect the overall performance of a server, we do need to have limits and policies in place. Without them it's incredibly hard to explain to the customer, in quantitative terms, exactly how a site is consuming too many system resources.
The Policies
Processes
- Processes should not:
- consume more than 30 MBs of RAM.
- utilize in excess of 15 seconds of CPU time.
- exceed more than 64 simultaneously open files.
- create core dumps.
- The number of simultaneous processes should not exceed 5.
- No process may fork in such a way as to to create a fork bomb.
- Programs may not run in the background or listen on a network port. If you require a bot, service or daemon, you should consider a dedicated server, as very few shared web hosts allow this type of program.
Databases
- All MySQL users are restricted to 15 concurrent connections.
- No single database may exceed 2 GB disk space.
- No database should be queried more than 3,000 times per hour.
- The number of database changes (insert/update/delete) should not exceed 1,000 per hour for a given database.
- Database servers should not be used as a hosted solution. Databases should only be accessed from sites hosted on a TIERRA server. You may, however, access your database remotely for development purposes (i.e. running scripts on your local computer against your TIERRA database).
Files and Directories
- The total number of files and directories in an account may not exceed 50,000.
- A directory can not contain more than 2,500 immediate child files. This includes subdirectories themselves, but does not include files contained within those directories.
Web and Email
- Simultaneous Apache connections may not exceed 50.
- Web processes should not fork or spawn subprocesses.
- Files in excess of 10 MB should not be sent via email.
- Processes should not send outbound mail to more than 25 recipients at any given time.
Cron Jobs
- All cron jobs must be 'niced' to 15 or greater (see the Unix manpage for 'nice' for more information).
- A cron job should not execute more frequently than once every 15 minutes.
Shell
- Our servers should not be used as an SSH bounce point to other servers/networks.
- You may not use the Unix 'find' command recursively on directories more than 5 levels deep.
Our Approach to Excessive Resource Usage
Resource usage is a reality of shared hosting, as the term 'shared' implies. There's a reason you pay a low per month rate for a shared hosting account, rather than the up to 1500 dollars a month price of a dedicated server, even though the space and bandwidth allotments are often mildly comparable. You're in an environment with other customers, and that carries with it certain restrictions and responsibilities. You can't manage your site with impunity, and you can't expect that, under all circumstances, you will be able to max out the bandwidth allocated to your account. There are other, more significant--albeit less tangible--limitations that can be and often are reached first.
Perhaps the most important thing to remember is that the a large bandwidth quota is not, by any stretch of the imagination, to trick customers into thinking that they can host any site under the sun on our servers for a low monthly rate. It should not be seen as a guarantee that you will be able to push the envelope of bandwidth per month on your shared hosting account. Even on many dedicated servers, unless your site is properly designed and optimized, you probably wouldn't be able to use that much bandwidth. You should see the bandwidth quota as more of an indication so that bandwidth will probably not be a primary factor in determining whether your account belongs in a shared hosting environment. Similarly, many providers offer unmetered bandwidth, meaning that they don't even bother tracking sites' bandwidth usage. But you can be certain that their lack of a hard bandwidth limit is not tantamount to a claim that their shared hosting accounts are suitable for hosting any and all websites. To the contrary, it is a very good indication that they use other factors to determine whether a site belongs on a shared hosting account.
Once again, our motivation for choosing such a our bandwidth(s) limit was, as described above, to indicate to customers that we're not overly concerned about your site's bandwidth usage. To make the assumption that because we are not concerned about bandwidth usage that we are not concerned about any of your site's resource usage would be a logical fallacy.
As a shared hosting provider, we have a responsibility to ensure that all sites have access to their fair share of the server's resources when needed. The fact of the matter is that some sites just don't belong on a shared hosting account, and we would be remiss in our duties if we allowed them to remain on our servers. You can expect any responsible hosting provider to do the same.
