Skip to content

Conversation

@stephprobst
Copy link

This exposes the information, if the sync_server is running to the top level, allowing users to build custom logic around the start and stop functionality, e.g. to optimize memory management.

@ayjayt
Copy link
Collaborator

ayjayt commented Dec 18, 2025

Hi @stephprobst

Thanks for the PR, I'll try to get it into the next release, but I'm curious about what memory management there is?

The sync server is a singleton, only one can ever be created.

@ayjayt
Copy link
Collaborator

ayjayt commented Dec 18, 2025

I will also mention that chrome tends to take up as much as it thinks it can, and monitors system memory to shrink and expand its footprint. This is to prevent allocation calls during rendering phases and make it more responsive.

Unfortunately, it also masks memory leaks, because this feature looks like a memory leak constantly.

@stephprobst
Copy link
Author

stephprobst commented Dec 18, 2025

The use case is the following: If chrome is running in a Kubernetes container with limited memory it tends to increase its memory footprint over time after processing many requests and is only freeing up the memory very slowly. Stopping and restarting the chrome process has shown to free up the needed memory. So a regular restart of the server helps to avoid OOM kills of the containers.

This is clearly a workaround, but more manageable for the end user than trying to optimize the memory handling of the chrome process directly somehow.

@stephprobst stephprobst closed this by deleting the head repository Dec 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants