Le lundi 2 mars 2015, 14:46:55 Hugues MORIN a écrit : >[…] > > bah ça dépend tellement de comment ta RAM est utilisée! Si > > ton système a tendance à swapper bah voilà, mais avec 64go, > > pour un serveur LAMP+email, si t'as pas de gros cache en > > RAM, c'est a priori assez large (de ce que j'en sais!) > > Donc d'apres vous, inutile de mettre 1.5 ou 2 fois la taille > de memoire en swap (comme vu sur certain site)
Note au passage : quand on cherche des infos sur des sujets qui ont la fâcheuse tendance à évoluer très rapidement (p.ex. le noyau), et qu’on trouve « certains sites » qui parlent du sujet qui nous intéresse, on pensera à vérifier, en plus des arguments, la date à laquelle les propos ont été tenus. Il y a plein de gens qui répètent et se battent sur le « X fois la RAM » avec, soit aucun argument, soit l’argument que Linux aurait dit, il y a vingt ans, que « deux fois, c’est bien », en oubliant que le noyau et les machines ont beaucoup évolué depuis et continuent d’évoluer (et Linus aussi). > Les 64Go suffisent amplement a un serveur LAMP (Linux Apache > MySQL PHP .... pour ceux qui comme moi on etait oblige de > chercher ;-) Si je vais mettre 1Go "par principe"... (.... > pour occuper un peu les 2To) Question fréquemment débattue… En tout cas, 1/65e de la RAM en swap, pour le dire crûment, c’est débile. (Et puis 1/2000e de plus ou de moins sur ton disque…) D’abord, il faut bien comprendre ce qu’est le swap : de la mémoire. De la mémoire sur un support très très lent (temps d’accès en ms, débit en centaine(s) de Mio/s) au lieu d’être sur un support très très rapide (temps d’accès en ns, ça fait un million de fois plus rapide, débit en Gio/s, ça fait (seulement) 10 à 100 fois plus rapide) mais de la mémoire quand même. Quand un processus qui demande de la mémoire, et qu’il n’y a plus de mémoire rapide disponible, le noyau swape quelques bouts de processus par-ci par-là, et utilise la mémoire rapide pour le processus. Ensuite, quand un processus avec des bouts swapés a besoin de ces bouts, ils sont remis en mémoire rapide et d’autres bouts d’autres processus sont mis en swap (si besoin). Donc, si un système utilise son swap régulièrement, si les processus sont sur le tourniquet, c’est qu’en fait il n’a pas assez de mémoire. (Ce n’est pas forcément un problème si le tourniquet ne devient pas une centrifugeuse et que le système reste suffisamment réactif.) Donc, en pratique, le swap, ça sert : — à ceux qui ont les moyens de s’acheter des disques mais pas de la RAM et pour lesquels la rapidité n’est pas un critère (petits systèmes, NAS, embarqué…) ; — à pallier un besoin de mémoire imprévu : le processus courant prend la mémoire rapide, les autres sont relégués en mémoire lente (swap), le système devient très lent, le sysadmin a le temps de voir ce qui cloche et de tuer le méchant processus avant que le système se mettent à tuer les gentils (même pas en rêve : le système est tellement lent qu’on n’a pas le temps de faire grand-chose). Ensuite, simplement, Linux sait très bien gérer un système qui n’a pas du tout de swap (et avoir 1/65e de la mémoire en swap pourrait bien le gêner plus qu’autre chose). Donc, pour un serveur¹, soit : — tu estimes préalablement tes besoins en mémoire (combien de sites en parallèle ? quelle activité ? quelle empreinte mémoire ? etc.), et tu devrais arriver à la conclusion que 64 Gio, c’est beaucoup trop ; — tu testes directement, sans swap, avec, dans l’absolu, un risque que ça coince (mais avec 64 Gio, c’est très peu probable) ; — tu testes avec un swap, avec la grande chance que tu te rendes compte que le swap n’est jamais utilisé. ¹ pour un poste personnel, c’est encore plus simple : pas de swap, jamais, sauf si on en a besoin pour le suspend2disk (et encore, un fichier de swap peut suffire). -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: https://lists.debian.org/2225494.BAkOqKTbEk@earendil
