[#13502] - Implemented pausing mechanisms into cli/finder_indexer.php.
- Fixed in Code Base
- 17 Sep 2019
- Medium
- Build: staging
- # 13502
- Diff
- frankmayer:cli-finder-indexer
- Success Hound No violations found. Woof! Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Pending JTracker/HumanTestResults Human Test Results: 1 Successful 0 Failed. Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
New issue:
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.
Summary of Changes
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.
Testing Instructions
Note:
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.
- Do not apply the patch, yet. Run the command with the
--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.
- Now apply the patch and run the same command again (with the
--purgeargument).
You should notice pauses being inserted between each batch, according to the time the finished batch took to process. The division to determine the pause length is rounded[processed-batch-running-time / divisor]. The default divisor is 5.
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
--purgeargument), and add--pause=division --divisor=3
Notice that the pauses are correctly calculated using the new divisor. -
Now run the same command again (with the
--purgeargument), and replace the--pause=division --divisor=3with--pause=3
Notice that the pauses are constantly three seconds long.
Documentation Changes Required
Yes. The new arguments should be included in the documentation here: https://docs.joomla.org/Setting_up_automatic_Smart_Search_indexing
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | CLI Language & Strings |
| Labels |
Added:
?
?
|
||
| Title |
|
||||||
| Title |
|
||||||
I have tested this item
Thank you!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13502.
| Category | CLI Language & Strings | ⇒ | CLI |
| Title |
|
||||||
| Category | CLI | ⇒ | CLI Language & Strings |
I think conflicts need to be solved first.
true. @frankmayer can you please resolve conflicting files?
| Status | Pending | ⇒ | Information Required |
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.
| Labels |
Removed:
J3 Issue
|
||
@franz-wohlkoenig resolved conflicts.
@SharkyKZ want to give it a try?
Thanks
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13502.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13502.
| Status | Information Required | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13502.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-09-17 16:13:17 |
| Closed_By | ⇒ | HLeithner | |
| Labels |
Added:
?
|
||
Thanks for this PR. The reason I'm merging this into 3.9 series is to protect servers overloading.
I have tested this item✅ successfully on b7134e2
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13502.