La taille du swap je l'ai choisi un peu au pif pour être honnête. Je voulais pas respecter la "règle" de la moitié de la ram en swap, parce que mon espace disque est limité, et je me disais aussi qu'on va jamais consommer autant de ram.
Comme dit plus bas, cette machine à la base n'était pas prévu pour faire tourner des vm, elle devait uniquement faire tourner un postgresql pas vraiment chargé.
Depuis, on a eu un nouveau projet et on a du utiliser cette machine, et le temps qu'on ait accès à des machines physiques pour nos process java, j'ai décidé d'y faire tourner quelques vm.
Jusqu'à présent ça marchait sans que rien ne se fasse tuer, mais ces dernières semaines la charge sur postgresql a augmenté, ainsi que la charge sur la vm avec Redis dessus, et le oom killer a commencé à frapper.
Bref, la config de cette machine est certainement pas parfaite, mais à la base je suis développeur, et ça a été mis en place en peu de temps.
Si je supprime le swap ça va pas accentuer le problème, vu qu'il est utilisé à 100% ?
Ce sont de simples fichiers sur un volume raid. Ce sont pas des vm qui font beaucoup d'io, à part un fichier de log d'un process java.
Si ça avait été prévu dès le départ de faire tourner des vm j'aurai certainement fait du lvm, mais à la base cette machine devait que de la base de données.
Apparemment il y a cette option pour désactiver le cache, mais je viens de vérifier et le cache est déjà désactivé sur mes vm. Ou bien je comprends mal ce que cette option est censé faire.
Je n'ai aucune ligne de ce genre dans mon syslog ou mon kern.log malheureusement, ce que j'ai fourni plus haut c'est tout ce que j'ai avec la liste de processus.
J'ai 6 vm avec 4096mo, une vm avec 2048 mo et une vm avec 8192 mo de RAM. 34816mo en tout.
La quantité de cache me paraît phénoménale, mais c'est sans doute normal.
Je pourrais rajouter de la RAM (c'est une grosse machine), mais pour le moment j'ai coupé 3 vm ce qui me donne un peu de marge, et ai transféré les services sur d'autres machines.
A tout hasard, est-il possible de connaître le détail de ce qui est en cache ?
EDIT: je viens de refaire un drop_caches pour voir, il vient de passer de 39 à 25go...
Je suis en 64 bits.
Le drop_caches m'a fait gagner environ 3 go de mémoire, je suis à 26Go de cache.
Concernant le détail de l'oom killer je ne suis pas sûr de ce que tu souhaites comme informations, donc voilà ce que j'ai dans mon syslog: http://pastie.org/3137082
Je n'ai pas inclus une liste de processus avec plusieurs centaines d'entrées de ce type:
Posté par Sphax .
En réponse au journal Les SSD.
Évalué à 2.
J'ai oublié de préciser je suis sur Windows. Avec un jeu comme Rift ou Mass Effect 2 qui prend chacun plus de 10go, c'est vite tendu. J'y ai mis aussi mes machines VirtualBox, ainsi qu'une petite partition avec une debian. Il me reste environ 50 go de libre, et encore j'ai du faire du ménage, avant j'avais beaucoup plus de jeux installés.
Posté par Sphax .
En réponse au journal Les SSD.
Évalué à 9.
Contrairement à ce qui a été dit plus haut, on a beaucoup à gagner avec un SSD. Je viens de changer mon disque système (un 7200rpm basique) contre un Crucial M4 128go, et je regrette pas du tout mon achat. Certes ça fait cher le Go (210€ le mien), mais pour une utilisation basique c'est le meilleur achat possible après la ram.
Par exemple, j'ai divisé mon temps de boot par 2, la plupart des applications se lancent instantanément, le chargement dans les jeux est plus rapide, etc
Pour la fiabilité, je vais pas en parler vu que ça fait même pas 2 semaines que j'ai un SSD.
Et un petit retour en utilisation serveur: depuis février dans ma boîte on a un serveur HP avec 2 SSD HP de 60Go monté en raid 1 via la carte raid. Autant ça marche bien, autant les performances sont pas super. En testant avec bonnie++ sur ce volume de SSD, et en comparant avec un volume de HDD 15k rpm aussi en raid 1, les chiffres étaient très similaires...Maintenant, savoir si c'est la carte raid qui nous bride d'une façon ou d'une autre, j'ai pas cherché plus loin.
Côté fiabilité, ce volume contient un tablespace PostgreSQL avec plus de 3 millions de lignes insérées chaque jour, et pour le moment les disques sont en vie.
J'ai remarqué que les écritures sur disque intervenait toutes les 30s. J'ai pensé aux intervalles que l'on peut tuner dans le noyau (vm.dirty_expire_centisecs et vm.dirty_writeback_centisecs), et bingo, dirty_expire_centisecs est par défaut à 300 100ème de seconde, soit 30s.
En pensant réduire le volume de données écrites, et écrire plus souvent mais moins longtemps, j'ai baissé ce paramètre à 10s. A mon étonnemment, les valeurs écrites n'ont pas changé, ou peu. De l'ordre de 5Mo. Ensuite j'ai augmenté la valeur à 60s, juste pour voir. Et ben pareil, j'ai les mêmes taux d'écriture sauf que maintenant cela se passe chaque minute.
En regardant le source de dstat j'ai vu qu'il se base sur /proc/diskstats pour donner ces valeurs. Est-ce que ces valeurs tiennent compte aussi des écritures des métadonnées ? Parce que je vois que ça à priori, on n'écrit pas autant de données à la minute. D'ailleurs, un "watch df" le confirme, la partition n'augmente presque pas de taille.
Alors la situation est mieux qu'avant (depuis que j'ai désactivé le log caché) mais ce n'est toujours pas bon.
Avec iotop je vois que l'activité vient des process Apache. D'un coup ils se mettent à écrire environ 20Ko/s chacun. Pendant que ça se passe, avec dstat je vois le taux d'écriture grimper à 1500Ko/s, alors qu'autrement il est bas (entre 0 et 50Ko de temps en temps).
Cette valeur de 1500Ko/s est aussi reporté dans iotop.
Ce qui me paraît étrange c'est qu'en surveillant la taille du volume avec df, j'ai vu une différence d'à peine une soixantaine de Ko, pas de plusieurs Mo...
Évidemment 2 minutes après avoir posté je me suis aperçu que sur Debian pour je ne sais quelle raison il y a un log d'accès par défaut "other_vhosts_access.log". Je l'ai désactivé, je n'ai plus ces pics pour le moment. Je verrai encore ce soir, quand j'ai le plus de trafic, si cela se reproduit.
Effectivement, mais comme dit je vérifiais la consommation de mémoire via htop, vmstat, dstat au moment même où ça plantait. La valeur "used" ne bougeait pas ou très peu. Si ça avait été ça le problème, ça aurait été simple :)
De plus, on atteint sans problème 3000 process Apache avec cette configuration, la plupart consomment quasiment rien en mémoire (et notre script php le plus appelé travaille sur peu de données, de l'ordre de quelques Ko).
Mais grâce à l'explication de neologix plus bas, j'ai cherché les effets sur Apache du passage de la variable vm.overcommit_memory à 2. Et d'après un post sur serverfault.com, ça ne fait pas bon ménage.
Bon j'ai pas pu tester en revenant sur un KeepAliveTimeout à 15, mais rien que là en observant le fichier /proc/meminfo j'ai vu que la valeur de Committed_AS a tendance à dépasser CommitLimit.
Si j'ai bien compris ce que j'ai lu, en passant overcommit_memory à 2 ça serait impossible, ce qui expliquerait les problèmes d'allocation mémoire commun à Postgresql, Apache, PHP et exim. Ça me parait le plus probable.
En tout cas cette histoire m'apprendra à faire de la pré-optimisation...
Si je comprends bien, actuellement 17Go sont alloués mais seulement 4 utilisés. J'ai jamais monitoré cette valeur, tout les outils que j'ai utilisé (vmstat, dstat, htop, top) n'affichent que le used/cache.
J'ai bien envie de tester en monitorant meminfo pour en avoir le coeur net mais comme c'est une machine de prod et qu'on a contourné le problème je pense pas que mon chef sera d'accord.
Ce n'est pas les paramètres par défaut, j'avais appliqué ces changements en me basant sur les recommandations du livre "Postgresql 9.0 High Performance".
J'aurai approuvé, seulement lors de ces problèmes je ne voyais AUCUNE augmentation de la consommation mémoire via htop. Alors à moins que htop / top / free mentent, je doute que j'ai réellement utilisé trop de mémoire.
De plus le 512Mo par process PHP est une limite, pas une valeur toujours atteinte; on a aucun script qui va consommer jusqu'à 512Mo de mémoire.
Bon, on a baissé le KeepAliveTimeout de 15 à 2s et ça a l'air de fonctionner. On va peut-être essayer sans KeepAlive vu que la machine peut tenir la charge. M'enfin ça n'explique pas pourquoi avec le KeepAlive on a ces problèmes.
A noter que tant que j'ai pas de trafic sur apache, postgresql n'a aucun problème.
J'ai essayé de changer les paramètres de ulimit (comme le max locked memory) en mettant les paramètres de mon ancien serveur qui fonctionne, ça n'a rien changé.
A noter aussi que là j'utilise apache avec le MPM prefork, et qu'avant hier quand j'utilisais le MPM event avec PHP en CGI je n'avais pas ces problèmes.
Avant j'utilisais Vimperator, c'est très bien, mais j'étais pas fan de la navigation clavier, je trouve que je suis plus lent qu'avec la souris.
Bon maintenant la question se pose pas, Vimperator est pas dispo pour FF4
Je suis passé de KDE 4.4 à Awesome, ça m'a changé la vie. Je n'utilise quasiment plus la souris maintenant, sauf quand je navigue sur le ternet. Le tiling c'est super, je me passe complètement d'une console multi onglets, j'utilise uniquement xterm.
En plus de tout ça c'est très facilement customisable via Lua pour afficher potentiellement n'importe quoi.
# Documentation
Posté par Sphax . En réponse au journal Rah nice && cgroups. Évalué à 2.
Voir ici
J'ai essayé vite fait avec un groupe à 100 cpu share et un à 900.
100 shares:
900 shares:
[^] # Re: augmenter le swap ?
Posté par Sphax . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1.
La taille du swap je l'ai choisi un peu au pif pour être honnête. Je voulais pas respecter la "règle" de la moitié de la ram en swap, parce que mon espace disque est limité, et je me disais aussi qu'on va jamais consommer autant de ram.
Comme dit plus bas, cette machine à la base n'était pas prévu pour faire tourner des vm, elle devait uniquement faire tourner un postgresql pas vraiment chargé.
Depuis, on a eu un nouveau projet et on a du utiliser cette machine, et le temps qu'on ait accès à des machines physiques pour nos process java, j'ai décidé d'y faire tourner quelques vm.
Jusqu'à présent ça marchait sans que rien ne se fasse tuer, mais ces dernières semaines la charge sur postgresql a augmenté, ainsi que la charge sur la vm avec Redis dessus, et le oom killer a commencé à frapper.
Bref, la config de cette machine est certainement pas parfaite, mais à la base je suis développeur, et ça a été mis en place en peu de temps.
Si je supprime le swap ça va pas accentuer le problème, vu qu'il est utilisé à 100% ?
[^] # Re: vmware / cache disque
Posté par Sphax . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1.
Ce sont de simples fichiers sur un volume raid. Ce sont pas des vm qui font beaucoup d'io, à part un fichier de log d'un process java.
Si ça avait été prévu dès le départ de faire tourner des vm j'aurai certainement fait du lvm, mais à la base cette machine devait que de la base de données.
Apparemment il y a cette option pour désactiver le cache, mais je viens de vérifier et le cache est déjà désactivé sur mes vm. Ou bien je comprends mal ce que cette option est censé faire.
[^] # Re: KSM ?
Posté par Sphax . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1.
Merci de ta proposition, mais c'était déjà activé.
[^] # Re: Détails ?
Posté par Sphax . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1. Dernière modification le 06 janvier 2012 à 16:31.
Je n'ai aucune ligne de ce genre dans mon syslog ou mon kern.log malheureusement, ce que j'ai fourni plus haut c'est tout ce que j'ai avec la liste de processus.
J'ai 6 vm avec 4096mo, une vm avec 2048 mo et une vm avec 8192 mo de RAM. 34816mo en tout.
La quantité de cache me paraît phénoménale, mais c'est sans doute normal.
Je pourrais rajouter de la RAM (c'est une grosse machine), mais pour le moment j'ai coupé 3 vm ce qui me donne un peu de marge, et ai transféré les services sur d'autres machines.
A tout hasard, est-il possible de connaître le détail de ce qui est en cache ?
EDIT: je viens de refaire un drop_caches pour voir, il vient de passer de 39 à 25go...
Merci de ton aide en tout cas.
[^] # Re: Détails ?
Posté par Sphax . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1.
Je suis en 64 bits.
Le drop_caches m'a fait gagner environ 3 go de mémoire, je suis à 26Go de cache.
Concernant le détail de l'oom killer je ne suis pas sûr de ce que tu souhaites comme informations, donc voilà ce que j'ai dans mon syslog: http://pastie.org/3137082
Je n'ai pas inclus une liste de processus avec plusieurs centaines d'entrées de ce type:
Je sais pas si c'est pertinent mais je peux le fournir si besoin.
[^] # Re: C'est du bon
Posté par Sphax . En réponse au journal Les SSD. Évalué à 2.
J'ai oublié de préciser je suis sur Windows. Avec un jeu comme Rift ou Mass Effect 2 qui prend chacun plus de 10go, c'est vite tendu. J'y ai mis aussi mes machines VirtualBox, ainsi qu'une petite partition avec une debian. Il me reste environ 50 go de libre, et encore j'ai du faire du ménage, avant j'avais beaucoup plus de jeux installés.
# C'est du bon
Posté par Sphax . En réponse au journal Les SSD. Évalué à 9.
Contrairement à ce qui a été dit plus haut, on a beaucoup à gagner avec un SSD. Je viens de changer mon disque système (un 7200rpm basique) contre un Crucial M4 128go, et je regrette pas du tout mon achat. Certes ça fait cher le Go (210€ le mien), mais pour une utilisation basique c'est le meilleur achat possible après la ram.
Par exemple, j'ai divisé mon temps de boot par 2, la plupart des applications se lancent instantanément, le chargement dans les jeux est plus rapide, etc
Pour la fiabilité, je vais pas en parler vu que ça fait même pas 2 semaines que j'ai un SSD.
Et un petit retour en utilisation serveur: depuis février dans ma boîte on a un serveur HP avec 2 SSD HP de 60Go monté en raid 1 via la carte raid. Autant ça marche bien, autant les performances sont pas super. En testant avec bonnie++ sur ce volume de SSD, et en comparant avec un volume de HDD 15k rpm aussi en raid 1, les chiffres étaient très similaires...Maintenant, savoir si c'est la carte raid qui nous bride d'une façon ou d'une autre, j'ai pas cherché plus loin.
Côté fiabilité, ce volume contient un tablespace PostgreSQL avec plus de 3 millions de lignes insérées chaque jour, et pour le moment les disques sont en vie.
[^] # Re: Makefile
Posté par Sphax . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 1.
Merci, j'aurai du chercher avec "make" plutôt que "makefile".
[^] # Re: Makefile
Posté par Sphax . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 0.
J'ai beau chercher, je ne vois pas où Linus (ni quelqu'un d'autre) parle de make, mais peut-être que je cherche mal. Tu aurais un lien ?
# Suite
Posté par Sphax . En réponse au message Apache qui cause des pics d'accès disque. Évalué à 1.
Alors, j'ai du nouveau.
J'ai remarqué que les écritures sur disque intervenait toutes les 30s. J'ai pensé aux intervalles que l'on peut tuner dans le noyau (vm.dirty_expire_centisecs et vm.dirty_writeback_centisecs), et bingo, dirty_expire_centisecs est par défaut à 300 100ème de seconde, soit 30s.
En pensant réduire le volume de données écrites, et écrire plus souvent mais moins longtemps, j'ai baissé ce paramètre à 10s. A mon étonnemment, les valeurs écrites n'ont pas changé, ou peu. De l'ordre de 5Mo. Ensuite j'ai augmenté la valeur à 60s, juste pour voir. Et ben pareil, j'ai les mêmes taux d'écriture sauf que maintenant cela se passe chaque minute.
En regardant le source de dstat j'ai vu qu'il se base sur /proc/diskstats pour donner ces valeurs. Est-ce que ces valeurs tiennent compte aussi des écritures des métadonnées ? Parce que je vois que ça à priori, on n'écrit pas autant de données à la minute. D'ailleurs, un "watch df" le confirme, la partition n'augmente presque pas de taille.
[^] # Re: /proc/sys/vm/block_dump et iotop
Posté par Sphax . En réponse au message Apache qui cause des pics d'accès disque. Évalué à 1.
Alors la situation est mieux qu'avant (depuis que j'ai désactivé le log caché) mais ce n'est toujours pas bon.
Avec iotop je vois que l'activité vient des process Apache. D'un coup ils se mettent à écrire environ 20Ko/s chacun. Pendant que ça se passe, avec dstat je vois le taux d'écriture grimper à 1500Ko/s, alors qu'autrement il est bas (entre 0 et 50Ko de temps en temps). Cette valeur de 1500Ko/s est aussi reporté dans iotop.
Ce qui me paraît étrange c'est qu'en surveillant la taille du volume avec df, j'ai vu une différence d'à peine une soixantaine de Ko, pas de plusieurs Mo...
# Suite
Posté par Sphax . En réponse au message Apache qui cause des pics d'accès disque. Évalué à 1.
Évidemment 2 minutes après avoir posté je me suis aperçu que sur Debian pour je ne sais quelle raison il y a un log d'accès par défaut "other_vhosts_access.log". Je l'ai désactivé, je n'ai plus ces pics pour le moment. Je verrai encore ce soir, quand j'ai le plus de trafic, si cela se reproduit.
[^] # Re: Suite
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
De plus, on atteint sans problème 3000 process Apache avec cette configuration, la plupart consomment quasiment rien en mémoire (et notre script php le plus appelé travaille sur peu de données, de l'ordre de quelques Ko).
Mais grâce à l'explication de neologix plus bas, j'ai cherché les effets sur Apache du passage de la variable vm.overcommit_memory à 2. Et d'après un post sur serverfault.com, ça ne fait pas bon ménage.
Bon j'ai pas pu tester en revenant sur un KeepAliveTimeout à 15, mais rien que là en observant le fichier /proc/meminfo j'ai vu que la valeur de Committed_AS a tendance à dépasser CommitLimit.
Si j'ai bien compris ce que j'ai lu, en passant overcommit_memory à 2 ça serait impossible, ce qui expliquerait les problèmes d'allocation mémoire commun à Postgresql, Apache, PHP et exim. Ça me parait le plus probable.
En tout cas cette histoire m'apprendra à faire de la pré-optimisation...
[^] # Re: attention à l'overcommitting
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
J'ai bien envie de tester en monitorant meminfo pour en avoir le coeur net mais comme c'est une machine de prod et qu'on a contourné le problème je pense pas que mon chef sera d'accord.
En tout cas merci pour les explications.
[^] # Re: attention à l'overcommitting
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
Ce n'est pas les paramètres par défaut, j'avais appliqué ces changements en me basant sur les recommandations du livre "Postgresql 9.0 High Performance".
/proc/meminfo:
Committed_AS: 18687308 kB
Ça fait 17Go, mais que représente cette ligne ?
[^] # Re: Suite
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
De plus le 512Mo par process PHP est une limite, pas une valeur toujours atteinte; on a aucun script qui va consommer jusqu'à 512Mo de mémoire.
Concernant le MaxRequestsPerChild on est à 10000.
# Suite
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
[^] # Re: Question bête…
Posté par Sphax . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
A noter que tant que j'ai pas de trafic sur apache, postgresql n'a aucun problème.
J'ai essayé de changer les paramètres de ulimit (comme le max locked memory) en mettant les paramètres de mon ancien serveur qui fonctionne, ça n'a rien changé.
A noter aussi que là j'utilise apache avec le MPM prefork, et qu'avant hier quand j'utilisais le MPM event avec PHP en CGI je n'avais pas ces problèmes.
[^] # Re: ip_relay
Posté par Sphax . En réponse au message Limitation de la bande passante avec tc. Évalué à 1.
[^] # Re: tc limite la bande passante qui sort
Posté par Sphax . En réponse au message Limitation de la bande passante avec tc. Évalué à 1.
J'ai pas spécialement envie de mettre un iptables/tc sur le serveur de prod donc je vais voir du côté d'ifb.
Merci.
# Merci !
Posté par Sphax . En réponse au journal Sortie de QtTvDB 0.2, Series Watcher 0.1.1, Lugdulo'V 0.3 and QCommandLine 0.2. Évalué à 2.
[^] # Re: Wireshark
Posté par Sphax . En réponse au journal Swisscom / coupure d'accès ADSL sans préavis. Évalué à 4.
[^] # Re: Awesome
Posté par Sphax . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.
Bon maintenant la question se pose pas, Vimperator est pas dispo pour FF4
# Awesome
Posté par Sphax . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.
- Vim
- Awesome
Je suis passé de KDE 4.4 à Awesome, ça m'a changé la vie. Je n'utilise quasiment plus la souris maintenant, sauf quand je navigue sur le ternet. Le tiling c'est super, je me passe complètement d'une console multi onglets, j'utilise uniquement xterm.
En plus de tout ça c'est très facilement customisable via Lua pour afficher potentiellement n'importe quoi.