Page 1 of 1

Prevent "ERROR : Worker is unavailable too long. The worker will be restarted." When worker heap memory hits max?

Posted: Wed Mar 13, 2019 9:18 pm
We have a graph which uses a Fast Sort component to sort millions of rows. Each time this graph runs our worker heap memory max is reached and the following errors occurs in the logs.

ERROR 3801093 [threadPool-84] Worker [[email protected]] is unavailable too long. The worker will be restarted.

Is there a way to prevent this error from happening besides increasing the system memory? Something like preventing the graph from utilizing to much memory?

Current memory settings:
Total System Memory: 31GB
Worker Heap: 16GB
Server Core : 6GB

I have tried increasing the time out properties for the worker (worker.connectTimeout/worker.readTimeout) but that doesn't seem to have any impact on when the Worker forces a restart.

Re: Prevent "ERROR : Worker is unavailable too long. The worker will be restarted." When worker heap memory hits max?

Posted: Mon Mar 18, 2019 2:13 pm
Just to clarify, I know there are other ways to adjust the FastSort components specifically to prevent high memory utilization to an extent. But I was wondering it there was some other server wide configuration I might be able to use which applies the memory usage of all server processes.

Re: Prevent "ERROR : Worker is unavailable too long. The worker will be restarted." When worker heap memory hits max?

Posted: Tue Mar 19, 2019 9:54 am
by bartonv
Hello,
there are a couple of different approaches that you can take to prevent this issue from happening. As you rightly said, revising the configuration of the FastSort component is one of these options that goes right to the bottom of the problem. However, the configuration is quite complex in terms of balancing the sorting speed and the memory consumption of this component. Another option that eliminates the need for a complex configuration is to replace FastSort with the ExtSort component. As a matter of fact, ExtSort is what we generally recommend in similar situations (overconsumption of the heap memory by FastSort) and what also proves to work in most cases.
Given the known facts, I would advise you against setting up arrangements on the server level without sorting out the core of the problem (on the component level). Nevertheless, if you would like to discuss this issue in more detail I would suggest logging a support ticket via our CloverCARE Customer Portal as we would need to dig deeper into the details of your use case.
Kind regards,
Vladi