Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Détecter les processus Beam qui prennent beaucoup de mémoire #3446

Closed
thbar opened this issue Sep 5, 2023 · 1 comment
Closed

Détecter les processus Beam qui prennent beaucoup de mémoire #3446

thbar opened this issue Sep 5, 2023 · 1 comment
Assignees
Labels
ops Gestion des serveurs et de la production

Comments

@thbar
Copy link
Contributor

thbar commented Sep 5, 2023

Voir:

Les reboots actuels sont liés à des processus Beam plutôt qu'à des conversions via Rambo.

J'ai posé des questions pour détecter ça (et profiter de l'usage excessif pour tester):

Thanks @LostKobrakai:

:memsup can track memory usage periodically
:recon (and :recon_alloc) can help with manual checks
memsup is a process which supervises the memory usage for the system and for individual processes
By my understanding it just supports a single threshold, but you can lower the threshold
but you can add a custom alarm handler to further inspect processes (if still alive)

And @michalmuskala:

You can configure process heap limits - default action is to kill the processes that are too big, but you can also just log them

Liens utiles:

Exemple de code qui est sensé consommer de la mémoire:

Transport.Jobs.ResourceHistoryJob.new(%{
  "resource_id" => 65185, 
  "id" => Ecto.UUID.generate()
}) |> Oban.insert()

Notes

Un téléchargement complet HTTP résulte en un body sous forme de "binary", qui dès une taille assez petite est en fait stocké "hors heap". Par conséquent, on ne peut pas utiliser max_heap_size pour protéger le processus contre cela, ni mesurer la heap directement pour avoir le retour.

Je vais voir si il est possible de malgré tout détecter cela pour avoir un mécanisme un peu astucieux et généralisé qui nous préviendrait, et sinon j'implémenterai juste du streaming (on pourra voir l'usage général mémoire décroitre en moyenne).

@thbar
Copy link
Contributor Author

thbar commented Oct 20, 2023

Je clôture, pour l'instant on a identifié de "bons morceaux" et on a un suivi logs qui donne au moins une piste.

@thbar thbar closed this as completed Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ops Gestion des serveurs et de la production
Projects
None yet
Development

No branches or pull requests

1 participant