• Resolved kevbot1

    (@kevbot1)


    Hi WP community!

    This is my first post but I am in need of some reasonably urgent assistance but would like to understand what’s happening! So I turn to those who may have come across this before and cross my fingers. I hope that I can get help and that this information will help others in the future.

    I have noticed our host’s disk space allocation filling up disproportionately to the size of the website and its content. The WP_posts DB table is quite large, listing 6.8Gb. The post_type taking up the majority of that space is “HTTP”. Our site is relatively small, with only ~150 pages at the moment.

    Here is the result of an SQL query showing the sheer number of post_type Http:

    post_type Rows Data_in_MB
    HTTP 392010 6786.99
    page 67 1.58
    elementor_library 149 0.67
    attachment 1433 0.52
    product 52 0.19
    product_variation 220 0.07
    nav_menu_item 316 0.06
    custom_css 2 0.04

    For the interest of anyone reading this post who might be running into the same type of issue, I ran the following SQL CLI to produce the above:

    SELECT 
      post_type, 
      COUNT(*) AS <code>Rows</code>,
      ROUND(
        SUM(
          LENGTH(
            CONCAT(
              ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_parent, guid, menu_order, post_type
            )
          )
        )/1048567, 2
      ) AS <code>Data_in_MB</code>
      FROM wp_posts
      GROUP BY post_type
      ORDER BY <code>Data_in_MB</code> DESC;

    I obtained the above from the extremely handy Deep Clean SQL DB post.

    I have run numerous Database optimization attempts using WP DB and optimization plugins that have not cleaned up any of the space as hoped. I presume the records are still regarded as required or aren’t considered problematic. Here are the plugins I have attempted:

    • Advanced Database Cleaner
    • WP Optimize
    • Wp Rocket
    • … and more

    I was using Simple History, which was regarded as a program that was filling up others’ storage with logs in another forum post (that I’ve lost for now), but I have since removed it as well as cleaned out any logs. Simple History was great, but I need to find the culprit.

    Given the DB size, I am unable to open it using free editors like RazorSQL or text editor on my MAC to view each entry in text format to identify what they are or what’s causing the issue.

    I will add more detail if I remember more but hope that’s enough for someone to have an idea of what’s causing this.

    I look forward to an informed response.

    • This topic was modified 3 years, 6 months ago by kevbot1.
Viewing 5 replies - 1 through 5 (of 5 total)
  • Hi @kevbot1

    Which is the purpose of the HTTP post type? Could you have a plugin that is filling this table with these HTTP inputs? Could you delete all HTTP rows? Before, please, make a backup.

    Have a nice day

    Dion

    (@diondesigns)

    Thread Starter kevbot1

    (@kevbot1)

    Hi @diondesigns and @amieiro,

    Thank you both for your replies, this is a great start to my morning! I had a thought of which plugin was causing the issue but didn’t realise which one it truly was. And I had no idea whether simply deleting the wp_posts post_type HTTP records was going to cause me more tribulation than it was worth.

    The link that Dion posted contains the answer! Core Control is a brilliant WordPress plugin (not sure if you have any affiliation with the author @diondesigns) but tucked away in the settings is an HTTP access logger that was enabled. Which is the primary cause of the space issue that I’m having!

    The HTTP post logs date back to 2020 when I installed the plugin, so I don’t believe that the logs are being cleared on the 60-day interval as the plugin suggests.

    I ran the following query that produced a filtered 391,980 results:

    SELECT * FROM 'wp_posts' WHERE 'post_content' LIKE '%core_control%' AND 'post_type' LIKE 'http' ODER BY 'post_date_gmt' ASC

    A few amendments to the SELECT query to run my DELETE simulation in phpMyAdmin, produced the same number of results:

    DELETE FROM 'wp_posts' WHERE 'post_content' LIKE '%core_control_http_log_item%' AND 'post_type' = 'http'

    The trigger has been pulled and the wp_posts table is down to 14MB from 6.8GB – a great success!

    I really appreciate the assistance from you both and hope this information can be useful for anyone who’s scratching their head then hitting it against a wall like I was!

    Cheers!

    • This reply was modified 3 years, 6 months ago by kevbot1.
    Dion

    (@diondesigns)

    No affiliation…all I did was a quick Google search, and that page was in the results. I’m glad it helped you to resolve your issue!

    You might want to contact the plugin’s authors and let them know about this issue. Also, since you manually cleared the wp_posts table, it’s worth asking them whether there is any data in the wp_postmeta table that should be cleared as well.

    Thread Starter kevbot1

    (@kevbot1)

    @diondesigns,

    Your Google skills are, therefore, far superior to mine! Again, I really appreciate your response to this post.

    I can see (now) that there is a similar WordPress forums post to the developer of the plugin with the same issue that I had. It seems as though it ‘should’ be regarded as expected behaviour if logging is enabled.

    I’ll mark this topic as resolved. Again, thank you for your assistance WordPress community!

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Huge “WP_posts” table ~8.7Gb mainly post_type “http” – pls help!’ is closed to new replies.