There are various cases where we observe crons which systematically face a CPU / memory limit. In a setup where a single worker cron is launched, a failing cron will prevent subsequent crons to run. This happens because the limits are evaluated at the worker level: the worker is killed, then starts over with the same job list order. If the vacuum cron cannot be run anymore, it leads to tables not garbage collected anymore (e.g. `bus_bus`), causing performance issues. To avoid this, we give a higher priority to the vacuum cron. closes odoo/odoo#144210 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
24 lines
979 B
XML
24 lines
979 B
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<odoo>
|
|
<record id="autovacuum_job" model="ir.cron">
|
|
<field name="name">Base: Auto-vacuum internal data</field>
|
|
<field name="model_id" ref="model_ir_autovacuum"/>
|
|
<field name="state">code</field>
|
|
<field name="code">model._run_vacuum_cleaner()</field>
|
|
<field name='interval_number'>1</field>
|
|
<field name='interval_type'>days</field>
|
|
<field name="numbercall">-1</field>
|
|
<field name="priority">3</field>
|
|
</record>
|
|
|
|
<record id="ir_cron_res_users_deletion" model="ir.cron">
|
|
<field name="name">Base: Portal Users Deletion</field>
|
|
<field name="model_id" ref="base.model_res_users_deletion"/>
|
|
<field name="state">code</field>
|
|
<field name="code">model._gc_portal_users()</field>
|
|
<field name='interval_number'>1</field>
|
|
<field name='interval_type'>days</field>
|
|
<field name="numbercall">-1</field>
|
|
</record>
|
|
</odoo>
|