Sphax a écrit 138 commentaires

  • # Documentation

    Posté par  . 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:

    Dict        Compressing          |        Decompressing
          Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
           KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS
    
    22:    2281    91   2430   2219  |    30548   110   2512   2756
    23:    2684   113   2424   2735  |    39540   145   2493   3618
    24:    3412   148   2483   3669  |   108073   391   2562  10026
    25:    8092   348   2654   9239  |   105097   388   2548   9883
    ----------------------------------------------------------------
    Avr:          175   2498   4465               259   2528   6571
    Tot:          217   2513   5518
    
    

    900 shares:

    Dict        Compressing          |        Decompressing
          Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
           KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS
    
    22:    7785   299   2537   7573  |    92630   326   2565   8357
    23:    5872   232   2580   5983  |    88638   316   2568   8111
    24:    6840   284   2591   7355  |    91305   332   2549   8470
    25:    5969   259   2632   6815  |    90866   337   2534   8545
    ----------------------------------------------------------------
    Avr:          268   2585   6932               328   2554   8371
    Tot:          298   2569   7651
    
    
  • [^] # Re: augmenter le swap ?

    Posté par  . 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  . 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  . 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  . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1. Dernière modification le 06/01/12 à 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  . 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:

    Jan 5 18:38:28 bub6 kernel: [8046096.424174] [25613] 33 25613 47013 1180 34 0 0 apache2

    Je sais pas si c'est pertinent mais je peux le fournir si besoin.

  • [^] # Re: C'est du bon

    Posté par  . 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  . 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  . 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  . 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  . 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  . 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  . 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  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    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...
  • [^] # Re: attention à l'overcommitting

    Posté par  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    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.

    En tout cas merci pour les explications.
  • [^] # Re: attention à l'overcommitting

    Posté par  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    sysctl -a:
    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  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    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.

    Concernant le MaxRequestsPerChild on est à 10000.
  • # Suite

    Posté par  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    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.
  • [^] # Re: Question bête…

    Posté par  . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.

    Le système est bien en 64 bits.

    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  . En réponse au message Limitation de la bande passante avec tc. Évalué à 1.

    Merci, je vais voir ça.
  • [^] # Re: tc limite la bande passante qui sort

    Posté par  . En réponse au message Limitation de la bande passante avec tc. Évalué à 1.

    Effectivement c'est bien le trafic entrant que je veux limiter. Je savais pas que tc ne s'appliquait que sur le trafic sortant...

    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  . 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.

    Serieswatcher va bien me faciliter la vie, avec la dizaine de séries que je regarde.
  • [^] # Re: Wireshark

    Posté par  . En réponse au journal Swisscom / coupure d'accès ADSL sans préavis. Évalué à 4.

    Peut-être qu'elle n'était pas configuré en routeur. En tout cas chez Free, par défaut la Freebox n'est pas en mode routeur et tu es en accès direct.
  • [^] # Re: Awesome

    Posté par  . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.

    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
  • # Awesome

    Posté par  . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.

    - Git
    - 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.