Parfois, quand vous auto-hébergez vos services web ou quand vous utilisez une machine avec très peu de RAM, il arrive que vous arriviez devant des comportements d'applications qui semblent inexplicables. Un cas parmi tant d'autre est celui du service coupé, du processus tué alors qu'on n'a rien fait de spécial pour que ça arrive. Il n'empêche que la plus importante chose pour les applications (surtout en production) est la stabilité et donc qu'il serait bien de pouvoir comprendre ce qu'il se passe, dans ces cas-là.
Il existe de plus en plus de plates-formes d'hébergement qui louent des serveurs virtuels, où vous pouvez exécuter les services que vous voulez. Le nombre de processus ne sera pas limité. Par contre, les ressources y seront. Un des point faible de ces environnements est généralement la mémoire vive (RAM) qui, une fois dépassée, entraîne une instabilité du serveur, voire un plantage total.
OOM KIller est un ensemble de processus du noyau Linux qui est chargé d'empêcher la surcharge de la mémoire sur le système. Il se déclenche donc quand il n'y a plus aucune mémoire disponible sur le système.
Quand un processus a besoin de mémoire, le système alloue tout d'abord la mémoire physique du système. Une fois que cette mémoire est "pleine", le système tentera de remplir la mémoire swap : un fichier d'échange ou une partition dédiée qui joue le rôle de mémoire d'échange du système. Une fois que cette mémoire est également pleine, il ne reste plus du tout de place pour que le système alloue de la mémoire.
Quand il n'y a plus du tout de ressources mémoires disponibles à allouer, le processus du Out Of Memory Killer se déclenche et essaye de faire un peu de ménage. Ce processus va essayer de deviner quelles sont les applications qui consomment le plus de mémoire, ou qui seraient les plus susceptibles d'être arrêtées via un ensemble d'algorithme, et les tue jusqu'à ce que le système retrouve suffisamment de ressources pour fonctionner.
Le problème avec ce système, c'est qu'on ne peut pas deviner à l'avance quelles seront les applications qui seront tuées avant les autres. D'ailleurs, l'OOM Killer visera vraisemblablement plus facilement les applications ayant besoin de beaucoup de mémoire pour fonctionner. Dans le cas d'applications de bureau, à la limite, le problème n'est pas bien grave. Dans le pire des cas, on se retrouvera avec un Firefox ou, pour les développeurs, avec un IDE de programmation, qui se ferme (oui, ces deux softs consomment énormément de mémoire).
Le vrai soucis est plutôt pour les applications métiers ou dans les systèmes critiques, où on n'aura pas forcément envie de voir les applications qui se coupent en plein milieu d'un processus délicat. Pensez par exemple à un robot qui s'arrêterait de travailler en plein milieu de la confection d'une pièce dans une usine ou alors à un robot médecin (pourquoi pas, c'est la mode, il me semble) qui s'arrêterait au beau milieu d'une opération.
Dans les faits, quand l'OOM Killer est appelé, c'est qu'il y a un problème de mémoire sur la machine. On peut pour cela trouver plusieurs raisons qui sont toutes aussi valables :
Dans tous les cas, il faudra penser à dimensionner la machine (même virtuelle) sur laquelle le processus s'exécutera de façon à ce qu'il fonctionne correctement. Pour savoir la quantité de RAM nécessaires aux processus qui tournent sur le serveur, référez-vous aux manuels ou faites des tests de charge, ce ne sera jamais du temps de perdu.
Lorsque la mémoire du système est épuisée à tel point qu'il y a une menace sur la stabilité du système, le processus d'optimisation de la mémoire s'exécutera : il tuera et continuera de tuer des processus jusqu'à ce que suffisamment de mémoire soit libérée pour que le reste du système fonctionne correctement - en tout cas, au moins les processus que le noyau exécutera.
Dans un premier temps, la sélection se fera sur le meilleur processus à tuer. Meilleur parce qu'il libérera le plus de mémoire, mais aussi parce qu'il ne sera pas indispensable à la stabilité du système. L'objectif ici sera de tuer un minimum de processus tout en maximisant la quantité de mémoire libérée. Ainsi, le système sera impacté au minimum.
Pour faciliter le choix des processus qu'il peut tuer, le noyau Linux garde un oom_score pour chacun des processus qu'il lance. Vous pouvez d'ailleurs voir le oom_score d'un processus en tapant la commande :
cat /proc/{pid}/oom_score
Plus la valeur de l'oom_score du processus sera élevé, plus il aura de chance d'être tué par l'OOM Killer.
Il y a quelque temps maintenant, le calcul du oom_score était un processus plutôt hasardeux. A l'heure actuelle, il repose essentiellement sur la question de savoir quel pourcentage de la mémoire disponible est utilisé par le processus.
Il y a deux types de dépassement de mémoire :
Quelque soit le cas, l'utilisation de mémoire d'un processus est la somme de la RAM qu'il occupe et de son utilisation de SWAP.
Une fois qu'on sait quelle est la quantité de mémoire utilisée par un processus, on peut calculer son oom_score sur une référence 1000 :un processus qui utilise tous les octets de la mémoire disponible aura un score de 1000 ; un processus qui n'utilise aucune mémoire aura un score de 0 (il y a très peu de chance, donc). J'ai sciemment simplifié le calcul, mais dans l'ensemble, c'est comme ça que ça marque. Il y a ensuite quelques ajustements qui sont faits dans ce calcul, mais sur de très faibles valeurs (maximum 30).
Ceci étant dit, il est possible d'adapter cette valeurs aux besoins de notre système. Il existe une variable nommée oom_adj_score qui peut être ajustée et qui rentrera dans le calcul du oom_score. Cette variable, que chaque processus possède et dont la valeur doit être comprise entre -1000 et 1000, est ajoutée au calcul du oom_score : si le oom_score d'un processus donné, calculé d'après la formule précédente, est de 300, par exemple et que la variable oom_adj_score est de -500, l'oom_score réel du processus sera de -200, faisant de lui un processus qui ne sera pas tué tout de suite en cas de problème mémoire.
Pour ajuster cette variable, vous pouvez le faire via /proc, mais il vous faudra savoir le PID de votre processus.
Prenons un exemple. S'il est absolument primordial pour vous que le processus sshd ne soit jamais arrêté (c'est bien pour un serveur lointain, par exemple, ça évite d'être obligé d'éteindre le courant pour avoir à nouveau accès à la machine). Commencez par trouver le PID de votre processus :
ps aux | grep sshd
Vous devriez voir apparaître quelque chose dans ce goût-là :
root 2623 0.0 0.0 49948 1232 ? Ss Feb08 0:00 /usr/sbin/sshd
Ce qui veut dire que votre application a un PID de 2623. Toutes les informations de ce processus sont donc situées, dans le système, dans le dossier /proc/2623. Et en effet, quand on liste le contenu de ce dossier, on obtient :
[code][...] -r--r--r-- 1 root root 0 Feb 11 01:09 cmdline [...] lrwxrwxrwx 1 root root 0 Feb 11 01:09 exe -> /usr/sbin/sshd [...] -rw-r--r-- 1 root root 0 Feb 12 00:22 oom_adj -r--r--r-- 1 root root 0 Feb 12 00:22 oom_score -rw-r--r-- 1 root root 0 Feb 12 00:22 oom_score_adj [...] -r--r--r-- 1 root root 0 Feb 11 06:25 status [...][/code]
C'est la liste des fichiers associés au processus en cours (je n'ai pas tout retranscrit par soucis de lisibilité). Remarquez les 3 fichiers oom qui nous intéressent :
Si vous voulez connaître leur valeur, faites un :
cat /proc/<PID>/oom_*
Si on veut être sûr que ce processus ne s'arrête pas tant qu'on ne lui a pas demandé de s'arrêter, on pourra mettre la variable oom_score_adj à -1000 :
echo -1000 > /proc/<PID>/oom_score_adj
Ainsi, lors du calcul du oom_score, le processus de calcul soustraira 1000 à la valeur calculée et il y aura donc de très fortes chances que votre processus ne s'éteigne jamais.
Si vous voulez faire l'inverse, c'est à dire donner un score maximum à un process pour être sûr que ce soit lui qui s'arrête avant les autres, la valeur -1000 sera remplacée par 1000 pour qu'à la fin du calcul, le processus ajoute 1000 au score.
Bien sûr, comme quasiment n'importe quelle fonctionnalité du noyau Linux, on peut configurer à notre convenance la façon dont OOM Killer fonctionnera..
Il y a deux variables que nous pouvons modifier :
Quand on y réfléchit, un système ne peut gérer un dépassement de mémoire que de deux façons : tuer certains processus qui prennent trop de place dans la mémoire ou planter purement et simplement. Par soucis de stabilité, par défaut, le noyau Linux préférera couper certains processus que de totalement planter avec un kernel panic. Si toutefois votre préférence va pour le kernel panic, aucun soucis, vous pouvez désactiver complètement l'effet du OOM Killer en modifiant la valeur de la variable du noyau /proc/sys/vm/panic_on_oom :
Attention, la stabilité d'un système ne tient souvent pas à grand chose. La gestion de la mémoire du noyau Linux est compliquée et modifier la façon dont le système fonctionne peut entraîner une grande instabilité du système. Chaque machine étant différente, il convient de bien comprendre la façon dont la gestion de la mémoire se fait avant de toucher quoi que ce soit. Garder toujours à l'esprit qu'il vaut mieux dimensionner son système correctement, voire modifier notre système (ajouter de la RAM, de la SWAP…) que de modifier la façon dont le système gérera les dépassement de mémoire.
Cet article est pour information, il relate ce que j'ai compris de la configuration du kernel Linux face au manque de mémoire. Faites-moi savoir si vous voulez plus de précisions ou si j'ai fait des erreurs.
Le première extension que j’installe, quelque soit le site que je fais avec Joomla!, c’est JCE - un acronyme de Joomla Content Editor. JCE est un éditeur de contenu HTML très performant qui offre des services que l’éditeur par défaut n’offre pas, notamment au niveau de la gestion des liens et des images. Une fois qu’on a essayé son système de gestion des médias, il est difficile de revenir à l’éditeur par défaut.
Il est possible d’améliorer encore ses capacité en installant des plugins pour l’éditeur. J’installe notamment quasi systématiquement JCE Popup qui permet d’ouvrir des liens - images, autre site, etc. - dans une fenêtre popup LightBox.
Une des fonctions qu’il manque à Joomla! de base, d’après moi, c’est la possibilité de prévisualiser les articles que nous sommes en train d’écrire exactement comme ils seront affichés dans le site Internet au final. L’extension Better Preview ajoute un bouton “Aperçu” dans la fenêtre d’édition des article qui permet justement de prévisualiser cet article dans le site Internet.
Admin Tools permet de réhausser le niveau de sécurité d’un site Joomla! Il permet de faire quelques opérations simples de maintenance qui pourraient vite, sans cette extension, prendre beaucoup de temps, notamment :
Crée par les mêmes personnes qui ont fait le composant “Admin Tools”, “Akeeba Backup” permet de créer des points de sauvegarde du site Internet. Ce qui est intéressant avec ce système de sauvegarde en particulier, c’est qu’il est capable de générer une archive de l’intégralité du site Internet, base de données et fichiers inclus. Cette archive pourra ensuite être extraite pour restaurer votre site Internet sur n’importe quel serveur, avec le logiciel “Akeeba Kickstart”.
AllVideos est un plugin de contenu qui permet d’afficher des vidéos et de lire des fichiers audio venant de multiples sources comme YouTube, Metecafe, Vimeo (et beaucoup d’autres). Il permet de ne pas copier / coller un code HTML infinissable dans chaque page dans laquelle nous avons une vidéo à intégrer.
Cet article va me servir en priorité d'aide-mémoire, mais si ça peut aider certains d'entre vous, tant mieux.
Compter le nombre de dossiers, sous-dossiers et fichiers d'un dossier donné :
ls -R1 | wc -l
Définitions |
||
Vecteurs |
 |
Pixels |
|
Les dessins par vecteurs sont générés à partir de formules mathématiques. Ils peuvent donc être agrandis ou réduits indéfiniment. |
Les dessins en pixels (ou rasterisés) sont des images faites de petits points. Ils ont été prévus pour avoir une taille donnée, et l'agrandissement ou la réduction de ces images fera apparaître ces points. |
|
Au niveau des extensions |
||
|
|
|
Les programmes à utiliser |
||
|
|
|
Game Maker est un puissant outil dédié à la création de jeux vidéo de qualité. Besoin d’une preuve ? Ces quelques exemples en vidéo devraient vous convaincre du potentiel de ce logiciel :
À l’ouverture du logiciel, vous êtes face à un écran dépouillé, mais contenant toutes les options nécessaires à la création « simple » d’un jeu.
La création d’un jeu n’étant pas chose aisée, il y a forcément de nombreux boutons et fonctionnalités assez poussées. Toutefois, vous pouvez utiliser ce logiciel de façon simple, car Game Maker (GM) reste accessible, même pour un débutant.
Regardons ensemble ce que cet écran nous propose.
Vous trouverez l’arbre des ressources sur la gauche de votre écran. Il contient tous les éléments composant votre jeu. Tout ce que dont vous aurez besoin (graphismes, objets, niveaux, sons, etc.) se trouve dans cette liste, trié en catégories ayant du sens pour le moteur de GM. Quand vous créez un nouveau projet, cette liste est entièrement vide.
Pour ajouter de nouveaux éléments dans cette liste, cliquez avec le bouton droit de la souris sur un type de ressource à créer (par exemple object), puis sur “create”.
Parmi les éléments qui composent un jeu, 4 sont vraiment importants, et il vous faudra bien comprendre leur utilité avant de pouvoir créer quoi que ce soit avec GM.
Au plus haut niveau de cette liste, il y a les sprites. Ce sont les images et les animations qui composent vos graphismes. D’ailleurs, un sprite peut être une simple image comme une animation en plusieurs images. Nous pouvons également régler la forme de l’objet lors des collisions (une forme précise, un carré, un rond, etc.).
Les backgrounds (ou arrière-plans) ressemblent un peu aux sprites parce que ce sont également des images. Contrairement aux sprites, les arrière-plans ne peuvent pas contenir d’animations. Ils sont fixes et ne peuvent pas non plus gérer de collisions. Ce sont donc des images qui n’ont quasiment aucune propriété spéciale, et peuvent donc être plus grosses et répétées.
Les objets représentent le coeur même du système. Grâce aux objets, vous allez pouvoir créer toute la logique et l’interactivité de votre jeu. En général, les objets sont les éléments visuels de votre jeu : le personnage contrôlé par le joueur, les ennemis, les objets que l’on doit attraper ou ceux faisant partie du décor, les murs, etc. Mais on peut aussi les utiliser pour des actions plus abstraites, comme contrôler la musique ou le volume sonore, connaître le nombre de vies restantes au joueur, etc.
Un sprite peut être assigné aux objets, et ils contiennent au départ une liste vide d’événements que vous devrez remplir pour que les objets puissent être utiles. Un événement est quelque chose qui se passe dans le jeu : un utilisateur presse une touche ou clique avec la souris quelque part, un objet entre en collision avec un autre, le démarrage du jeu, le nombre de vie arrive à 0, etc.
Quand un événement que vous aurez défini arrive, l’objet effectuera les actions associées à cet élément : bouger de quelques pixels, détruire un objet, baisser le nombre de vies, incrémenter le score, changer des variables de jeu, etc.
Voici la clef des jeux créés avec GM : quand votre jeu est lancé, des événements sont déclenchés et des actions réalisées. Dans un premier temps, vous pouvez réaliser entièrement en glisser-déposer à peu près tout ce que vous voudrez. Avec de l’expérience, vous apprendrez à maîtriser le langage de programmation associé à GM : GML (Game Maker Langage) et vous apprendrez que vous n’avez quasiment aucune limite dans ce que vous pouvez faire avec ce logiciel.
Les pièces peuvent être considérées comme des « niveaux » dans vos jeux, ou plus simplement des « écrans » qui contiendront les autres éléments définis dans la liste des ressources. Ainsi, un menu, une introduction ou un niveau sont tous (trois) des pièces.
Pour démarrer, un jeu doit avoir au moins une pièce définie, et par défaut, GM affichera la pièce située tout en haut de la liste des pièces.
Une pièce a également quelques propriétés : une taille, une vitesse d’exécution (un nombre d’images calculées par seconde), un arrière-plan associé, etc.
L’onglet objects sur la gauche vous permettra d’ajouter des objets préalablement créés, mais nous y reviendrons plus tard.
Il y a bien sûr d’autres ressources utilisables dans GM, mais si vous comprenez déjà ce que sont les sprites, les arrières-plans, les objets et les rooms, vous connaissez l’essentiel, et surtout, vous devriez commencer à comprendre la logique du moteur de GM.
La suite prochainement.