I remember a short discussion of that topic a few months ago (IIRC the
subject was "SQL_giveup error") where simultaneous scans on multiple
slaves were causing the same problem (multiple instances of the manager
fighting for tasks.db locks).
I wanted look into the topic but never found the time. Putting the
tasks.db on a ramdisk will somewhat lessen the IO problem (by tempting
fate, don't do this on a system where losing tasks.db will hurt). But
that doesn't solve the main problem at hand, just does its best to
mitigate it. I have yet to dig deeper into the sourcecode, but my best
guess is that this will always be a bottleneck caused by how sqlite does
it's database locking.
Using a database like PostgreSQL with table or row locking would
probably go a good way to solving the problem in environments that are
prone to this problem (I saw that it is being worked on, but to my
knowledge it isn't finished yet).
On 8/13/2014 6:26 PM, luciano fain wrote:
Dear all, any of you knows why when you run 7 / 8 task in paralell
each one with one host, the gsad intrface stucks?
I can see the key problem in tasks.db access, do you have any
suggestion to execute 7 or more tasks in paralell with good response
of tasks.db?
I know the same sqlite db is used by scanner and gsad gr.interface.
Any tip will be appreciated.
Regards.
_______________________________________________
Openvas-discuss mailing list
[email protected]
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Openvas-discuss mailing list
[email protected]
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
