Pour ceux qui ont entendu parler des conteneurs et de Docker , mais qui ne comprennent pas comment Java s'est accroché aux conteneurs. Tout d'abord, rafraîchissons notre mémoire sur la mémoire Java . Permettez-moi de vous rappeler que la mémoire est constituée de Stack et de Heap, qui utilisent la RAM (mémoire vive) du serveur ; lorsque nous parlerons plus en détail de mémoire, nous parlerons de RAM. Examinons maintenant le conteneur en coupe transversale. Non bien sûr que non, la croupe et les cuisses ne nous intéressent pas, nous allons regarder la structure mémoire dans le conteneur. Elle peut être divisée en trois parties : • Heap Memory – le tas lui-même ; • Hors tas : tout ce qui n'est pas dans le tas ; • La surcharge du système d'exploitation correspond à la surcharge de mémoire nécessaire à l'implémentation des processus à l'intérieur du conteneur. Disons : Nous avons alloué 1 Go au conteneur, dans la figure ce sera Container Limit - ses limites sont indiquées par un rectangle bleu. Nous avons alloué 80 %, soit 0,8 Go, pour la mémoire Java dans le conteneur, et Heap nous a pris environ 80 % du conteneur, soit pas moins de 0,8 Go, car OS Overhead prenait une partie des ressources (overhead) pour maintenir les processus. Il reste environ 20 % du conteneur pour tout ce qui n'est pas connecté au tas ( Off Heap ). La zone Utilisée sur la figure montre la zone mémoire utilisée pour exécuter l'application. Nous devons maintenant parler des situations dans lesquelles la mémoire du conteneur peut s'épuiser. OutOfMemoryError Si la consommation de mémoire de l'application ( Zone utilisée ) atteint les limites du tas ( Heap ), nous attraperons une OutOfMemoryError (OOM Error) . Ce qui signifie qu'il n'y a pas assez d'espace dans le tas, à savoir dans la zone mémoire dans laquelle sont placés les objets créés par programme dans l'application. Si ce n’est pas encore tout à fait clair, je vais l’expliquer chez les chats. OOM L'erreur , c'est lorsqu'un chat crie très, très longtemps devant les portes du balcon, et lorsque cette porte est ouverte, il se tient dans l'embrasure de la porte et ne va dans aucun sens, on dit souvent que le chat est gelé. Si vous le poussez à temps, il laissera tomber sa mâchoire et ira sur le balcon pour faire ses affaires de chat. OOM Killer C'est une autre situation qui peut se produire dans un conteneur lorsque la mémoire est épuisée. Si un programme sort du conteneur, nous obtenons un OutOfMemory Killer (OOM Killer) - il s'agit d'un processus qui met fin à l'application pour empêcher le noyau de planter. Cela sacrifie l’application pour que le conteneur continue de fonctionner. Ce n’est pas un fait que le conteneur tombera, mais l’application qui s’y exécute tombera certainement. Cela se produit si vous laissez la consommation de mémoire d'une application Java incontrôlée. Encore une fois sur les chats. Si vous avez décidé de dormir plus longtemps samedi et avez oublié de donner à manger aux chats, alors OOM Killerles fleurs sont garanties, les pots ne pourront pas être endommagés, mais les fleurs devront être replantées. Quelle est la différence entre l'erreur OOM et le tueur OOM ? Vous pouvez traiter l'erreur OOM et effectuer certaines actions (par exemple : mettre à l'échelle l'application), et OOM Killer tuera simplement l'ensemble du processus. OOM Killer est similaire à kill-9 (kill moins neuf) - une commande qui tue un processus sous Linux . Le fait est que l'implémentation de conteneur la plus populaire est le conteneur Docker, qui est basé sur Linux , même si vous l'exécutez sous Windows , le noyau proviendra toujours de Linux . Sous Linux, nous nous intéressons à un concept : les CGroups (groupe de contrôle en anglais) - un mécanisme du noyau Linux qui limite et isole les ressources informatiques (processeur, réseau, ressources mémoire, ressources d'E/S) pour des groupes de processus. En termes simples, ce mécanisme permet de gérer les ressources dans un conteneur, dans notre cas la mémoire. Quel est le rapport entre Java et cela ? C'est grâce au mécanisme CGroups que Java peut s'accrocher à la mémoire du conteneur. Mais tout dépend de la version de Java. Par exemple, Java 7 ne sait pas utiliser les CGroups et les limites des conteneurs lui sont inconnues. Par défaut, taille maximale du tas = ¼ de mémoire physique. Si l'application dépasse les limites du conteneur, alors il y aura un OOM Killer , et si les limites du conteneur ne sont pas définies, alors l'application prendra la mémoire des autres applications sur le serveur (il est préférable de fixer des limites, sinon tout le monde perdra) . Vous pouvez bien sûr utiliser des paramètres de tas ou utiliser des "images" spéciales qui résolvent ce problème, mais le moyen le plus simple consiste à utiliser la version correcte de Java. Les versions correctes commencent avec Java 8 x131 (porté depuis Java 9), elles commencent à comprendre les CGroups . Et dans Java 10, la prise en charge des conteneurs est apparue : UseContainerSupport , plus tard cette fonction a été portée sur Java 8 x 191 . Ou vous pouvez simplement utiliser Java : 11+ . Que peut-on conclure : Lorsque vous utilisez la mémoire du conteneur, vous pouvez recevoir une erreur OutOfMemoryError (erreur MOO) ou OutOfMemoryKiller (MOO Killer). Dans le premier cas, l'application ne plantera pas immédiatement, une erreur MOO peut être détectée, traitée et des actions contrôlées peuvent être entreprises. Par exemple, faites évoluer l'application. Si un OOM Killer se produit, l'application plantera immédiatement et il n'y aura plus aucune option pour la sauvegarder. Et le pire, c'est qu'extérieurement, le conteneur lui-même ira bien, c'est-à-dire que vous ne soupçonnerez peut-être même pas que quelque chose y est tombé. Les mécanismes Linux sont utilisés pour interagir avec la mémoire du conteneur et Java. Mais tous les Java ne les implémentent pas. Pour éviter les problèmes avec Java 8, vous devez utiliser une version commençant à 131, ou mieux encore, à partir de 191. Ou utilisez Java : 11+. Pour la pratique : OutOfMemoryError : attrapez-le si vous le pouvez
Non bien sûr que non, la croupe et les cuisses ne nous intéressent pas, nous allons regarder la structure mémoire dans le conteneur. Elle peut être divisée en trois parties : • Heap Memory – le tas lui-même ; • Hors tas : tout ce qui n'est pas dans le tas ; • La surcharge du système d'exploitation correspond à la surcharge de mémoire nécessaire à l'implémentation des processus à l'intérieur du conteneur. 
Disons : Nous avons alloué 1 Go au conteneur, dans la figure ce sera Container Limit - ses limites sont indiquées par un rectangle bleu. Nous avons alloué 80 %, soit 0,8 Go, pour la mémoire Java dans le conteneur, et Heap nous a pris environ 80 % du conteneur, soit pas moins de 0,8 Go, car OS Overhead prenait une partie des ressources (overhead) pour maintenir les processus. Il reste environ 20 % du conteneur pour tout ce qui n'est pas connecté au tas ( Off Heap ). La zone Utilisée sur la figure montre la zone mémoire utilisée pour exécuter l'application. Nous devons maintenant parler des situations dans lesquelles la mémoire du conteneur peut s'épuiser. OutOfMemoryError Si la consommation de mémoire de l'application ( Zone utilisée ) atteint les limites du tas ( Heap ), nous attraperons une OutOfMemoryError (OOM Error) . Ce qui signifie qu'il n'y a pas assez d'espace dans le tas, à savoir dans la zone mémoire dans laquelle sont placés les objets créés par programme dans l'application. 
Si ce n’est pas encore tout à fait clair, je vais l’expliquer chez les chats. OOM L'erreur , c'est lorsqu'un chat crie très, très longtemps devant les portes du balcon, et lorsque cette porte est ouverte, il se tient dans l'embrasure de la porte et ne va dans aucun sens, on dit souvent que le chat est gelé. Si vous le poussez à temps, il laissera tomber sa mâchoire et ira sur le balcon pour faire ses affaires de chat. 
OOM Killer C'est une autre situation qui peut se produire dans un conteneur lorsque la mémoire est épuisée. 
Si un programme sort du conteneur, nous obtenons un OutOfMemory Killer (OOM Killer) - il s'agit d'un processus qui met fin à l'application pour empêcher le noyau de planter. Cela sacrifie l’application pour que le conteneur continue de fonctionner. Ce n’est pas un fait que le conteneur tombera, mais l’application qui s’y exécute tombera certainement. Cela se produit si vous laissez la consommation de mémoire d'une application Java incontrôlée. Encore une fois sur les chats. Si vous avez décidé de dormir plus longtemps samedi et avez oublié de donner à manger aux chats, alors OOM Killerles fleurs sont garanties, les pots ne pourront pas être endommagés, mais les fleurs devront être replantées. 
Quelle est la différence entre l'erreur OOM et le tueur OOM ? Vous pouvez traiter l'erreur OOM et effectuer certaines actions (par exemple : mettre à l'échelle l'application), et OOM Killer tuera simplement l'ensemble du processus. OOM Killer est similaire à kill-9 (kill moins neuf) - une commande qui tue un processus sous Linux . 
Le fait est que l'implémentation de conteneur la plus populaire est le conteneur Docker, qui est basé sur Linux , même si vous l'exécutez sous Windows , le noyau proviendra toujours de Linux . Sous Linux, nous nous intéressons à un concept : les CGroups (groupe de contrôle en anglais) - un mécanisme du noyau Linux qui limite et isole les ressources informatiques (processeur, réseau, ressources mémoire, ressources d'E/S) pour des groupes de processus. En termes simples, ce mécanisme permet de gérer les ressources dans un conteneur, dans notre cas la mémoire. Quel est le rapport entre Java et cela ? C'est grâce au mécanisme CGroups que Java peut s'accrocher à la mémoire du conteneur. Mais tout dépend de la version de Java. Par exemple, Java 7 ne sait pas utiliser les CGroups et les limites des conteneurs lui sont inconnues. Par défaut, taille maximale du tas = ¼ de mémoire physique. Si l'application dépasse les limites du conteneur, alors il y aura un OOM Killer , et si les limites du conteneur ne sont pas définies, alors l'application prendra la mémoire des autres applications sur le serveur (il est préférable de fixer des limites, sinon tout le monde perdra) . Vous pouvez bien sûr utiliser des paramètres de tas ou utiliser des "images" spéciales qui résolvent ce problème, mais le moyen le plus simple consiste à utiliser la version correcte de Java. Les versions correctes commencent avec Java 8 x131 (porté depuis Java 9), elles commencent à comprendre les CGroups . Et dans Java 10, la prise en charge des conteneurs est apparue : UseContainerSupport , plus tard cette fonction a été portée sur Java 8 x 191 . Ou vous pouvez simplement utiliser Java : 11+ . Que peut-on conclure : Lorsque vous utilisez la mémoire du conteneur, vous pouvez recevoir une erreur OutOfMemoryError (erreur MOO) ou OutOfMemoryKiller (MOO Killer). Dans le premier cas, l'application ne plantera pas immédiatement, une erreur MOO peut être détectée, traitée et des actions contrôlées peuvent être entreprises. Par exemple, faites évoluer l'application. Si un OOM Killer se produit, l'application plantera immédiatement et il n'y aura plus aucune option pour la sauvegarder. Et le pire, c'est qu'extérieurement, le conteneur lui-même ira bien, c'est-à-dire que vous ne soupçonnerez peut-être même pas que quelque chose y est tombé. Les mécanismes Linux sont utilisés pour interagir avec la mémoire du conteneur et Java. Mais tous les Java ne les implémentent pas. Pour éviter les problèmes avec Java 8, vous devez utiliser une version commençant à 131, ou mieux encore, à partir de 191. Ou utilisez Java : 11+. Pour la pratique : OutOfMemoryError : attrapez-le si vous le pouvez
GO TO FULL VERSION