Rappel : OOM Killer c'est specifique a Linux... Tous les OS ne traitent pas le manque de memoire de la meme maniere.
Je veux bien que les tres grosses allocs soient a eviter, mais le truc est que 10 ou 20Mb c'est pas si enorme... Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.
Un pool de processus c'est toujours pourri au niveau du design, tu te tapes le cout de chaque processus a part le 1er (stack assignee au process, tous les buffers statiques, etc...) en extra. Tout ce que tu fais au final c'est accelerer le moment ou tu seras OOM vu que tu consommes plus, et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à -4.
Rappel : OOM Killer c'est specifique a Linux... Tous les OS ne traitent pas le manque de memoire de la meme maniere.
Je veux bien que les tres grosses allocs soient a eviter, mais le truc est que 10 ou 20Mb c'est pas si enorme... Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.
Un pool de processus c'est toujours pourri au niveau du design, tu te tapes le cout de chaque processus a part le 1er (stack assignee au process, tous les buffers statiques, etc...) en extra. Tout ce que tu fais au final c'est accelerer le moment ou tu seras OOM vu que tu consommes plus, et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.