Cannot deactivate Jetpack

There is some more info in this thread: https://www.ads-software.com/support/topic/server-keeps-crashing-cannot-determine-the-cause

I’m sorry to hear you’ve run into issues.

Let’s try to address these issues one by one:

I have had problems in the past 100% on every WordPress installation with the sites being crashed via brute force hacking attempts to /xmlrpc.php I have had to completely deny access to that even though it screws up jetpack because I have not been able to get Order Allow,Deny to work. It either causes 520’s to all URLs across the whole server or it reports “order not allowed here” in the error log and it doesn’t work.

Brute Force attacks again XML-RPC are definitely a known issue for many WordPress users. However, if you’re using the right tools, you can prevent such issues.

1. I’d recommend installing this plugin first, as a lot of attacks still use the pingback XML-RPC method.
   https://www.ads-software.com/plugins/disable-xml-rpc-pingback/
2. Once you’ve done so, and since you’re already using CloudFlare, make sure it’s configured to protect your site. If you’ve configured the service and the plugin properly, most brute force attacks should get blocked before to even reach your server. You’ll especially want to look under the “Firewall” menu:
   https://i.wpne.ws/eOWg
   A “Medium” security setting usually blocks most offenders, but you could set that up to “High” if you wanted. It is a great way to protect your site without blocking services like IFTTT, Jetpack, or the mobile apps. I haven’t personally tested with IFTTT, but I can confirm that you can use the mobile apps and Jetpack with the “High” security setting.
3. If Jetpack is enabled, I’d highly recommend turning on the Protect module. It protects your XML-RPC file as well.

Now, all of that isn’t very useful if your site is down. Let’s look at your other issues.

When I try to deactivate jetpack I just get a blank white screen.

That’s annoying, but you should be able to find out more by looking at your server’s PHP error logs around the time when this happened. Blank white screens , aka White Screens of Deaths are often PHP Fatal errors, that would show up in your PHP error logs. Once we know more about the error, we should be able to get this fixed.

It might also be worth going through the steps described here:
https://jetpack.me/support/getting-started-with-jetpack/configure-jetpack-cloudflare/

If the blank screen is caused by a caching problem, excluding wp-admin from your CloudFlare settings could help.

last month my server started hitting top loads of 25+ and all requests would time out or generate 520 errors.
[…]
when I force disabled jetpack the loads, while not as low as I would expect, are dramatically reduced.

That’s definitely a problem, but unfortunately the 520 errors don’t tell us much about the problem. As Joe mentioned in the other thread, something seems up with your server configuration, as if memory usage climbs on a WordPress site, it should only go up until the limit set by WordPress. The defaults are 40M for single sites, and 64M for multisite installations:
https://core.trac.www.ads-software.com/browser/tags/4.4.1/src/wp-includes/default-constants.php#L20

Unless you’ve changed those values in your site’s wp-config.php file, your site should throw errors as soon as memory reaches those values, but it shouldn’t affect your server.

That said, Jetpack itself shouldn’t cause such high memory usage. I use it on many sites and test sites, and never ran into such issues.

I’d like to come back to that 520 error, though. Do you experience the error on your own server, or do you get it from CloudFlare? If it comes from CloudFlare, what happens when you pause CloudFlare to bypass it and query your server directly? Do you get an error there? If so, what kind of error, and what do you see in your logs?

Hi Jeremy,

Thanks. Great info here. Let me go through all of this and gather the data and get back to you.

Thanks!

Oh no… I just typed out a huge reply to this and lost it.

1. OK installed that, thanks.

2. Very familiar with CloudFlare and have it properly configured.

3. Didn’t nkow that, thanks, will do.

4. Deactivating Jetpack and the white screen of death: There is nothing in my php error log, also not in MySQL or Apache.

5. 520 errors were through CloudFlare. If I can create them again and see them without CloudFlare I’ll report back.

6. The memory limit is not defined in wp-config.php or wp-settings.php – should I add it or does it default to 40M anyway?

I will add some more in a bit.

So some more details…

As mentioned disabling Jetpack seems to make the problem less severe (it’s the only plugin that has a marked effect on performance) but it certainly doesn’t fix it.

I’ve tried absolutely everything I can think of and not only that but every piece of advice I could get from hosting providers, friends, forums, etc. No dice. I have tried the site now on four different servers so I think it is something in the WordPress code but this seems ridiculous because the only changes I’ve made are: 1) Add articles, 2) Plugin updates as they become available, 3) WordPress core updates as they become available. The problems appeared on or about Dec 20.

More details to come.

OK and now here are all things I’ve done so far to troubleshoot.

1) Cloned my server to rule out a hardware problem. No improvement.

2) Took an image of another server running a WordPress site with most of the same plugins and just a different theme and installed this problem site on it. No improvement. Among other things the purpose here was to rule out that I didn’t screw something up fiddling around with Apache and MySQL tuning trying to fix the problem.

3) Tried managed WordPress hosting at Flywheel. They are working on it. They made the following suggestions which did not help at all.

A) Install “Delete Expired Transients” plugin and delete expired transients. (Note I did not do “all transients — use with caution! because I don’t really understand what this does)

B) Created an index over that table [wp_options I think] for the “autoload” data which will help speed up that query but doesn’t fully solve the issue if transients aren’t being removed properly.

C) Behind the scenes things that are totally opaque to me but they mentioned “bumping performance settings” and “tuning things”.

The only difference with Flywheel is that the site seems to perform acceptably with CloudFlare enabled whereas CloudFlare could not save my server but I am not sure that would hold with a traffic spike. Without CloudFlare the Flywheel installation is terrible too. I get page load times as long as 8 or 9 seconds. The admin panel is almost unsuable. Today I have not been able to connect Jetpack to WordPress.com due to a 15,000 milisecond time out limitation by Flywheel.

4) I installed a query monitor and while the MySQL performance certainly could be better it does not appear to be the main bottleneck right now.

As I continue to test and tune on my own server configuration I get results like this in the admin panel:

Page generation time: 3.6608 12.2% of 30s limit

Peak memory usage: 104,416 kB 39.8% of 262,144 kB limit

Database Query time: 0.0179

Database Queries: SELECT: 23 SHOW: 1 DELETE: 2

And I see things like this on the front page:

Page generation time: 3.4225 11.4% of 30s

Memory usage 102,837 kB 19.6% of 524,288 kB limit

Query time: 0.1003

Database Query Time: SELECT: 55 SHOW: 1 UPDATE: 1

On the front end I see the page generation time going through the roof sometimes though. It ranges from 3-12 seconds. The rest of the stuff is relatively consistent whether I’m looking at the front end or the admin panel. And this is just me as a single client browsing on my test server – the live site is running off Flywheel now. Sometimes just reloading the home page once pushes the load up over 1! I’ll see 3-4 apache processes popup taking a combined 90-100% of the CPU and they remain for a second or a two and then disappear. Of course with just a couple more clients this would bog down completely very fast.

The memory usage seems fine (although again this is with only one client testing) but the CPU is through the roof.

Do you have any other ideas for me? I would really like to solve this.

Thanks.

5. 520 errors were through CloudFlare. If I can create them again and see them without CloudFlare I’ll report back.

Excellent. 520 errors don’t tell us much, so as recommended by CloudFlare it might be best if you run tests against your own server first, to find out the root of the problem, before to turn on CloudFlare:
https://support.cloudflare.com/hc/en-us/articles/200171936-Error-520-Web-server-is-returning-an-unknown-error

Luckily, you should be able to do just that using your test server.

6. The memory limit is not defined in wp-config.php or wp-settings.php – should I add it or does it default to 40M anyway?

It defaults to 40M unless you don’t have 40M available on the server. However, looking at your last post, it doesn’t seem like memory is the issue here.

A) Install “Delete Expired Transients” plugin and delete expired transients. (Note I did not do “all transients — use with caution! because I don’t really understand what this does)

Could you give that a try on your test server? Deleting all transients shouldn’t cause any more trouble than you already have. You will most likey notice a bump as transients get set again, but at least you’ll start with fresh, non-cached data.

Monarch Plugin (Share On Theme123.Net)

This got me curious, as the Monarch plugin was originally developed by Elegant Themes:
https://www.elegantthemes.com/plugins/monarch/

Do you use a forked version of the plugin? If so, I’d recommend using the original instead. While it is a paid plugin, you’ll be able to trust the authors of that plugin. I’m not familiar with Theme123.Net, but a quick look at the site shows that they’re redistributing paid plugins and themes. What we don’t know, however, is what they add to the plugins before to redistribute, and what that plugin may have added to your installation (backdoors, extra scripts, changes to other plugins or your theme, …). I’d strongly recommend against using plugins and themes from such sources.

It might be best to deactivate and delete that plugin, and then start with a fresh installation of WordPress, where you’ll import your existing content with WordPress’ built-in importer under Tools > Import. Once you’ve done, you can download and install each one of your plugins again. It’s best not to copy them from your old site, but to download and install them from scratch, to be sure you’ll start with a fresh installation.

Let me know how it goes.