Community archivos de la lista de correo


Re: wkhtmltopdf severe memory leak

XOE Corp. SAS, David Arnold
- 28/07/2016 19:05:55
@Naran hello to celery!

El jue., 28 jul. 2016 a las 18:03, David Arnold (<>) escribió:
Daniel, I'm not sure if that's 100% certain.

The problem is memory consumption, not necessarily of the type that non-blocking/async addresses. However, offloading report generation is in my opinion quite an imperative, regardless of this issue. In this I absolutely agree with you!

As webkit.url is already configurable in databases, I think at first sigh, it seems rather ease to spin it out as a microservice.
So putting webkit onto a lightweight server and caging it into a docker with resource limits (eventually onto a completely different server) seems to me the right approach. 

Please correct me if I'm wrong about the possibilities of the webkit.url parameter.

I repeat: After this, I think running wkhtmltopdf on the same server as the odoo or (worse) postgres instance is a major slumbering risk for the instance.

Best, David

El jue., 28 jul. 2016 a las 17:22, Daniel Reis (<>) escribió:
As a future improvement idea, delegating the pdf generation to an async  cron job could mitigate this issue.

Report generation queues is something you can find in ERPs like SAP or Oracle Financials.


No dia 28/07/2016, às 22:52, David Arnold <> escreveu:


This is what has been caused by wkhtmltopdf on one of our smaller instances (4 GB on Google Cloud).

El jue., 28 jul. 2016 a las 16:37, David Arnold (<>) escribió:

thanks for this valuable input! On the linked issue, it has been reported that 16GB doesn't cause problems as it is presumably sufficient to buffer this extraordinary consumption. Also what you describe about the limit_memory_hard parameter to 2GB and previous errors could be interpreted as coinciding with the reported increase in memory demand.

I suppose it would be wise to state, that outsourcing wkhtmltopdf to another service is probably a good idea.

If all conclusions are right, then your setup could possibly explode when all 10 odoo workers get increased load from this wkhtmltopdf problem at around the same time, assuming that the memory demand of this malicious wkhtmltopdf process would be more than 16GB This is extremely unlikely, indeed.

Assuming that you are on 0.12.1, this would then indicate that 0.12.1 has the same problem. This also coincides with the issue the wkhtmltopdf maintainer linked in my reported issue, which was going on for 2 years.

Any further reports on this are helpful. Thanks!

as to wkhtmltopdf, iirc: a patched version is required which is satisfied by either 0.12.1 or 0.12.3, yet NOT by 0.12.2
Therefore I think, this is a different beast.

Best, David

El jue., 28 jul. 2016 a las 15:53, Ray Carnes (<>) escribió:

In our most recent deployment:


8 CPU’s

2 Threads per core

4 Cores per socket

1 Socket             1

2,900 Mhz CPU



10 Odoo workers


Initially we ran into occasional error -11 with PDF generation.


After increasing the worker  limit_memory_hard parameter to 2GB we have had no further reports of any problems.


For those who don’t know, Odoo recommends 0.12.1 of wkhtmltopdf as documented at




From: David Arnold []
Sent: Thursday, July 28, 2016 1:27 PM
To: Community <>
Subject: wkhtmltopdf severe memory leak



we have experienced the following issue:

In short wkhtml explodes to 1GB+ memory consumption in less then our metrics resolution (2s).

That should worry anyone who runs wkhtmltopdf on the same instance as odoo runs and would kill every averagely scoped server instance under otherwise normal load.

Be warned!
Share your experience with this please!

If I remeber correctly (I'm under way on cellphone):
we are on wkhtmltopdf 0.12.3
the maintainer suggests to try 0.13 alpha

I'll keep you updates once further findings drop in.

Best, Regards


Post to:


Post to: