Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was changed
destroy()
methods to Workflow-related classesGarbageCollector
which is responsible for the frequency of calling the finding circular references function (garbage collecting).phpunit
has been updated to version 10. This is a necessary measure because changes in the PR broke some tests that couldn't be handled usingphpunit
9.Why?
A few months ago, when we were troubleshooting a memory leak issue, I added a call to the
gc_collect_cycles()
method after eachDestroyWorkflow
command execution.Garbage collection is quite a costly operation, and Workflows in Temporal are created and destroyed very frequently. We can verify this by looking at the metrics provided by the user Pyjac
We recently returned to the issue of potential memory leaks. In the process, some important optimizations were implemented:
gc_collect_cycles()
, but introduced control over the frequency of these calls. The collecting of circular references is now called by a 30-second timeout or when 1000 Workflows are destroyed. This way we are combating memory leaks in user code.After this update, we are seeing a significant increase in the throughput of the Workflow worker and almost no TaskTimeout errors under highload.
Before
After