bonjour,
j’oubliai,
system request écrit sur le swap pour un panic,
bon tout le monde n’utilise pas le produit!
donc le swap est utile!!!
A+
JB1
[quote=“PascalHambourg”]
tmpfs, pas ramfs. La distinction est de taille car ramfs a deux gros inconvénients par rapport à tmpfs qui en est une amélioration :
- ramfs n’est pas swappable,
- on ne peut pas limiter sa taille, donc il peut occuper toute la RAM et étrangler le système.
C’est d’autant plus dangereux de l’utiliser pour /tmp que n’importe quel utilisateur peut y écrire.[/quote]
Oui, tu m’avais déjà fait la remarque, j’emploie l’un pour l’autre ce qui est une erreur. Mais dans les lignes suggérées de fstab comme dans ce que fait l’initialisation du système sur une debian (comme dans CefAgreg), c’est du tmpfs. Donc pour Ricardo, lit tmpfs au lieu de ramfs dans mes remarques.
Pour Ed et lol: C’est curieux car j’aurais eu tendance à privilégier le swap sur un serveur, en cas de grosses demandes exceptionnelles, la machine arrive à s’en sortir en mettant le temps et surtout est capable de répondre à une requête ssh. Ainsi une fois, quelqu’un avait utilisé comme domaine d’origine d’un spam un de mes domaines et ce durant août. Le serveur a eu affaire à une cadence de 60000 mails/jour et spamassassin comme clamav ont fini par bouffer la mémoire mais pas complètement le swap. À raison d’une commande par 10 minutes, j’ai pu rattraper la chose. Sans swap, tu ne t’aperçois de rien entre le moment où tu as de la mémoire et où tout est gelé (le noyau supprime des processus à l’arrache si il a le temps). Si tu n’as pas accès physique à la machine, le swap me parait indispensable.
Pour résumer :
- sur un desktop avec des Go de Ram en pagaille : on peut se passer de swap
- sur un serveur : il vaut mieux jouer la sécurité et garder un peu de swap
pas compliqué 
OK, enregistré.
En l’occurrence, il s’agit d’une machine bureau NON serveur.
[quote=“agentsteel”]Pour résumer :
- sur un desktop avec des Go de Ram en pagaille : on peut se passer de swap
- sur un serveur : il vaut mieux jouer la sécurité et garder un peu de swap
pas compliqué [/quote]
Je vais me rallier à la majorité : pas de swap.
Je suppose que si l’avenir me donnait tort, il est toujours possible de créer une partoche swap sur un DD externe, non 
Mieux, tu peux simplement créer un fichier, et le rajouter en swap:
root@portos:/tmp# dd if=/dev/zero of=/sw bs=500M count=1
root@portos:/tmp# mkswap -c /sw
Setting up swapspace version 1, size = 511996 KiB
no label, UUID=083d1027-88dc-455c-b462-2299ac3280d8
root@portos:/tmp# swapon /sw
root@portos:/tmp# free
total used free shared buffers cached
Mem: 3959420 2775372 1184048 0 255708 1205800
-/+ buffers/cache: 1313864 2645556
Swap: 3791864 0 3791864
root@portos:/tmp# swapo
swapoff swapon
root@portos:/tmp# swapoff /sw
root@portos:/tmp# free
total used free shared buffers cached
Mem: 3959420 2778892 1180528 0 255732 1207804
-/+ buffers/cache: 1315356 2644064
Swap: 3279868 0 3279868
root@portos:/tmp#
Pour les concours, lorsque des candidats devenaient soudain gourmand en mémoire, j’avais quelques clefs USB préformattées avec un swap (de 4G donc) que je mettais sur leur machine et montais à la volée. Cela a rendu de grands services (c’est gros une image parfois).
fran.b: en fait, moi je pense l’exact oposé! Si aucun accès à la machine physique (95% du temps pour moi) surtout pas de swap! Vaut mieux que le kernel défonce les processus qui mangent trop et que la machine soit utilisable plutôt que impossible d’y lancer un bash 
Mais bon c’est histoire de gout j’imagine.
Après effectivement, le swap peut être utilisé par d’autre sous-système. Dans ce cas, partition de swap avec swapiness=0 ne me parait pas idiot.
Pour le swap dans un fichier, c’est quand même fortement déconseillé 
(c’est le derniers recours!)
Ben le problème c’est que souvent le processus le plus gourmand en mémoire est named (ainsi sur deux serveurs importants avec des DNS dessus il est respectivement en second (derrière spamd) et en premier). Sur une troisième il est vrai, c’est mysql puis des instances d’apache qui sont avant named (c’est du à phpBB)). Si named est tué, la machine se retrouve en carafe d’où ma volonté d’éviter ça.
En effet j’hésite à mettre un deuxième DNS dans le resolv.conf car les deux DNS ont des configurations différentes (views) avec des réponses différentes suivant l’origine de la requête. Du coup deux DNS dans le resolv.conf pourraient donner deux réponses différentes et j’ignore les implications que ça peut avoir.
[quote=“scorpio81”][quote=“agentsteel”]
l’installeur Debian actuel détecte-t’il automatiquement si le disque est de type SSD et dans un tel cas, effectue-t’il automatiquement certaines optimisations?[/quote]
Si on se réfère au man mount
[quote]
diratime
Mettre à jour les horodatages d’accès d’inœuds sur ce système de fichiers. Option par défaut.
noatime
Ne pas mettre à jour les horodatages d’accès aux inœuds sur ce système de fichiers (accès plus rapide pour des serveurs de news par exemple).
relatime
Mettre à jour les horodatages d’accès par rapport à l’horodatage de modification. L’horodatage d’accès est mis à jour seulement si le précédent horodatage d’accès est antérieur à l’horodatage de modification (c’est équivalent à l’option noatime, mais permet aux applications, comme mutt, de savoir si un fichier a été lu depuis sa dernière modification). Depuis Linux 2.6.30, le comportement par défaut du noyau est celui fourni par cette option (sauf si noatime a été indiquée), et l’option strictatime est nécessaire pour obtenir les sémantiques traditionnelles. De plus, depuis Linux 2.6.30, la date de dernier accès au fichier est toujours mise à jour si elle est vielle de plus d’un jour.
discard/nodiscard
Contrôler si ext4 devrait envoyer des commandes discard et TRIM au périphérique bloc sous-jacent quand les blocs sont libérés. C’est utile pour les périphériques SSD et l’allocation fine et dynamique (« thinly-provisioned LUN »), mais n’est pas activé par défaut avant d’avoir été suffisamment essayé.[/quote][/quote]
noatime semble toujours d’actualité, ah 
Oulaaa ça va pas du tout 
cat /sys/fs/ext4/sda1/lifetime_write_kbytes
1251105617
cat /sys/fs/ext4/sda5/lifetime_write_kbytes
1193035127
sudo smartctl -A /dev/sda | awk '/Power_On_Hours/ {print $NF}'
87
cat /sys/fs/ext4/sda5/session_write_kbytes
1522180
cat /sys/fs/ext4/sda1/session_write_kbytes
748888
uptime
13:17:13 up 2:58, 4 users, load average: 0,06, 0,15, 0,24
Incohérent ton truc, ça suppose 28G/h soit 674G écrit par jour!!
Chez moi j’arriverais à 345M/heure ce qui me parait beaucoup mais envisageable.
Ta deuxième série donne 757M/h (chez moi 450M après recopie d’un fichier de 1,5G).
Ça fait beaucoup tout de même chez toi…
Oui beaucoup, et j’ai faillit tomber de ma chaise …
Apres quelques optimisations ça semble se calmer (discard,noatime,data=writeback), bricolage dans kde, et quelque tmpfs.
[14:18:17] laurent@debian:~$ df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 25G 16G 8,4G 65% /
udev 10M 0 10M 0% /dev
tmpfs 1,6G 488K 1,6G 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 3,2G 2,2M 3,2G 1% /run/shm
/dev/sda5 93G 38G 50G 44% /home
/dev/sdb1 459G 14G 422G 4% /media/backup
tmpfs 7,9G 0 7,9G 0% /var/cache/pbuilder/build
tmpfs 4,0G 0 4,0G 0% /var/cache/apt/archives
tmpfs 803M 488K 802M 1% /var/log
tmpfs 400M 44K 400M 1% /home/laurent/.cache
cat /sys/fs/ext4/sda1/session_write_kbytes
79496
cat /sys/fs/ext4/sda5/session_write_kbytes
92920
uptime
14:50:59 up 32 min, 3 users, load average: 0,44, 0,31, 0,20
@ suivre
[quote=“fran.b”]Incohérent ton truc, ça suppose 28G/h soit 674G écrit par jour!!
Chez moi j’arriverais à 345M/heure ce qui me parait beaucoup mais envisageable.
Ta deuxième série donne 757M/h (chez moi 450M après recopie d’un fichier de 1,5G).
Ça fait beaucoup tout de même chez toi…[/quote]
j’invente rien http://marc.info/?l=linux-ext4&m=125832311230638&w=2
En y réfléchissant j’ai eu un truc bizarre sur l’upgrade du firmware du SSD
Et après coup c’etais inutile! 
J’ai trouvé bizarre que la led hhd du boitier soit en permanence allumée alors que j’étais sur l’invite de commande sansung.
En gros je sais pas ce que ce truc a fait pendant les heures ou j’étais pas là!
[quote=“scorpio81”]…
En gros je sais pas ce que ce truc a fait pendant les heures ou j’étais pas là![/quote]
Et c’est pour ça que je n’aime pas que mes machines (sauf le serveur) tournent en permanence.
s2disk ou s2ram 
[quote=“ricardo”][quote=“scorpio81”]…
En gros je sais pas ce que ce truc a fait pendant les heures ou j’étais pas là![/quote]
Et c’est pour ça que je n’aime pas que mes machines (sauf le serveur) tournent en permanence.
s2disk ou s2ram [/quote]
Mouai …boff 
Je pense que farfouiller le www,les logs etcc m’ont évité de renvoyer ce SSD réputé fiable six mois apres !
Le besoin d’une swap avec beaucoup de mémoire dépend de ce que l’on fait sur sa machine.
En usage basique (bureautique, internet par exemple) la swap ne me semble pas nécessaire avec 8Go de Ram.
Comme je reviens d’un séjour au bord de la mer, j’ai fait la vidéo avec kdenlive (mélange de photos et de vidéo provenant d’appareils photo) de ce séjour soit 28 min de vidéo environ. En créant le fim vidéo en xvid j’ai eu jusqu’à 5Go de ram de pris et un tout petit peu de swap pris (3 fois rien, mais …) avec 12Go installé. Peut-être que cela passait, mais je n’en sais rien. J’ai 1,9 Go de swap.
Mais je n’ai pas de ssd, donc c’est peut-être différent avec ce genre de disque. Mes observations ne valent pas l’expertise technique de certains, bien sûr.
Un autre problème est que le noyau ne tue pas forcément les processus qui mangent le plus de mémoire. S’il tue sshd, on est mal…
Je me demande ce qu’il se passe une fois qu’on a consommé toute la RAM et qu’on n’a pas de swap, le système se fige ou y a encore moyen de reprendre la main ?
Le noyau flingue des processus suivant une stratégie pas toujours claire (le processus le plus gourmand mais les critères ne sont pas clairs). J’ai noté que si la demande est trop soudaine le système peut geler. Par exemple sur ClefAgreg sur des machines légères (512M) avec une grosse demande, une demande importante soudaine gèle la machine.