View the original community article here
Last tested: Jun 18, 2020
A user sees RendererNoRenderFinishedEventReceivedError when downloading a PDF
So we go to the logs and see this:
2020-06-12 11:45:52.426 -0500 [WARN|00872|render] :: Chromium console output: WebSocket connection is not alive. id: 33
2020-06-12 11:45:52.433 -0500 [INFO|00872|render] :: Chromium Render Failed: WebSocket connection is not alive. id: 33
What is a Websocket?
Chromium is headless (it doesn't have a graphical display) and websockets are how Looker controls Chromium
If the connection is not alive it's likely that Chromium crashed or became unresponsive. This often happens when Chromium does not have enough available memory to run properly. On the Looker host, this can be caused by too much memory being allocated to the Looker process and not enough left over for Chrome.
If this happens often, the host will need more memory or Looker will need to be allocated less memory.
If your instance is Looker-hosted in Kubernetes, the instance will need a higher memory limit value with the memory request value staying the same. This is because due to the way that our infrastructure is set up, the Looker JVM will get all of the request memory, so to increase the leftover memory that Chrome can use, the limit will need to be increased.
To fix this issue for Looker-hosted k8s instances, the Looker devops team will need to upsize the memory limit to be 50% more than the request while keeping request as is, i.e. if request/limit is at 20 / 26GB, change to 20 / 30GB
If you're curious to learn more about what these numbers represent, check out this article for more information on request/limit memory values in kubernetes.
This content is subject to limited support.