User tests: Successful: Unsuccessful:
With thousands of articles or K2 items with lots of different text each, the server might become unresponsive, mostly as a result of a lot of processing and IO/WAIT.
This patch implements a pausing mechanism that pauses for a defined or dynamically adjusted amount of time between batches, therefore giving the server a little time to catch up.
For all of the tests, you may break the processing, at any point, after the findings are confirmed. No need to run them completely on very large sets of data.
--purgeparameter to also clean up the database.
Note: You might or might not notice (on huge number of articles with a lot of different text) that the machine(server) might get unresponsive.
Even if you don't notice that, you will notice that the apache/php- and mysql-processes are each constantly fully consuming a CPU core. Which depending on the cores available (and the settings of mysql in core usage) might translate to 50% on a dual core, 25% on a quad core or 12,5% on an octa-core processor. While this alone might not be an issue, it does add up the the problem at hand.
You also might or might not notice (depending on the storage subsystem [hdd, ssd or hybrid]) that there is a lot of IO/WAIT during the task. It gets worse, if it is a very long running task. I have seen this resulting in an unresponsive site, during indexing. Where unresponsive can mean that the response could take from 5-10 seconds to a lot more, or a complete timeout.
You should also notice that the site/admin interface is now a lot more responsive, as the machine has less IO/WAITS and less constantly fully consuming of CPU cores.
Now run the same command again (with the
--purge argument), and add
Notice that the pauses are correctly calculated using the new divisor.
Now run the same command again (with the
--purge argument), and replace the
--pause=division --divisor=3 with
Notice that the pauses are constantly three seconds long.
Yes. The new arguments should be included in the documentation here: https://docs.joomla.org/Setting_up_automatic_Smart_Search_indexing
|Category||⇒||CLI Language & Strings|
|Category||CLI Language & Strings||⇒||CLI|
|Category||CLI||⇒||CLI Language & Strings|
It's fixing a bug
the server might become unresponsive, mostly as a result of a lot of processing and IO/WAIT.
you can reduce the load of the server if you use ionice and nice to reduce the priority of the process.
Wow... two and a half years later...
@HLeithner yes, one could do that, too.
However, this PR gives the user more control than just setting a priority on the whole process and/or its IO.
Also, I am not sure if nice and ionice would indeed be much help, as the IO-heavy process(es) would be the one(s) of the database server, not the script itself.
And the issue would be with the massive read/writes of the database server for the script, which could stress the server and under certain loads making it not able to actually serve content in parallel to running the script, as I wrote in the PR-description. This PR introduces user-defined pauses to the process, so that whatever medium is used for the db, can catch up and also serve other purposes in between.
@franz-wohlkoenig should I go on and fix the conflicts, then?
Wow... two and a half years later... smile
it takes time if you have less People volunteering.
@franz-wohlkoenig I know, be sure there was no pun intended. I just noticed how long ago I created the PR
should I go on and fix the conflicts, then?
If you fix the Conflicts @SharkyKZ can take a look. So "Yes".
Ok, will do. Thanks
Thank you for this feature. I do consider it a new feature and not just a bugfix, and thus I would recommend to add this to 4.0 instead of 3.x. I would actually be interested if this issue persists with the new DB structure in 4.0.
And yes, some things take a VERY long time. sigh
@Hackwar Yes, it can be seen both ways. But it fixes a problem that is happening on the 3.x version. And since people will be on that version for some time to come, we might as well provide a better experience.
As for 4.0, I have not tested, and unfortunately I didn't have any time to check out all the great stuff you people have done with the new version. But if we have this on 3.x it shouldn't be too much of an effort, if needed, to port it to 4.0.
|Status||Information Required||⇒||Ready to Commit|
|Status||Ready to Commit||⇒||Fixed in Code Base|
|Closed_Date||0000-00-00 00:00:00||⇒||2019-09-17 16:13:17|
Thanks for this PR. The reason I'm merging this into 3.9 series is to protect servers overloading.