Conversation
supportHI there have had server issues with PHP processes etc thats affecting SQL. I see in this week you have had 2 updates “Various bug fixes” what exactly were they? just want to know if it was related
hey @techguysa they were frontend UI tweaks and translation related updates. We didn’t change anything in the database. What’s your server issues? Maybe I can help debug.
Oh you know… resources getting nailed busy with indexing SQL just have to do it in stages at night when traffic is super low 12 core 16gb ram Mysqltuner is suggesting increasing the innob log files from 1g to 2.8gb or something like that etc and suggsting more ram but 3 weeks ago with a 10core 12gb ram everything was fine till we got knock on synattacks and woocommerce transcient issuse (that is sold we got rid of wordfence for another WAF etc (i dont share this info publicly) but its paid and runs less resources litespeed cache crawler is off and childs droped from 35 to 5 so it doesnt eat so many cpu cores but once i got the SQL indexing sorted im checking everything else i do have about 40k plus products and about 20k of those are published i use a good few plugins that all work well with 1 plug in we made for quoted orders. (61 lines of code only) autoloads been turned off on most plugins that dont need it without breaking functionality WP cron disabled for a real cron via Cpanel Cron Jobs its optimisations im busy with but also trying to figure out which plugin is causing what exactly i can disable everything its smooth i start slowly (49 of them) then its fine but give it a few hours i do have a ton of crawlers on the site blocked bad ones though going to enable litespeed cache crawler cause ui turned him off but i want to configure it first via sitemapping got most of it to be stable with traffic so database crash isnt happening but i have to strangle it a bit I am thinknig of moving servers with 24gb ram but first i want to fix it. mysqltuner did state i need more ram but thats when tables were missing etc it was eating all 11gb ram now after about 10/11hours running its about just under 8gb ram so doing more SQL tweeks and optimisations there. however my focus will be those php proceses. I cant see why they want to HOG so much % but if i increase the child from 5 to 20 for example the % drops but they add so many workers and its taking all of them (my product imports are off i deleted those jobs to stop from failing etc or slow downs cause i supplier can be 7000 products) top – 11:38:02 up 1 day, 4:37, 1 user, load average: 16.59, 16.16, 15.96 Tasks: 272 total, 12 running, 258 sleeping, 0 stopped, 2 zombie %Cpu(s): 47.6 us, 13.6 sy, 0.4 ni, 16.7 id, 0.2 wa, 0.0 hi, 6.2 si, 15.3 st MiB Mem : 15995.5 total, 1939.5 free, 7120.8 used, 6935.1 buff/cache MiB Swap: 2048.0 total, 2016.5 free, 31.5 used. 8253.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 443398 mysql 20 0 15.2g 4.5g 30836 S 142.1 28.9 400:45.90 mysqld 445388 memcache 20 0 610412 233912 3200 S 110.6 1.4 301:32.76 memcached 375621 root 20 0 2568268 14096 8256 S 61.9 0.1 229:29.37 imunify360-unif 633250 vapeand+ 20 0 457992 221472 147148 R 51.0 1.4 0:04.54 lsphp 633217 vapeand+ 20 0 473560 237340 147384 R 47.4 1.4 0:07.33 lsphp 633285 vapeand+ 20 0 438056 201620 147212 S 45.7 1.2 0:02.54 lsphp 632752 vapeand+ 20 0 479648 243712 147512 S 44.7 1.5 0:33.89 lsphp 632905 vapeand+ 20 0 479060 242856 147228 S 43.4 1.5 0:25.07 lsphp 632984 vapeand+ 20 0 474276 239080 148408 R 42.7 1.5 0:23.27 lsphp 633274 vapeand+ 20 0 460040 223544 147240 R 39.7 1.4 0:03.40 lsphp 633226 vapeand+ 20 0 468744 231848 147148 R 37.7 1.4 0:06.77 lsphp 633213 vapeand+ 20 0 480520 241412 147148 R 35.4 1.5 0:07.15 lsphp 633305 vapeand+ 20 0 452916 213268 145964 R 34.8 1.3 0:01.05 lsphp 633308 vapeand+ 20 0 450868 210800 145900 R 33.1 1.3 0:01.00 lsphp 633309 vapeand+ 20 0 452916 212904 145900 S 31.5 1.3 0:00.95 lsphp 633324 vapeand+ 20 0 433840 189524 141404 R 17.9 1.2 0:00.54 lsphp 633325 vapeand+ 20 0 425584 169868 130012 R 12.3 1.0 0:00.37 lsphp 633326 vapeand+ 20 0 417260 152288 119200 R 7.0 0.9 0:00.21 lsphp 443752 nobody 20 0 1208428 139100 38540 S 6.3 0.8 7:43.09 litespeed 443746 nobody 20 0 1198292 129396 38348 S 4.3 0.8 7:36.11 litespeed 443745 nobody 20 0 1216596 139516 38588 S 2.0 0.9 7:47.60 litespeed 796 root 20 0 678816 36892 10220 S 0.7 0.2 13:08.02 agent360 1638 root 20 0 3239520 97952 11036 S 0.7 0.6 12:14.03 imunify-residen
It sounds like you know what you’re doing! I think looking for slow queries it the right approach. Have you installed https://wordpress.org/plugins/query-monitor/ to get some more insights? Also, you can safely deactivate Extendify for a few days and nothing should break. We don’t have any frontend dependencies your site needs (unless you started with a version from 3 years ago, then it depends).
yeah got that running the slow query makes no sense (to do wtih woocommerce but ill dig into it and find that table i swear i optimised already i use woodmart im pretty sure it functions with yours
HI I see i got a slow query from your plugin however ive been cahtting to chatGPT and i think i might not need your plugin but im not really sure the slow query is QueryCallerComponentRowsTime SELECT DISTINCT YEAR( post_date ) AS year, MONTH( post_date ) AS month FROM EdmHnkOX_posts WHERE post_type = 'attachment' ORDER BY post_date DESC wp_enqueue_media() wp-includes/media.php:4876 Extendify\Shared\Admin->loadGlobalScripts() wp-content/plugins/extendify/app/Shared/Admin.php:48 do_action('admin_enqueue_scripts') wp-includes/plugin.php:517 Plugin: extendify 58 0.0677 now i use woodmart as the theme and WPBakery to build the pages i did import the demo “hardware” and worked on those based on that demo i replaced the images etc added stuff here and there etc i dont have guntenberg installed at all. should i keep it?
That’s a built in WordPress query that we load only for admin users (with manage_options capabilities), so even if it’s slowing things down, it woulnd’t be slow for your users, only for you. However, looking inside wp_enqueue_media() I don’t see that SQL query being run. I do see it being run inside a months_dropdown() function ( source ). It could be that another plugin is adding a filter that then calls this function (potentially in a place it’s not needed). I’m not sure. The query itself is just loading attachment images though. Since you have a lot of rows in the wp_posts table (and maybe a lot of images), it’s slow. If you haven’t already, you could probably add an index on that query, which will help your site overall (not just for the Extendify plugin). ALTER TABLE EdmHnkOX_posts ADD INDEX idx_post_type_post_date (post_type, post_date); But if you’re not using features from Extendify, you can also remove it. It’s not a critical plugin unless you’re using the Library to import patterns.
hey @techguysa they were frontend UI tweaks and translation related updates. We didn’t change anything in the database. What’s your server issues? Maybe I can help debug.
Oh you know… resources getting nailed busy with indexing SQL just have to do it in stages at night when traffic is super low 12 core 16gb ram Mysqltuner is suggesting increasing the innob log files from 1g to 2.8gb or something like that etc and suggsting more ram but 3 weeks ago with a 10core 12gb ram everything was fine till we got knock on synattacks and woocommerce transcient issuse (that is sold we got rid of wordfence for another WAF etc (i dont share this info publicly) but its paid and runs less resources litespeed cache crawler is off and childs droped from 35 to 5 so it doesnt eat so many cpu cores but once i got the SQL indexing sorted im checking everything else i do have about 40k plus products and about 20k of those are published i use a good few plugins that all work well with 1 plug in we made for quoted orders. (61 lines of code only) autoloads been turned off on most plugins that dont need it without breaking functionality WP cron disabled for a real cron via Cpanel Cron Jobs its optimisations im busy with but also trying to figure out which plugin is causing what exactly i can disable everything its smooth i start slowly (49 of them) then its fine but give it a few hours i do have a ton of crawlers on the site blocked bad ones though going to enable litespeed cache crawler cause ui turned him off but i want to configure it first via sitemapping got most of it to be stable with traffic so database crash isnt happening but i have to strangle it a bit I am thinknig of moving servers with 24gb ram but first i want to fix it. mysqltuner did state i need more ram but thats when tables were missing etc it was eating all 11gb ram now after about 10/11hours running its about just under 8gb ram so doing more SQL tweeks and optimisations there. however my focus will be those php proceses. I cant see why they want to HOG so much % but if i increase the child from 5 to 20 for example the % drops but they add so many workers and its taking all of them (my product imports are off i deleted those jobs to stop from failing etc or slow downs cause i supplier can be 7000 products) top – 11:38:02 up 1 day, 4:37, 1 user, load average: 16.59, 16.16, 15.96 Tasks: 272 total, 12 running, 258 sleeping, 0 stopped, 2 zombie %Cpu(s): 47.6 us, 13.6 sy, 0.4 ni, 16.7 id, 0.2 wa, 0.0 hi, 6.2 si, 15.3 st MiB Mem : 15995.5 total, 1939.5 free, 7120.8 used, 6935.1 buff/cache MiB Swap: 2048.0 total, 2016.5 free, 31.5 used. 8253.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 443398 mysql 20 0 15.2g 4.5g 30836 S 142.1 28.9 400:45.90 mysqld 445388 memcache 20 0 610412 233912 3200 S 110.6 1.4 301:32.76 memcached 375621 root 20 0 2568268 14096 8256 S 61.9 0.1 229:29.37 imunify360-unif 633250 vapeand+ 20 0 457992 221472 147148 R 51.0 1.4 0:04.54 lsphp 633217 vapeand+ 20 0 473560 237340 147384 R 47.4 1.4 0:07.33 lsphp 633285 vapeand+ 20 0 438056 201620 147212 S 45.7 1.2 0:02.54 lsphp 632752 vapeand+ 20 0 479648 243712 147512 S 44.7 1.5 0:33.89 lsphp...
It sounds like you know what you’re doing! I think looking for slow queries it the right approach. Have you installed https://wordpress.org/plugins/query-monitor/ to get some more insights? Also, you can safely deactivate Extendify for a few days and nothing should break. We don’t have any frontend dependencies your site needs (unless you started with a version from 3 years ago, then it depends).
yeah got that running the slow query makes no sense (to do wtih woocommerce but ill dig into it and find that table i swear i optimised already i use woodmart im pretty sure it functions with yours
HI I see i got a slow query from your plugin however ive been cahtting to chatGPT and i think i might not need your plugin but im not really sure the slow query is QueryCallerComponentRowsTime SELECT DISTINCT YEAR( post_date ) AS year, MONTH( post_date ) AS month FROM EdmHnkOX_posts WHERE post_type = 'attachment' ORDER BY post_date DESC wp_enqueue_media() wp-includes/media.php:4876 Extendify\Shared\Admin->loadGlobalScripts() wp-content/plugins/extendify/app/Shared/Admin.php:48 do_action('admin_enqueue_scripts') wp-includes/plugin.php:517 Plugin: extendify 58 0.0677 now i use woodmart as the theme and WPBakery to build the pages i did import the demo “hardware” and worked on those based on that demo i replaced the images etc added stuff here and there etc i dont have guntenberg installed at all. should i keep it?
That’s a built in WordPress query that we load only for admin users (with manage_options capabilities), so even if it’s slowing things down, it woulnd’t be slow for your users, only for you. However, looking inside wp_enqueue_media() I don’t see that SQL query being run. I do see it being run inside a months_dropdown() function ( source ). It could be that another plugin is adding a filter that then calls this function (potentially in a place it’s not needed). I’m not sure. The query itself is just loading attachment images though. Since you have a lot of rows in the wp_posts table (and maybe a lot of images), it’s slow. If you haven’t already, you could probably add an index on that query, which will help your site overall (not just for the Extendify plugin). ALTER TABLE EdmHnkOX_posts ADD INDEX idx_post_type_post_date (post_type, post_date); But if you’re not using features from Extendify, you can also remove it. It’s not a critical plugin unless you’re using the Library to import patterns.