Title: Large wfConfig Table Causing PHP Crash Last modified: October 5, 2018 --- # Large wfConfig Table Causing PHP Crash * Resolved [Demonslay335](https://wordpress.org/support/users/demonslay335/) * (@demonslay335) * [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/) * Wordfence Security Version 7.1.15 [Free] WordPress 4.9.8 with all plugins updated CentOS 6 running WHM/cPanel * We have an installation of WordFence that seems to be going crazy and overpopulating its config table. Eventually, it became several MB large, and caused PHP to crash due to the memory limit being surpassed. * `[26-Sep-2018 08:14:51 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /home/[redacted]/public_html/ wp-content/plugins/wordfence/lib/wfConfig.php on line 280` * While the obvious answer to fix this crashing would be to up the memory limit, it would just mask the problem. I believe 256MB is _plenty_ for most websites already (it’s fine for the other 20+ websites on this server). * When inspecting the table wp_wfConfig, it seems to have a ton of duplicate entries. I had done a complete uninstall/re-install of the plugin in order to get the site back online, and a week later it is up to 14820 rows already (it added 10 more while typing this); I cannot remember how many it was before when it crashed the site, but it was in the hundreds of thousands possibly. I’ve checked with other sites I manage, and none have more than a few hundred rows. * An example of the last 25 rows (unable to display the BLOB contents except individually thru PhpMyAdmin): * ``` name val autoload lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes totalLoginHits [BLOB - 3 B] yes totalLoginHits [BLOB - 3 B] yes totalIPsBlocked [BLOB - 3 B] yes total503s [BLOB - 3 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes totalLoginHits [BLOB - 3 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes totalLoginHits [BLOB - 3 B] yes totalIPsBlocked [BLOB - 3 B] yes total503s [BLOB - 3 B] yes total503s [BLOB - 3 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes totalLoginHits [BLOB - 3 B] yes totalIPsBlocked [BLOB - 3 B] yes total503s [BLOB - 3 B] yes total503s [BLOB - 3 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes lastBruteForceDataSendTime [BLOB - 17 B] yes ``` * Is this from the site being under attack? I haven’t received email alerts of crazy proportions, and all scans have been clean. Viewing 4 replies - 1 through 4 (of 4 total) * [wfasa](https://wordpress.org/support/users/wfasa/) * (@wfasa) * [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/#post-10760081) * Hi [@demonslay335](https://wordpress.org/support/users/demonslay335/), Sorry to hear you’re having this problem. Have you checked to make sure the database user your WordPress installation is running with has all permissions that are needed? You would be able to check this via Wordfence Tools > Diagnostics page. * Thread Starter [Demonslay335](https://wordpress.org/support/users/demonslay335/) * (@demonslay335) * [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/#post-10760355) * [@wfasa](https://wordpress.org/support/users/wfasa/) * Yep, no issues in the Diagnostics, everything has happy green checkmarks. * ``` Wordfence Config - Ability to save Wordfence settings to the database. Checking basic config reading/writing - [✓] Basic config writing Checking serialized config reading/writing - [✓] Serialized config writing MySQL Database version and privileges. Database Version - 5.5.61-cll Checking if MySQL user has DELETE privilege - OK Checking if MySQL user has INSERT privilege - OK Checking if MySQL user has UPDATE privilege - OK Checking if MySQL user has SELECT privilege - OK Checking if MySQL user has CREATE TABLE privilege - OK Checking if MySQL user has ALTER TABLE privilege - OK Checking if MySQL user has DROP privilege - OK Checking if MySQL user has TRUNCATE privilege - OK ``` * Here’s the diagnostics on the `wp_wfConfig` table. * ``` Name Comment Engine Rows Avg_row_length Data_length Index_length Auto_increment Create_time Row_format Collation Version Max_data_length Data_free Update_time Check_time Checksum Create_options wp_wfConfig MyISAM 15999 81 3205484 1024 2018-09-26 21:53:52 Dynamic utf8_general_ci 10 281474976710655 1894052 2018-10-08 14:35:38 ``` * [wfasa](https://wordpress.org/support/users/wfasa/) * (@wfasa) * [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/#post-10760638) * Thanks for checking that. I’m not quite sure how this is possible, it’s not something I recall seeing before. * The main issue obviously is that you somehow end up with duplicate rows. The rows in wfConfig are not created unless they don’t exist. For updates to options we use “ON DUPLICATE KEY UPDATE”. I’m wondering if there could be some problem with the indexes on the table but I’m not sure. * Would it be possible for you to share a dump of the wfConfig table? If you can upload it somewhere safe, you could send a link for me to download it. If so, send the email to [asa@wordfence.com](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/asa@wordfence.com?output_format=md). * If you can send a Wordfence diagnostics report to [asa@wordfence.com](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/asa@wordfence.com?output_format=md) as well that would be helpful too. You can send it from the top of the Wordfence Tools > Diagnostics page. * Thread Starter [Demonslay335](https://wordpress.org/support/users/demonslay335/) * (@demonslay335) * [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/#post-10760675) * Ah, yes, that seems to be the issue. * `No index defined!` * I’ve compared with another WordPress site’s database and confirmed `name` should be the PRIMARY KEY. Not sure how the index was not added during install of the plugin, all other WordFence tables have their indexes. * Thank you for the prompt response, this should fix the issue (I have to first consolidate the duplicate keys before MySQL will allow me to add the index). I’ll mark this as resolved and re-open it if I run into further issues. * Thanks! Viewing 4 replies - 1 through 4 (of 4 total) The topic ‘Large wfConfig Table Causing PHP Crash’ 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/) * 4 replies * 2 participants * Last reply from: [Demonslay335](https://wordpress.org/support/users/demonslay335/) * Last activity: [7 years, 8 months ago](https://wordpress.org/support/topic/large-wfconfig-table-causing-php-crash/#post-10760675) * Status: resolved