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.
Forum Linux.debian/ubuntu 32 ou 64 bits
26
juil.
2010
# PS pour Info
Posté par phoenix (site web personnel) . Évalué à 2.
# capilotractage
Posté par NeoX . Évalué à 6.
à 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
[^] # Re: capilotractage
Posté par William Briand . Évalué à 2.
# RAM / Pagination / Buffer cache... je m'égare...
Posté par ze_lionix (site web personnel) . Évalué à 3.
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 fanto30 . Évalué à 2.
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 fanto30 . Évalué à 5.
C'est pas la taille qui compte ...
# Différence de performances
Posté par yellowiscool . Évalué à 6.
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 Florian.J . Évalué à 8.
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 ze_lionix (site web personnel) . Évalué à 1.
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 BAud (site web personnel) . Évalué à 2.
sur AIX, alors ? non ? (pour le swap surtout...)
[^] # Re: Petite erreur mon cher...
Posté par ze_lionix (site web personnel) . Évalué à 3.
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 BAud (site web personnel) . Évalué à 2.
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 ze_lionix (site web personnel) . Évalué à 2.
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 Krunch (site web personnel) . Évalué à 3.
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 phoenix (site web personnel) . Évalué à 2.
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 NeoX . É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 Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 32 bits
Posté par phoenix (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.