TIERRAhosting.com Resource Usage Policy

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 16 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 inodes in an account may not exceed 75,000. Every file (a webpage, image, email, php file, directory, etc.) on your account uses up one (1) inode. This is not something we actively enforce and it will only become an issue if a client is causing problems for other people on the server. We will of course notify you if this is the case with a full explanation.
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

Simultaneous Apache connections may not exceed 50 from one individual source at any given time.
Web processes should not fork or spawn subprocesses.

Email and Mailing Lists

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.
The maximum number of members per mailing list is 1,500.
POP connections are limited to 60 per hour.
SMTP connections (outbound email connections) are limited to 500 per hour per server account.
Any mailing list over 900 emails is only allowed in off peak times such as Saturday and Sunday or from 12am to 7am CST during the week.
Any mailing list must be throttled so that it sends an email every 6 seconds at the very minimum. If the mailing list software you are using doesn't support throttling you must use something else. We do this as this keeps the server load from going very high and causing problems for other users. If you don't do this you will be suspended.
We do not allow you to send to a mailing list you were given or that you bought. This is spamming and we have zero tolerance for this.
Any mailing list must comply with the rules set forth by the United States of America and can be found at: http://www.ftc.gov/bcp/edu/microsites/spam/.
No Direct SMTP mailing system scripts are permitted. Mail should be relayed through the local MTA.

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.

Resource Usage Policy

Your internet presence is very important to us!

Contents

What are Resource Usage Policies?