Not worth the aggravation

[admin]

P.S. Could you please change the Pong Master text next to my name to Aleeious Lead Developer Thanks.

Are you not able to update your title in the forum?  If not, I will do this for you.

[admin]

EDIT: You should also remove PHP versions that have reached EOL(end-of-life) PHP 5.3 EOL Announcement and require the site owners to use the next higher version. If the scripts on the site stops working then the owner will hopefully "wake up" and can either upgrade the script to a newer version, ask the script publisher to support the latest PHP version or move to a different script. I once had a very bad experience with a host that refuses to upgrade past 5.2.17 because:

Sorry for the double post.  Our plans are to remove 5.2 and 5.3 once 5.6 is released.  (5.2 may very well be removed before that.  It has only been kept due to compatibility reasons for some users, but honestly it is not worth the risk.)  The problem is that some have 5.2.17 selected that can use a newer version.

[Scorpion Illuminati]

EDIT: You should also remove PHP versions that have reached EOL(end-of-life) PHP 5.3 EOL Announcement and require the site owners to use the next higher version. If the scripts on the site stops working then the owner will hopefully "wake up" and can either upgrade the script to a newer version, ask the script publisher to support the latest PHP version or move to a different script. I once had a very bad experience with a host that refuses to upgrade past 5.2.17 because:

Sorry for the double post.  Our plans are to remove 5.2 and 5.3 once 5.6 is released.  (5.2 may very well be removed before that.  It has only been kept due to compatibility reasons for some users, but honestly it is not worth the risk.)  The problem is that some have 5.2.17 selected that can use a newer version.

True, however they will be running newer versions of PHP that are more secure and compatibility won't maa difference throwing out the whole "5.2.17 for compatibility" issue. As for the others that aren't compatible my last comment still stands.

P.S. Could you please change the Pong Master text next to my name to Aleeious Lead Developer Thanks.

Are you not able to update your title in the forum?  If not, I will do this for you.

Nope, seems when you upgraded the forum you removed the permissions required to self update it. Thanks for updating it.

Sincerely,

Aleeious

[admin]

EDIT: You should also remove PHP versions that have reached EOL(end-of-life) PHP 5.3 EOL Announcement and require the site owners to use the next higher version. If the scripts on the site stops working then the owner will hopefully "wake up" and can either upgrade the script to a newer version, ask the script publisher to support the latest PHP version or move to a different script. I once had a very bad experience with a host that refuses to upgrade past 5.2.17 because:

Sorry for the double post.  Our plans are to remove 5.2 and 5.3 once 5.6 is released.  (5.2 may very well be removed before that.  It has only been kept due to compatibility reasons for some users, but honestly it is not worth the risk.)  The problem is that some have 5.2.17 selected that can use a newer version.

True, however they will be running newer versions of PHP that are more secure and compatibility won't maa difference throwing out the whole "5.2.17 for compatibility" issue. As for the others that aren't compatible my last comment still stands.

P.S. Could you please change the Pong Master text next to my name to Aleeious Lead Developer Thanks.

Are you not able to update your title in the forum?  If not, I will do this for you.

Nope, seems when you upgraded the forum you removed the permissions required to self update it. Thanks for updating it.

Sincerely,

Aleeious

I agree with you about older PHP versions, especially 5.2.17.  We will force these to at least 5.3.28 and remove 5.2.17 as a selection.  I have found some users still using 5.2.17 because that is what they were using on the old servers, even though they are running newer scripts.  Once 5.6.x is released, the same thing will be done with 5.3, moving all that have 5.3 set to 5.4.  The choices will be 5.4/5.5/5.6 at that time.

[Speedline Z]

I have, i believe an outdated vBulletin or phpbb installed on a subscription or two i asked to be suspended a while back (since i shut the sites down), and thus granted it's not accessible to the web, I also don't have the ability to access it to delete it ... I think i'll shoot you an email shortly about doing some general clean up on my account for all of the things I am no longer using. 

[admin]

This service is starting to get out of hand again.  Users using well beyond their CPU resources, a large number of mysql tables and queries not optimized, outdated scripts, insecure permissions, etc.

I guess our only choice will be to shut this down.

[namhuy]

no way to throttle cpu?

[admin]

no way to throttle cpu?

Not easily with the way things are setup.  It is not just CPU but overall I/O wait that causes problems.

The West server was recently using much CPU, but it was used by Qmail due to a spammer injecting some scripts in an outdated site.  Restricting the user wouldn't have stopped this since it was the Qmail process using a good portion of the resources.  (The rest of the systems are not running Qmail and have less of these issues.)

[markjay]

It so sad that some users are abusing this kind of service that you never find elsewhere. I don't want to see this great service gone... FreePgs.com is still the best and greatest hosting service I have ever found.

[admin]

I feel bad for the users that don't cause problems, but unfortunately, there are numerous problems being caused, most are not intentional (while some are).

-Dormant sites/scripts that then get exploited (because they are not kept up to date)
-Users using too many resources (page loads taking 10+ seconds, easily DoS'd)
-Improperly indexed tables (likely no indexes at all on some)
-Inefficient database queries
-Selection of lower PHP versions that is necessary to run their script.

[Leirosa]

I would be quite sad if this service shut down since I have used it for so long.

After the problems started, I started keeping all my forum scripts up to date, but I am not knowledgeable with optimizing databases. If there is something I can do to help on my end I will though.

If it does close, will there be an option to transfer to an lvcs plan? Although I don't relish paying a lot more to keep my site open, I still have users and my sites mean to much to me and them to shut them down.

[admin]

We are starting to force the few new users into plans where number of connections can be limited.  Hopefully this will help reduce the problem (to some extent), especially if this is extended to the rest of the users.  Existing users of the system are excluded from some of the rules, so we will need to design a custom plan for these users.

For tables: If a field is in the ORDER BY or WHERE clauses, be sure those fields are indexed.  (i.e. If you are filtering for something and/or sorting by something, those fields you are sorting and filtering by should be indexed at the very minimum.)

[Scorpion Illuminati]

I feel bad for the users that don't cause problems, but unfortunately, there are numerous problems being caused, most are not intentional (while some are).

-Dormant sites/scripts that then get exploited (because they are not kept up to date)
-Users using too many resources (page loads taking 10+ seconds, easily DoS'd)
-Improperly indexed tables (likely no indexes at all on some)
-Inefficient database queries
-Selection of lower PHP versions that is necessary to run their script.

So do i, a few bad apples ruining it for everyone is very unfair.

For tables: If a field is in the ORDER BY or WHERE clauses, be sure those fields are indexed.  (i.e. If you are filtering for something and/or sorting by something, those fields you are sorting and filtering by should be indexed at the very minimum.)

Could you please explain this a bit more? Does that mean I should create indexes for all my columns? Any assistance would be greatly appreciated.

Sincerely,

Aleeious

[admin]

I feel bad for the users that don't cause problems, but unfortunately, there are numerous problems being caused, most are not intentional (while some are).

-Dormant sites/scripts that then get exploited (because they are not kept up to date)
-Users using too many resources (page loads taking 10+ seconds, easily DoS'd)
-Improperly indexed tables (likely no indexes at all on some)
-Inefficient database queries
-Selection of lower PHP versions that is necessary to run their script.

So do i, a few bad apples ruining it for everyone is very unfair.

For tables: If a field is in the ORDER BY or WHERE clauses, be sure those fields are indexed.  (i.e. If you are filtering for something and/or sorting by something, those fields you are sorting and filtering by should be indexed at the very minimum.)

Could you please explain this a bit more? Does that mean I should create indexes for all my columns? Any assistance would be greatly appreciated.

Sincerely,

Aleeious

You should create indexes for any column your are sorting or filtering by.  If you are not sorting by that column (i.e. using it in an ORDER BY clause) or filtering by that field (using it in a WHERE clause), this will not be necessary.  [This should also be done if joining tables using these fields.]

[admin]

As long as your site isn't taking multiple seconds per page load, you are generally fine.  (We are not talking about time waiting on downloading files to the client computer, Nginx offloads that part from Apache very well, but time waiting on your pages to generate due to waiting for MySQL, waiting for a remote API, etc.)

For the most part, we try to keep the load low on the servers.  We let users exceed CPU-I/O time limits for a period of time in case they are working with their site or are getting a traffic spike.  When we get complaints on the performance of a specific server, if we find these high resource users and the reason they are using resources is Google is crawling their site (because their site takes 10 seconds to load on each pageview), we generally disable the user and attempt to help them index their tables or explain what processes are using too many resources.

If your site loads fast, you will likely never fall into this group.

By replying to this topic, we didn't want to send the message that we were thinking of discontinuing the service, because we are not.  We may need to consolidate it further in an effort to lose less money, but there is no reason the service will need to be discontinued in the near future.