Forum Linux.debian/ubuntu 32 ou 64 bits

Posté par (page perso) .
Tags : aucun
3
26
juil.
2010
Bonjour,

je souhaite installer un serveur WEB (et mail + antivirus, ...) sur une machine. J'ai le choix entre 32 et 64 bits.

Ma question se porte sur la mémoire et sur le choix du nombre de bits.

La taille des pointeurs étant 2 fois plus grande en 64 bits, et étant limité à 2Go de mémoire (et je n'aurais jamais plus sur cette machine). Dois-je prendre du 32 bit ou du 64 bits ?

Si je prend du 64 bits, est-ce que je ne risque pas d'utiliser plus de mémoire qu'il n'en faut pour mes besoins ?
Si je prend du 32 bits, est-ce que je ne vais pas avoir une perte de performance ?

Merci d'avance de vos réponses.
  • # PS pour Info

    Posté par (page perso) . Évalué à 2.

    Je penche plutôt pour le 64 bits, mais je pose la question pour voir si je ne vais pas gagner un peu de RAM en 32 bits.
  • # capilotractage

    Posté par . Évalué à 6.

    la question de perf/memoire avec une machine standard et 2Go de ram,

    à mon avis tu ne verras AUCUNE difference.

    32/64bits, ca va jouer sur les environnements effectuant des gros calculs, et ou utilisant beaucoup de RAM (retouche image par exemple).

    en dehors de ca, y pas grands choses à gagner à passer en 64bits sur une machine de 2Go
  • # RAM / Pagination / Buffer cache... je m'égare...

    Posté par (page perso) . Évalué à 3.

    En 32 bits tu ne peux allouer que 2^32 ~= 4Go de mémoire paginée...
    Et en 64 bit ben tu peux aller jusqu'a 2^64 et je te laisse faire chauffer xcalc ou autre !

    Vu que tu ne vas pas monter au delà de 2 Go 32 bits suffit...

    Pas de différence de perfermance entre 32 et 64 bits à ma connaissance...

    Ce qui change, c'est quand on a un max de RAM sur une machine :
    - tu peux encaisser les process "monstres bouffe RAM" et en mettre un wagon sur une même machine...
    - tu as un gros buffer-cache pour aller plus vite. En gros quand tu as du mou, le pinux il fait des caches pour accélérer les I/O ( cache disque ) , c'est ce qui fait que même quand rien ne tourne tu as quasiment toute la mémoire utilisée ! ( cf "cached" en bas a droite dans Top ! )

    Mais à quantité de RAM égale ça change rien à ma connaissance !

    Fuse : j'en Use et Abuse !

    • [^] # Re: RAM / Pagination / Buffer cache... je m'égare...

      Posté par . Évalué à 2.

      Et si mes souvenirs sont bons, c'est surtout 4 (en fait 3, 1Go est "pris" par le système) par processus.

      Tu peux avoir 512 Mo de RAM, et ton processus va quand même avoir "accès" à 4 G0 (en fait 3).
      Et c'est là que le swap intervient, pour faire sa soupe avec toutes ces pages mémoire.

      En gros, c'est juste l'espace mémoire adressable par le processus qui est impacté par les 32 ou 64 bits d'adresses.

      Certains instructions des x86 sont un poil plus performantes en 64 bits, ça leur permet de manipuler une quantité de données plus importante dans le même cycle processeur.
      Me suis laissé dire que les miss dans les caches instructions/données des processeurs étaient de ce fait plus gourmand en 64 bits.

      AMHA (que je partage avec moi-même) pas vraiment d'intérêt/avantage pour une machine d'utilisation "standard" d'être en 64 bits.
  • # On le repetera jamais assez

    Posté par . Évalué à 5.

    La taille des pointeurs étant 2 fois plus grande en 64 bits

    C'est pas la taille qui compte ...
  • # Différence de performances

    Posté par (page perso) . Évalué à 6.

    Pour ma part, je choisirais la version 64 bits.

    Remplir 2go de ram en 32 bits avec un serveur web, à moins d'utiliser java ou ruby, il faut le faire.

    Donc autant utiliser 64 bits qui améliore les performances même si ce n'est pas très facile à voir à l'œil nu.

    En effet, à moins d'utiliser gentoo, les distributions 32 bits classiques compilent les applications sans optimisations spécifiques au processeurs récents. Les différents processeurs 64 bits en x86 partagent un même lot d'optimisation très efficace. Une debian 64 bits a des paquets compilé avec plus d'optimisation, en plus de la faible amélioration des performances due au passage en 64 bits.

    C'est très léger, mais tant qu'à faire, autant utiliser ce qui est le plus performant.

    Puis si un jour il t'arrive de vouloir encoder une vidéo, tu vas voir la différence. Pas besoin de compter là :-)

    Envoyé depuis mon lapin.

  • # Retour d'expérience.

    Posté par . Évalué à 8.

    Ca tombe bien, j'ai rédigé il y a quelques temps de ça un article pour jeuxlinux.fr sur le sujet:

    http://diablo150.ath.cx/Florian/Comparatif-mem/html/comparat(...)

    Il n'a toujours pas été validé, je pourrais le faire moi même mais je vais pas aller contre l'avis du chef ^^
    Le contenu n'engage donc que moi, pas jeuxlinux.fr

    Que ça soit pour un serveur ou un ordinateur de bureau je pencherais plutôt pour le 64 pour plusieurs raisons.

    Pour commencer c'est en théorie plus sécurisé sur certains aspects:
    http://fr.wikipedia.org/wiki/NX_bit

    Et puis a grande majorité des crackers ont pour cible des windowsiens qui tournent sur x86. L'architecture est archi connue (ansi que ses défauts) depuis longtemps et la plupart des gens l'utilisent, donc il est logique que pour le moment les systèmes x64 soit un peu épargnés. Ca tiens à pas grand chose mais c'est un fait. :p
    Tout comme Linux est un système plus sécurisé par rapport à windows pour plein de raisons, mais la principale est sans doute parce que windows est une cible évidente comparé à Linux.

    Ensuite si l'espace virtuel adressable par processus reste limité à 3go sous Linux quelque soit l'architecture, sur x64 le système peut gérer un quantité de mémoire quasi infinie. En tout cas pour les deux prochaines décénnies, au moins ^^
    Encore que sur ce point là tu t'en fout un peu.

    C'est également l'occasion de l'implémentation d'un tas de nouvelles instructions et un nettoyage de l'architecture. Je pense que c'est un grosse évolution des compatibles PC similaire à l'arrivée du Pentium il y a 15 ans.

    Après si tu cherche un graphique qui te dira qu'un processeur x64 exécute ses instructions plus rapidement qu'un x86, j'ai bien peur que tu risque de chercher longtemps.
    Le x64 peut améliorer les performances à condition d'avoir un compilateur qui optimise en utilisant au maximum les instructions spécifiques à l'architecture pour réélement profiter de ses apports. Et ça c'est pas gagné (gcc tourne sur trop d'architectures pour prétendre l'exhaustivité).
    Si tu as un processeur Intel, que les applications ne doivent tourner que chez toi, que tu te fout d'avoir un compilateur qui se branle de C et qu'il soit propriétaire avec ça, Icc (le compilo C++ d'Intel) peut t'apporter ça. Il y a pas plus performant dans ce cas précis.

    Pour tout le reste il y a gcc :)

    Quand même un petit comparatif x86/x86_64 (avec des graphiques tout en couleur) que j'ai fais il y a...pfiou plus de 3 ans déjà !
    http://www.jeuxlinux.fr/a111-Comparatif_x86_64_contre_x86.ht(...)

    Pour finir je gage que c'est pour une utilisation personnelle, donc autant passer dès maintenant au x64, c'est l'avenir.
    • [^] # Petite erreur mon cher...

      Posté par (page perso) . Évalué à 1.

      "Ensuite si l'espace virtuel adressable par processus reste limité à 3go sous Linux quelque soit l'architecture,"

      Ceci est faux : en 64 bit il n'y a plus cette "limitation" ....
      D'ailleurs ce n'est pas une limite vu que cela se change avec le paramètre de tuning HIGHMEM du kernel 32 bit de souvenir...

      => J'ai vu du processus mono thread a 7Go de footprint dans mon ancien taff...

      => J'ai une base de donnée qui bouffe 90 Go de ram et 27 Go de swap sous les yeux ( sur 15 processus ca fait environ 6Go / proc )

      Fuse : j'en Use et Abuse !

      • [^] # Re: Petite erreur mon cher...

        Posté par (page perso) . Évalué à 2.

        => J'ai une base de donnée qui bouffe 90 Go de ram et 27 Go de swap sous les yeux ( sur 15 processus ca fait environ 6Go / proc )

        sur AIX, alors ? non ? (pour le swap surtout...)
        • [^] # Re: Petite erreur mon cher...

          Posté par (page perso) . Évalué à 3.

          Ben non sous Linux en RHEL avec hudge mem et tout....
          On a 32Go de swap et ça a jamais posé de soucis en 2 ans...

          Il y a des problème avec gros swap sous linux ?

          Fuse : j'en Use et Abuse !

          • [^] # Re: Petite erreur mon cher...

            Posté par (page perso) . Évalué à 2.

            Il y a des problème avec gros swap sous linux ?

            hum non, mais ce n'est pas la "stratégie" habituelle :
            - sous AIX il envoie assez vite dans le swap dès qu'il détecte que ce n'est pas vraiment utilisé, pas de souci à avoir du swap donc
            - sous GNU/Linux, la RAM est remplie à satiété et quand ça devient nécessaire envoie vers le swap (qui peut être interprété comme un indicateur de manque de RAM en régime stabilisé...). Cela dépend du paramétrage après, sans plus d'info pas moyen d'en tirer vraiment de conclusion ;-) À toi de voir si tu as un peu trop d'I/O wait en permanence lors des traitements, ce qui indiquerait qu'il bascule un peu trop entre swap et RAM. Si c'est ponctuel (passage du transactionnel au mode batch le soir et inversement le matin), c'est une bonne utilisation du cache àmha.
            sar est ton ami pour recueillir quelques stats sur une semaine pour étudier le comportement ;-)
            • [^] # Re: Petite erreur mon cher...

              Posté par (page perso) . Évalué à 2.

              Je suis complètement en phase sur le coté "Swap + wait IO = manque de RAM".... C'est le mode critique swap in / swap out continue, qui pénalise en plus la CPU, et suivant le type d'application peut finir en oom killer... :-/

              Sans être un spécialiste je pense que les pages qui sont peux accédées sont placées en swap au bout d'un certain temps pour libérer de la mémoire vive ( pour proc ou buffer cache ). Et donc une utilisation importante du swap sans I/O n'est pas inquiétante !
              Ce qu'on constate c'est que même en charge on est toujours aux environs de 25Go de swap, mais les quelques petits pics de wait ne dépassent jamais 6% de CPU... Ca tourne ! :o)

              J'ai découvert sar ( honte à moi ) il y a seulement 2 ans....
              Pas intrusif pour deux sous à 5s de sampling, et j'adore la petite option "suit ce processus "

              SAR c'est bien !

              Fuse : j'en Use et Abuse !

  • # It's a bird! It's a plane! It's the point flying over your head!

    Posté par (page perso) . Évalué à 3.

    Pour la vaste majorité des applications, l'intérêt de x86_64 par rapport à i686 c'est qu'il y a 16 registres disponibles au lieu de 8. N'importe quel compilateur digne de ce nom est capable d'exploiter ça et ça a un impact sur n'importe quelle application plus compliquée que Hello, World!\n indépendamment de la quantité de mémoire qu'elle utilise.

    http://en.wikipedia.org/wiki/X86-64#Architectural_features

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # 32 bits

    Posté par (page perso) . Évalué à 2.

    Pour info, j'ai choisis le 32 bits pour dire de tester (je migre depuis un serveur où j'étais en 64 bits et ou la moitié de mon swap était remplis).

    Niveau perf (vitesse d'appli), ce que je remarque, c'est que je ne suis pas plus lent (peut-être plus rapide, mais je ne suis pas sur, et si c'est le cas, c'est parce que je n'ai plus de swap).

    La en faisant le test en 32 bits, sur les 2Go de mémoire, 500Mo sont utilisé pour les applis, le reste est utilisé pour le cache.

    En 64bits, avec 1Go de mémoire, j'avais 1Go d'applis (dont une partie dans le swap), et 2 à 300Mo de cache.

    Pour l'instant j'ai l'impression de consommer moins (apache, php, python, postfix, spamassassin, clamav, mysql).

    Peut-être que cela tient aussi du fait que j'ai migrés de postgresql à mysql car les bases sont assez petites et je trouvais postgresql assez gros.

    Mon choix du 32 bits c'est aussi fait sur le fait que je pourrais faire tourner une copie exacte dans une VM (en effet les machines 64 bits que j'ai chez moi, n'ont pas les options proc pour faire de la virtualisation, et je dois donc me cantonner à faire de la virtualisation 32bits).

    Bon cela fait peu de temps que le serveur tourne (alors que l'autre avait plusieurs mois de bouteille). Je referai un état des lieux d'ici quelques mois.
    • [^] # Re: 32 bits

      Posté par . Évalué à 2.

      Mon choix du 32 bits c'est aussi fait sur le fait que je pourrais faire tourner une copie exacte dans une VM (en effet les machines 64 bits que j'ai chez moi, n'ont pas les options proc pour faire de la virtualisation, et je dois donc me cantonner à faire de la virtualisation 32bits).

      il me semblait qu'une machine 32bits pouvait virtualiser uniquement 32bits
      mais qu'une machine 64bits pour virtualiser du 32 mais aussi du 64bits.

      et cela sans avoir les instructions de virtualisation processeur.
      • [^] # Re: 32 bits

        Posté par (page perso) . Évalué à 2.

        Selon la technologie de virtualisation utilisée, une VM 64 bits sur un host 32 bits est possible. Non pas que ça soit super efficace...

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: 32 bits

          Posté par (page perso) . Évalué à 1.

          J'utilisai VirtualBox mais apparemment sur du QEMU c'est pareille. QEMU est capable de simuler un proc 32 bits. Mais pas de simuler un 64bits. Donc a moins que le processeur ne prenne en charge les instructions de para-virtualisation, je reste en virtualisation avec "simulation" du processeur. Et je ne peux donc utiliser qu'un processeur 32bits.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.