Limites matérielles et logicielles de la mémoire de tâches AWS ECS
Je suis confus quant au but d'avoir à la fois des limites de mémoire matérielle et logicielle pour les définitions de tâches ECS.
IIRC la limite logicielle est la quantité de mémoire que le planificateur réserve sur une instance pour l'exécution de la tâche, et la limite matérielle est la quantité de mémoire qu'un conteneur peut utiliser avant d'être tué.
Mon problème est que si le planificateur ECS alloue des tâches aux instances en fonction de la limite logicielle, vous pourriez avoir une situation où une tâche qui utilise de la mémoire au-dessus de la limite logicielle mais en dessous de la limite matérielle pourrait faire en sorte que l'instance dépasse sa mémoire maximale (en supposant toutes les autres tâches utilisent une mémoire légèrement inférieure ou égale à leur limite souple).
Est-ce correct?
Merci
Si vous prévoyez d'exécuter une charge de travail de calcul qui est principalement liée à la mémoire au lieu de liée au processeur, vous devez utiliser uniquement la limite fixe, pas la limite souple. De la documentation:
Vous devez spécifier un entier différent de zéro pour l'un ou les deux de memory ou memoryReservation dans les définitions de conteneur. Si vous spécifiez les deux, la mémoire doit être supérieure à memoryReservation. Si vous spécifiez memoryReservation, cette valeur est soustraite des ressources de mémoire disponibles pour l'instance de conteneur sur laquelle le conteneur est placé; sinon, la valeur de la mémoire est utilisée.
http://docs.aws.Amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
En spécifiant uniquement une limite de mémoire matérielle pour vos tâches, vous évitez de manquer de mémoire car ECS arrête de placer des tâches sur l'instance et Docker tue tous les conteneurs qui tentent de dépasser la limite matérielle.
La fonction de limite de mémoire souple est conçue pour les applications liées au processeur où vous souhaitez réserver un petit minimum de mémoire (la limite souple) mais autorisez des rafales occasionnelles jusqu'à la limite stricte. Dans ce type de charge de travail élevée du processeur, vous ne vous souciez pas vraiment de la valeur spécifique de l'utilisation de la mémoire pour les conteneurs, car les conteneurs manqueront de CPU bien avant d'épuiser la mémoire de l'instance, vous pouvez donc placer des tâches en fonction de Réservation CPU et limite de mémoire logicielle. Dans cette configuration, la limite stricte n'est qu'une sécurité intégrée au cas où quelque chose deviendrait incontrôlable ou en cas de fuite de mémoire.
Donc, en résumé, vous devez évaluer votre charge de travail à l'aide de tests de charge et voir si elle a tendance à manquer de CPU en premier ou à manquer de mémoire en premier. Si vous êtes lié au processeur, vous pouvez utiliser la limite de mémoire logicielle avec une limite matérielle facultative tout comme une sécurité intégrée. Si vous êtes lié à la mémoire, vous devrez utiliser uniquement la limite stricte sans limite souple.