• Resolved Micke123

    (@micke123)


    My WordPress admin is very slow and Query Monitor are reporting very high memory usage. Just opening /wp-admin/index.php I get 7.96S 206.03MB 0.6397S 88Q and similar results every time. Frontend is more reasonable.

    I get one slow query (0.3s): UPDATE wp_options (table isn’t really called wp_). And it is super long. With this string:
    a:1:{s:14:\”dsq_sync_forum\”;a:1 {s:32:\”40cd750bba9870f18aada2478b24840a\”;a:2 {s:8:\”schedule\”;b:0;s:4:\”args\”;a:0:{}}}}i:1436881917;
    repeated over and over again. It takes forever to scroll through.

    However, I’ve got a test site (different tables on the same database) more or less replicating the real site and there I get 1.13S 23.74MB 0.0809S 79Q. And I get the same really long query (it’s not as insanely long, but I’m assuming that is because the database is much smaller on the test site) and it’s taking 0.0255s. (I’ve got a couple of extra plugins, like WordPress SEO, on the real site, but deactivating them makes no difference.)

    I’m really lost as to what is causing the real site to use so much memory. I’ve tried to optimize the database but that didn’t help. I assume something is broken, but I’ve no idea where to look.

    https://wordpress.org/plugins/query-monitor/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author John Blackbourn

    (@johnbillion)

    WordPress Core Developer

    Google tells me that the dsq_sync_forum option comes from a Disqus plugin. It looks like Disqus is having some sort of problem scheduling its syncing.

    I would try deactivating the Disqus plugin to see if the problem goes away. If so, your problem lies there.

    Thread Starter Micke123

    (@micke123)

    Thank you! Deleting Disqus didn’t help, and the dsq_sync_forum was still in the query. I did some more digging and the problem appeared to be with the cron job. I tried to delete it, only for it to immediately reappear. So I manually deleted the content of the cron option (leaving the option) and it appears to have fixed the problem. Afterwards the wanted cron jobs re-populated the table.

    I did copy the content to a text file and it was a wopping 4.5MB! For some reason the size of the table wp_options decreased by more than that.

    Thank you again!

    Hello @micke123,

    we have the same issue, here.

    I did try to DELETE manually the option_id, but records are re-populated immediately.

    Thread Starter Micke123

    (@micke123)

    Sorry @daweb this is beyond my knowledge. Think I probably just got lucky that my method worked for me.

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

The topic ‘Admin very slow, high memory use’ is closed to new replies.