Problem with pages not loading and speed for weeks. Now host sent me a email wants to shut me down

  • Anonymous


    I’m not really sure where to start. I’m not a tech, by any means.

    Several weeks ago my site started running slow. Also when I would be in edit mode some pages would not load or when hit trash or any button it would come up a blank screen.

    I sent in “ticket” to HG and the told me to try a few things. listed below, I did with no difference.

    Today they sent me another email which I will enclose because simply I do not have the slightest idea what to do. I told them this and they suggested I contact you.

    First email. I tried the suggestions, but still doing the same thing.

    We have a couple recommendations to Optimize WordPress sites.

    First, try to reduce the total number of active plugins on your sites. The following types of plugins are known to cause high resource usage and should be avoided:

    – All related posts plugins (WordPress Related Posts, YARPP) can cause significantly high load in most cases.

    – WPRobot3 and other auto-posters can also cause high load issues, and should be disabled if they are causing issues

    – StatPress and other WordPress statistics software should also be disabled, as these too can consume too much CPU in certain cases. Use Google Analytics instead for statistics as well as Awstats which already comes by default on your account.

    – WP Post Views is also a plugin that you’ll want to avoid as it causes significant resource usage.

    – Any other plugins that are not vital to your WordPress should be disabled.

    View this link for further tips on optimizing your blog:

    Second, re-configure the plug-in WP-Super-Cache. This plug-in helps to greatly reduce the CPU required to run a WordPress blog and can help you to have more traffic while using less CPU. You can optimize your WordPress installations for use on our servers by following the tips in this article:

    Second email (today).

    This message is to advise you of a temporary block placed on your database. The database was found to be consuming an inordinate amount of processor time, to the point of degrading overall system performance. While we do limit each account to no more than 25% of a system’s CPU in our terms of service, we do not actively disable accounts until they greatly exceed that number, which is what happened in this case. Requests to this database may become degraded by limiting the maximum number of queries or connections for a limited amount of time, or if there are sustained issues, ultimately we may be forced to block access to this database until the issue has been resolved.

    Resolving this situation may be as simple as adding additional indexes to your database, optimizing the queries used, or something equally easy. If not, it may simply be a matter of moving this database to dedicated services, as it may have outgrown a shared environment.

    If you believe you have a solution to this overuse, we are happy to discuss the situation with you and possibly reinstate the database on the server. Otherwise, we will be happy to assist you with the upgrade process if a dedicated server is the most appropriate solution. Thank you, and we look forward to hearing from you shortly.


    Excessive MySQL activity is caused by (a) a long-running process that locks a table, causing other queries to back up, (b) a query that is not optimized ][example: select all from … and involving a large or complex query], (c) huge table copies/maintenance during peak hours.

    NOTE:, the following are just possible fixes or suggestions, and are not endorsed or supported by HostGator. They are included in the hope that they may apply to your situation, and/or help you reduce the amount of resources your SQL queries consume. As always, it’s best to backup any data before making any changes or adjustments.

    First and foremost, you may need to optimize your tables. The frequency depends on the size and usage of the database, but most databases would benefit from doing something like this on a yearly basis: a) Enter your phpMyAdmin/MySQL control panel. Click on the database (not the table, the database name), and on the right hand column your tables should be listed. Scroll down till you see the .Check all. link. Click on that link, make sure all database tables are checked and then from the drop-down next to it, and carefully select .Optimize table..

    Additionally, adding indexes to your table(s) may improve performance. If you’re not sure what you’re doing, it’s best not to modify any table; caution is recommended. There are various articles ( and It may be best to Google for something like [Your Software Name] MySQL indexes for suggestions.

    If you reply back to this with your IP address ( we will be more than happy to go ahead enable HTTP access for you, so that you can safely work on the script without it causing further issues. Please let us know how you would like to proceed.

    CPU_TIME:77 table_rows_read:315471043 SELECTS:1812 ROWS_UPDATED:1348 ROWS_FETCHED:98235 BUSY_TIME:81 ONNECTED_TIME:433 BYTES_SENT:123905166 BYTES_RECEIVED:1073814 WAIT_TIME:4

    Top table row reads:

    DB_USER: ptfrugal_wrdp1 — TOTAL_CONNECTIONS: 394 — CONNECTED_TIME: 433 — CPU_TIME: 77 — TABLE_ROW_READS: 315471043 — SELECT_COMMANDS: 1812 — UPDATE_COMMANDS: — BUSY_TIME: 81 — BYTES_SENT: 123905166 — BYTES_RECEIVED: 1073814 — WAIT_TIME (IO): 4

    Top WAIT (IO) TIME:

    DB_USER: ptfrugal_wrdp1 — TOTAL_CONNECTIONS: 394 — CONNECTED_TIME: 433 — CPU_TIME: 77 — TABLE_ROW_READS: 315471043 — SELECT_COMMANDS: 1812 — UPDATE_COMMANDS: — BUSY_TIME: 81 — BYTES_SENT: 123905166 — BYTES_RECEIVED: 1073814 — WAIT_TIME (IO): 4

    ptfrugal 22092 0.0 0.0 15856 1540 ? SN Feb27 0:00 imap []

    Thu Feb 28 00:32:51 CST 2013

    Running Processes:

    ptfrugal 22092 0.0 0.0 15856 1540 ? SN Feb27 0:00 imap []

    Running Queries:

    Open connections

    Current Site Requests: /week-21-i-nsstrive-to-reach-my-nsnation-goals-at-nutrisyst /wp-admin/edit.php?page=wp-db-backup&_wpnonce=55cd58c837&fr /wp-admin/edit.php?page=wp-db-backup&_wpnonce=55cd58c837&fr


    Syahir Hakim


    Issues like this usually point to some rogue script of inappropriate settings that’s causing such a high database connections. WordPress is a fairly complex framework, especially when plugins are involved, so it could be difficult to pinpoint the cause. Without access to your server’s control panel, it would be near impossible to.

    In any case, have you tried:

    1. optimising the database tables, like the host suggested?

    2. deactivate all plugins and see if the DB connections and CPU usage drop?



    I did try deactivating each plug-in no change.

    I do not know how to go about optimizing, afraid I will mess it up.

    This is the email they sent today.

    Data points:

    memory usage 44.0000 MB average

    database queries 40 average

    plugin calls 10417 average

    visits 3

    Time breakdown:

    Profiler overhead 1.5796 seconds average

    Margin of Error 0.0314 seconds average

    total 2.5837 seconds average

    site 0.9364 seconds average

    core 0.1270 seconds average

    plugins 0.5725 seconds average

    profile 1.6473 seconds average

    drift 0.0314 seconds average

    Plugins and theme breakdown:

    theme 7.95% 0.2055 seconds average

    Profiler 0.65% 0.0167 seconds average

    About Me 3000 0.03% 0.0007 seconds average

    Ad Squares Widget 1.22% 0.0315 seconds average

    Akismet 0.09% 0.0024 seconds average

    Broken Link Checker 2.47% 0.0637 seconds average

    CommentLuv 0.47% 0.0122 seconds average

    Easy Recipe 0.40% 0.0103 seconds average

    Feedburner Feedsmith Plugin 2.3 0.08% 0.0020 seconds average

    Givecount 0.39% 0.0101 seconds average

    Google Analytics For WordPress 3.89% 0.1004 seconds average

    Nofollow Links 0.03% 0.0007 seconds average

    NoFollowr 0.02% 0.0006 seconds average

    Pin It On Pinterest 0.17% 0.0044 seconds average

    Revision Control 0.33% 0.0086 seconds average

    Scissors Continued 0.14% 0.0036 seconds average

    Sexybookmarks 1.45% 0.0374 seconds average

    Share a Draft 0.50% 0.0129 seconds average

    Wordpress Hit Counter 0.30% 0.0078 seconds average

    Wordpress Seo 3.60% 0.0931 seconds average

    WordPress Database Backup 0.07% 0.0017 seconds average

    Wp Nofollow Categories 0.03% 0.0008 seconds average

    WP Post Signature 1.99% 0.0514 seconds average

    Wp Super Cache 1.28% 0.0331 seconds average

    WPtouch 2.56% 0.0662 seconds average

    Also you have 7455 comments. WordPress starts becoming inefficient at handling the number of posts somewhere between 1500 and 2500 posts, at over about 5000-6000 comments, and over around 7000 tags, give or take a little depending on plugin configuration. Once those numbers are doubled, it becomes exceedingly inefficient, performing very poorly and using a lot of cpu resources to process the results coming back from mysql. You can reduce your account resource consumption by reducing the number of rows in the database tables for wp_comments.


    Syahir Hakim


    Your memory usage and database queries look good, actually. Plugin calls is a bit on the high side but you do have a lot of plugins. How’s the CPU usage looking at the moment?

    Optimising the database is quite easy – just follow the step-by-step instructions that your host provided. It doesn’t involve any coding at all, just point and click.

Viewing 4 posts - 1 through 4 (of 4 total)

  • You must be logged in to reply to this topic.