Jobs, locking and doing large updates
Wednesday, 18 October 2017 · 3 messages
OS
Omar Siam18 Oct 2017 17:14 #
Hi list!
I was experimenting with the jobs module for the last weeks to speed up updates and to make them fit into less than 6 GB of memory. It does not work the way I expected.
* Updating jobs don't seem to run in parallel even if they don't work with and lock the same database. Or do they start much later than I expected?
* It seems to me there is an upper limit of jobs that can be queued (about 100?). I automatically started all of the update jobs but some updates did not run.
The upside is: I can run my updates with just about 1 GB of memory which is much better for me.
I work with dictionary like XML documents. They look like
<root>
<entry>Contents with further tags</entry>
<entry>Contents with further tags</entry>
<entry>Contents with further tags</entry>... a few thousand more ...
<entry>Contents with further tags</entry>
<entry>Contents with further tags</entry>
</root>I add or change larger parts of them and I also need to keep track of changes. So in a separate database there are old versions of entries with time stamps (@dt) like
<hist>
<entry dt="">Contents with further tags</entry>
<entrydt="">Contents with further tags</entry>
<entrydt="">Contents with further tags</entry>... a few thousand more ...
<entrydt="">Contents with further tags</entry>
<entrydt="">Contents with further tags</entry>
</hist>I tried to do everything at once and when I need to update most of my entries (about 30000) I exhaust my memory.
So I use the jobs module to do this 100 at a time so the updates list does not grow beyond any reasonable size. Having those 100 as one transaction is good enough for my needs.
Then I thought maybe I should use jobs to seprate the two tasks. One async job saves a memory (update) copy of the old entry, the other writes the new one. After some transformations to my XQuery BaseX told me they don't lock the same database or global.
I expected the jobs running on different databases to work in parallel. They don't. I don't quite understand why.
Also I have a much larger dataset split into a number of databases where it would be quite useful to execute updates in parallel.
Am I missing something? Is this perhaps the wrong way to tackle this scaling problem?
Best regards
Omar Siam
CG
Christian Grün18 Oct 2017 17:19 #
Hi Omar,
Beforehand: You mentioned that your RESTXQ always cause global locks. Do you have an example for that (see my last mail)?
Quoted text · Omar Siam · 2 lines
> * Updating jobs don't seem to run in parallel even if they don't work with > and lock the same database. Or do they start much later than I expected?
It should be possible indeed to run updating jobs in parallel. An example would be welcome.
Quoted text · Omar Siam · 2 lines
> * It seems to me there is an upper limit of jobs that can be queued (about > 100?).
There is actually no limit; I have successfully queued more than 10.000 jobs in the past.
Quoted text · Omar Siam · 2 lines
> Is this perhaps the wrong way to tackle this scaling > problem?
Concurrent updates can slow down execution a lot (because of random IO access patterns). However, from a scalability point of view, it can be the right way to go.
Cheers,
Christian
OS
Omar Siam18 Oct 2017 17:23 #
Quoted text · Christian Grün · 7 lines
Am 18.10.2017 um 17:19 schrieb Christian Grün: > Hi Omar, > > Beforehand: You mentioned that your RESTXQ always cause global locks. > Do you have an example for that (see my last mail)? > >
Sorry, no. While running that large update yesterday I thought I saw someone running a RESTXQ call without
xquery:eval which was not processed because of the update in progress. But I could not reproduce it. I'll keep an eye on it but perhaps I just did not see the xquery:eval.Written for BaseX 8.6. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery