Title: wordfence_syncAttackData creates high load Last modified: February 26, 2021 --- # wordfence_syncAttackData creates high load * Resolved [devcri](https://wordpress.org/support/users/devcri/) * (@devcri) * [5 years, 3 months ago](https://wordpress.org/support/topic/wordfence_syncattackdata-creates-high-load/) * Hi WordFence-Team, * today I noticed a very high load on my webserver. The load was at about 30 and slowing down the server. Now it is back to normal at about 0.1 – 0.3. * While scaning through the nginx logs I noticed that today the most requests came from my own servers ip adress: xxx@xxx:/var/log/nginx# cat access_xxx.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head 3635 xxx.xxx.xxx.xxx (my own server ip adress) * Looking at these requests I noticed that they have this pattern: xxx.xxx.xxx. xxx – – [26/Feb/2021:20:09:32 +0100] “POST /?wordfence_syncAttackData=1614366572.0638 HTTP/1.1” 200 31 “[https://mydomain.tld/?wordfence_syncAttackData=1614366572.0638”](https://mydomain.tld/?wordfence_syncAttackData=1614366572.0638”);“ WordPress/5.6.2; [https://mydomain.tld”](https://mydomain.tld”); * Than I checked how many requests of the 3635 requests included ‘wordfence_syncAttackData’ xxx@xxx:/var/log/nginx# cat access_xxx.log | grep ‘xxx.xxx.xxx.xxx’ | grep ‘wordfence_syncAttackData’ | wc -l 2214 * Overall there were 2214 requests out of 3635 requests that included ‘wordfence_syncAttackData’. * I have seen other users report the same issue: [https://wordpress.org/support/topic/wordfence_syncattackdata-4/](https://wordpress.org/support/topic/wordfence_syncattackdata-4/) * The suggestions for this user was to use InnoDB, but I am already using InnoDB. * The high load stop by itself without restarting or blocking anything. I just wanted to let you know. Maybe there is a bigger problem in your plugin or a new attack aiming at sites that use the WordFence plugin. * Hope this helps. Best regards Viewing 3 replies - 1 through 3 (of 3 total) * [Gwyneth Llewelyn](https://wordpress.org/support/users/gwynethllewelyn/) * (@gwynethllewelyn) * [5 years, 3 months ago](https://wordpress.org/support/topic/wordfence_syncattackdata-creates-high-load/#post-14108765) * My own server, running about 20 installations of WordFence, has roughly logged 750+ `wordfence_syncAttackData` requests (out of 250K+) in the past 24 hours. I consider that a ‘slow day’ 🙂 * I have no idea how much is too much, of course, but I’d say that having ⅔ of _all_ requests being flagged as `wordfence_syncAttackData` is way, way too much, and clearly a sign that there is some sort of deliberate attack going on. * BTW, [as reported elsewhere](https://wordpress.org/support/topic/wordfence_syncattackdata-3/#post-13107218), those calls including `wordfence_syncAttackData` (which come from your own server talking to itself) are simply the mechanism that Wordfence uses to push data into the database. In other words, on the lines _before_ each `wordfence_syncAttackData` request, you _might_ find the real culprit — before Wordfence detects the (potential) attack and logs it to the database. As that link I’ve posted suggests, you can try to change your Live Traffic settings to ‘Security Only’ — it makes an insane difference! In fact, the concept around Live Traffic is a cute nicety that will almost never be deployed on a _real_ setup, especially one that _is_ being attacked— because it’ll basically kill your database, as Wordfence tries to _write each access_ to the database server — thus magnifying the attack a thousandfold or more, since `nginx` can easily deal with _several orders of magnitude_ of accesses than MySQL. * In fact, one personal peeve I have with the Wordfence development team is the level of aggressivity they place on the database server. I use `nginx` as well, and I can say with a reasonable degree of confidence that _most_ of those 250K + requests do _not_ hit the database at all — except if Wordfence, for some reason, needs to log something about any one of those requests (in my case, as said, it just felt the ‘need’ to log ‘only’ 750 or so requests… which is nothing). I’ve started a few threads on [this subject](https://wordpress.org/support/topic/still-having-slow-queries-on-wfblockallblocks-mysql-dies/) but, unfortunately, I was not quick enough to answer those threads before they were closed… 🙂 * I hoped to have some sort of file-based logging mechanism as an option to the constant hammering on the database, but, alas, I learned that Wordfence really, really needs all those logs at the database level to be able to process them fully. It’s either that or having _no_ security whatsoever. * As for performance increases at the database engine level… MariaDB, the MySQL fork, includes a few extra database engines. I have had reasonable success in using the **Aria** engine for tables having lots of writes (and lots of accesses in general). The Aria engine is conceptually similar to the old MyISAM engine, in the sense that it’s super-fast (very slightly faster than MyISAM, in fact) and handles big loads well — at the cost of _not_ being transactional (as InnoDB is). However, it includes journaling and data recovery (unlike MyISAM) so that it resists quite well to database or even server crashes. Being a simpler engine, it has fewer configuration variables, so it is not so finicky to fiddle with as InnoDB — which has an endless supply of configuration options. It might be an option for you — because of the unknown future of Oracle’s MySQL, MariaDB has been packaged with the most recent Debian/Ubuntu distros (as well as a few others, of course) as the ‘default’ SQL database engine. It’s 99.9999% compatible with MySQL and works as a drop-in replacement — so if you have a choice there, it may be a good option. If you have to stick with MySQL, then InnoDB is still the best overall engine (that’s why it’s the default one!). * On the other hand, if you have _lots_ of memory to spare, I guess that you could put the Wordfence log tables in the Memory engine… that would certainly increase performance! * Also, unless you _really_ need the massive amount of logs produced by Wordfence, you can decrease the number of lines that get written to the log by changing the `Amount of Live Traffic data to store (number of rows)` to 100, and the ` Maximum days to keep Live Traffic data` to 5. I actually use even less than that. * Anyway, to resume: 1. Those `wordfence_syncAttackData` apparently coming from your own server are just the mechanism that Wordfence uses to push data into the database; 2. Having two-thirds of your logs with `wordfence_syncAttackData` is not normal IMHO; 3. You should check if you have Live Traffic turned on; while useful, it’s an almost- certain database killer; switch to ‘Security Only’ instead and see if it improves things; 4. Reduce `Amount of Live Traffic data to store (number of rows)` to 100, and the` Maximum days to keep Live Traffic data` to 5 or even less; 5. If you’re using MariaDB, you might get some performance increase (or at least avoid the highest traffic peaks) by switching some of the most intensely-used tables to the Aria engine. * Good luck… * Thread Starter [devcri](https://wordpress.org/support/users/devcri/) * (@devcri) * [5 years, 3 months ago](https://wordpress.org/support/topic/wordfence_syncattackdata-creates-high-load/#post-14109655) * Thank you for your feedback and suggestions, Gwyneth. Let me add some more information to my previous post. * 1. `wordfence_syncAttackData` I think you are right. I notice in the log files, that just before or very close to the lines containg `wordfence_syncAttackData` I get requests like this: `POST /xmlrpc.php HTTP/1.1` and `POST /wp-login.php HTTP/1.1`. IP Adresses for those requests are changing. Interestingly I also see requests close to that line containing `wp-cron` like: `"POST /wp-cron.php? doing_wp_cron=1614403548.1214759349822998046875 HTTP/1.1"` followed by: `"POST/? wordfence_syncAttackData=1614403547.8128 HTTP/1.1"` Notice how similar the number in those two requests are. * 2. Just to clarify: the `wordfence_syncAttackData` lines are not 2/3 of my log, but 2/3 of the lines coming from my own IP adress. The log contains much more data. * 3. Live Traffic ‘All Traffic’ wasn’t turned on. Just ‘Security Only’. * 4. Reduce Amount of Live Traffic Good idea. I changed that from 2000 rows and 30 days to 100 and 5 as you suggested. * 5. MariaDB I will be switching to a new server soon and I already planed to switch to MariaDB anyways. * Thanks again for your suggestions. - This reply was modified 5 years, 3 months ago by [devcri](https://wordpress.org/support/users/devcri/). * Plugin Support [WFAdam](https://wordpress.org/support/users/wfadam/) * (@wfadam) * [5 years, 3 months ago](https://wordpress.org/support/topic/wordfence_syncattackdata-creates-high-load/#post-14113431) * Hello [@devcri](https://wordpress.org/support/users/devcri/) and thanks for reaching out! * [@gwynethllewelyn](https://wordpress.org/support/users/gwynethllewelyn/) Really hit the nail on the head. Excellent suggestions! * As mentioned, wordfence_syncAttackData is usually just a sting added to any sort of visit to your site. Live Traffic generally will generate these. * Thanks again! Viewing 3 replies - 1 through 3 (of 3 total) The topic ‘wordfence_syncAttackData creates high load’ is closed to new replies. * ![](https://ps.w.org/wordfence/assets/icon.svg?rev=2070865) * [Wordfence Security - Firewall, Malware Scan, and Login Security](https://wordpress.org/plugins/wordfence/) * [Frequently Asked Questions](https://wordpress.org/plugins/wordfence/#faq) * [Support Threads](https://wordpress.org/support/plugin/wordfence/) * [Active Topics](https://wordpress.org/support/plugin/wordfence/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wordfence/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wordfence/reviews/) * 3 replies * 3 participants * Last reply from: [WFAdam](https://wordpress.org/support/users/wfadam/) * Last activity: [5 years, 3 months ago](https://wordpress.org/support/topic/wordfence_syncattackdata-creates-high-load/#post-14113431) * Status: resolved