walkingpaper

@chrisathook commenting here to follow this thread. For the first time ever I’m having server load issues because of MySQL queries from TEC.

Thanks.

Hi @erania-pinnera — thanks for following up.

You must be seeing the 503 because of a firewall rule. I don’t want to disable the firewall — though I suppose I could whitelist your IP if you can send it. Otherwise, the site will have to remain categorized this way and we’ll move on from Jetpack.

(The site isn’t selling anything or asking for donations — it is a public library website._

Bumping this.

@trust17 — did you get any resolution on this I have the same problem.

Thanks!

I can confirm the same problem and solution as @ltad.

Disabling The Events Calendar on the root site lets me create new sites.

There’s a related thread on the support forum here: https://www.ads-software.com/support/topic/bug-with-multisite-incompat-with-latest-point-release-breaks-new-site-creation/

I am planning on emailing them too.

Just chiming in to say that I cannot create new sites via multisite with the plugin network enabled — or enabled on the root site — either.

If I network deactivate, and deactivate the plugin on the root site, I can create new sites. Hope this helps someone!

@itad — wow, I have that plugin network enabled too. I will disable and enable individually and report back.

Thank you SO MUCH for the info.

@ltad — I am having the exact same issue. So happy to find your post after a day of messing around with this.

Have you made any progress?

Best of luck migrating that data out of Ai1. I wish I had the time to do that!

I’m curious what your developer said about those fixes. Just want to make sure I didn’t miss something important.

Just popping in to say I had / have the same issue. Like you I manually uploaded the .min to fix the error.

This sounds similar to a problem some folks and I were having a while back.

Find what worked for us here:

https://www.ads-software.com/support/topic/resource-limit-reached-error-due-to-targetted-attacks/#post-13122579

Not sure if there’s been a fix from Timely for this.

I haven’t had any server load issues from these bots since I implemented the above .htaccess rules ~ 9 months ago.

Wordfence reports that the last time those User Agents accessed the site was in October 2019, which tracks with that.

@elliottbenzle still no real fix for me. The following in my .htaccess is helping with server load, but I’d prefer to have a real fix from time.ly

<RequireAll>
Require all granted
Require not ip 159.138
Require not ip 117.78
Require not ip 114.215
Require not ip 188.166
Require not ip 193.106
</RequireAll>

BrowserMatchNoCase "LieBaoFast" bad_bot
BrowserMatchNoCase "Mb2345Browser" bad_bot
BrowserMatchNoCase "zh-CN" bad_bot
BrowserMatchNoCase "MicroMessenger" bad_bot
BrowserMatchNoCase "zh_CN" bad_bot
BrowserMatchNoCase "Kinza" bad_bot
BrowserMatchNoCase "Bytespider" bad_bot
BrowserMatchNoCase "Baiduspider" bad_bot
BrowserMatchNoCase "Sogou" bad_bot
BrowserMatchNoCase "undefined" bad_bot
Deny from env=bad_bot

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.(Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|Bytespider|Baiduspider|Sogou).$ [NC]
RewriteRule .* - [F,L]

I’m in the same situation. Calendar URLs are getting absolutely hammered by bad bots from China and Singapore (that ignore robots.txt).

I’ve blocked User-agents, IP ranges, etc…with Wordfence and .htaccess and the server is still suffering badly.

159.138.155.25 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/cat_ids%7E23/tag_ids%7E284,61,310,146/request_format%7Ehtml/ HTTP/1.0” 403 859
159.138.154.104 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1567396800/cat_ids%7E23/tag_ids%7E280,227,114,197,199/request_format%7Ehtml HTTP/1.0” 403 859
119.179.42.178 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/cat_ids%7E27/tag_ids%7E94,147,29,89,215/request_format%7Ehtml/ HTTP/1.0” 301 523
159.138.128.246 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/cat_ids%7E23,24/tag_ids%7E47,139,112,228/request_format%7Ehtml/ HTTP/1.0” 403 859
159.138.152.95 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action~agenda/time_limit~1562558400/tag_ids~307,221,298,250,263,260,283/request_format~html/ HTTP/1.0” 403 859
159.138.157.35 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/tag_ids%7E307,36,133,314,31,177,264/request_format%7Ehtml/ HTTP/1.0” 301 521
159.138.150.255 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/tag_ids%7E307,196,187,198,147,315/request_format%7Ehtml/ HTTP/1.0” 301 519
159.138.155.229 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action~oneday/exact_date~1568174400/tag_ids~284,135,296,242/request_format~html/ HTTP/1.0” 403 859
159.138.158.84 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action%7Eagenda/time_limit%7E1562558400/cat_ids%7E23,285/tag_ids%7E206,178,253,281/request_format%7Ehtml/ HTTP/1.0” 403 859
159.138.156.170 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action~agenda/time_limit~1562558400/tag_ids~94,111,34,220,217,226,238/request_format~html/ HTTP/1.0” 403 859
159.138.154.63 – – [01/Oct/2019:17:11:35 +0000] “GET /calendar/action~agenda/time_limit~1562558400/cat_ids~50/tag_ids~307,268,202,257,61/request_format~html/ HTTP/1.0” 403 859

@dgfrench –

We ended up writing the cache to RAM and creating a cron job to empty it regularly. This is still causing some issues with CSS occasionally not loading on the calendar, so still fine tuning it.

That being said, the big cache directory, we think, was a conflict between the calendar plugin and this plugin: https://www.ads-software.com/plugins/redis-cache/

Hope this helps.