examsdaily

We resolved the issue a month ago.

Turns out the add filter query was overridden by a plugin for mobile theme.

And the nasty effects of database clogging was mitigated by adding the filter
as a custom plugin ( previously we pasted the same to function.php – effective only for desktop vies )

Thanks for helping us out.

Also let me make this an opportunity to request a tick-box within plugin
itself in future releases, that gives an option to exclude the tables from search queries. In our case,our tb-tables scaled enormously to some 10000 tables in tablepress and a single search query had the power to derail the database for couple of minutes.

Thanks, for your interest in this thread,

From the query log monitoring, we could still see some queries run resembling the following. Hence at time posts unnecessary load on the database server.

Unfortunate that we are still looking for the cause and caller, perhaps attributed to the search function.

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND (((wp_posts.post_title LIKE '%Ib%') OR (wp_posts.post_excerpt LIKE '%Ib%') OR (wp_posts.post_content LIKE '%Ib%') OR (wp_posts.post_content REGEXP '\\[table id=(["\']?)(38|81|103|107|108|117|126|137|143|155|159|161|162|167|173|174|184|189|192|220|223|228|240|241|245|250|379|398|417|422|433|440|443|444|445|453|464|465|469|472|473|474|475|476|477|485|495|496|502|503|506|508|509|515|518|531|584|586|592|593|594|596|600|603|606|607|610|612|627|628|644|645|655|656|660|668|673|674|685|688|696|698|699|710|724|726|746|774|779|782|783|784|788|789|790|791|792|794|797|798|799|815|822|825|827|836|839|840|841|845|850|855|864|870|871|877|879|885|890|892|895|897|898|904|906|914|917|918|919|936|952|961|962|968|975|1003|1023|1029|1037|1045|1049|1057|1128|1146|1197|1212|1255|1256|1257|1262|1264|1281|1289|1294|1296|1297|1316|1317|1330|1341|1348|1398|1424|1439|1445|1450|1451|1452|1455|1479|1489|1500|1522|1530|1533|1553|1565|1627|1641|1647|1670|1681|1698|1700|17 

— query goes on

Thanks for the quick reply Tobias

But we already have that filter in place;
yet not uncommonly we could see that long query clogging our database.

If you have any suggestions,
Please do help us.

Thanks for the suggestion @jnashhawkins ..
Hyper db is a valid option to consider.
But provided the plugin-version is outdated by a year and
with less than 10 active installation, is that worthy of risking a production
server. Or if there exists any descriptive cases of HyperDB installation and tutorials please do refer to us.

The concept of HyperDB seem to be exactly the option we might have been looking,
unluckily though it is never detailed by codex-wordpress. Our problem is more prevalent and exactly occurs during post editing and publishing.
One more important thing is that we have been into wordpress and over the year
we scaled massively, though we do have a software team, they are’nt much experienced in this PHP stuff either.
TL;DR
small team, simple solution, self manageable option
from where we come from, this case is either highly unlikely or excessively pricey remedy.

Though we are trying to be stable as long, also that now we got almost 1000 active connections and about 10000 posts, half a million attachments.
And the problems are increasingly unmanageable. But we look forward to have any sort of web management stubbornly within our company premises(rather than outsourcing) just as any sensible indie company would do. We look forward to the wordpress community for support.

One thing we could infer from the problem is that there was excessive memory leak
that peaks our max RAM value in apache file server. Causing the server to misbehave and shut down and open up infinite connection to DB server. During the times we don’t edit posts we are fine as heaven would be.
Also the question whether memory leak can be attributed to outdated plugins and themes (having depreciation error php7.2 as against 5.6) ?
PS: we upgraded to a even more powerful DB server and is highly capable this time

We do appreciate your acknowledgement

Thanks and regards