Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

vérifier que /tmp est monté en ram

Nico89

Bonjour,

Je viens de mettre le répertoire /tmp en ram en ajoutant cette ligne à mon fstab :

tmpfs /tmp tmpfs defaults,relatime,mode=1777,nosuid,size=8192M 0 0

Tout d'abord comment savoir que le répertoire /tmp est bien monté en ram et plus sur le disque?
Ensuite j'aimerais pouvoir comparer les vitesses d'écriture/lecture lorsque le répertoire est monté sur le disque et lorsque le répertoire est monté en ram.
Pouvez-vous m'aider svp ?

Vobul

> Tout d'abord comment savoir que le répertoire /tmp est bien monté en ram et plus sur le disque?

mount|grep tmpfs

> Ensuite j'aimerais pouvoir comparer les vitesses d'écriture/lecture lorsque le répertoire est monté sur le disque et lorsque le répertoire est monté en ram.

Tu peux utiliser dd mais bon franchement la différence va être minime, et t'as pas vraiment besoin de vérifier ce genre de choses, la RAM est plus rapide qu'un SSD, y'a pas de secrets. Et /tmp c'est pas non plus le truc super critique, y'a que des petits fichiers pas très importants qui sont écrits là-dessus, donc que ça prenne 250 microsecondes ou 80, ou 3 franchement, OSEF! 🙂

Zakhar

Vobul a écritTu peux utiliser dd mais bon franchement la différence va être minime, et t'as pas vraiment besoin de vérifier ce genre de choses, la RAM est plus rapide qu'un SSD, y'a pas de secrets. Et /tmp c'est pas non plus le truc super critique, y'a que des petits fichiers pas très importants qui sont écrits là-dessus, donc que ça prenne 250 microsecondes ou 80, ou 3 franchement, OSEF! 🙂

I beg to differ !

Au contraire, c'est largement mieux pour la performance dans des cas de grande sollicitation comme au démarrage... mais on peut rejoindre Vobu si tu as un SSD la différence est moins sensible... mais la RAM "usera" moins le SSD.
Avec un HDD, la différence est très très visible car précisément ce qui plombe la performance est le temps d'accès.

Pour vérifier la vitesse, tu créés un fichier random d'un peu moins de la moitié de ton /tmp en RAM et tu fais un dd sur le /tmp, puis un dd sur ton HD, et tu devrais voir une énorme différence.

Exemple : création d'un fichier de 2Go (ma RAM est réglée à 6Go)

$ dd if=/dev/urandom of=/tmp/file2Go bs=1M count=2048

Copies en /tmp et sur disque, on vide la cache à chaque mesure pour ne pas fausser :

$ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;
3
$ dd if=/tmp/file2Go of=/tmp/file2Go_copie bs=1M
2048+0 enregistrements lus
2048+0 enregistrements écrits
2147483648 octets (2,1 GB, 2,0 GiB) copiés, 1,87833 s, 1,1 GB/s
$ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;
3
$ dd if=/tmp/file2Go of=~/hdd/file2Go_copie bs=1M
2048+0 enregistrements lus
2048+0 enregistrements écrits
2147483648 octets (2,1 GB, 2,0 GiB) copiés, 17,0074 s, 126 MB/s

Tu vois, la différence est presque un facteur 10 : 1,9 secondes pour copie en RAM, 17 secondes sur HDD.

Vobul

@Zakhar : on est bien d'accord. Je pars du principe que tout le monde a son système installé sur un ssd 😉

Nico89

Bonsoir et merci de vos retours
Vobul, je ne comprends pas le retour de cette commande, en quoi prouve-t-elle que le /tmp est bien monté en RAM ?

xxx@xxx:~$ mount|grep tmpfs
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=1969160k,nr_inodes=492290,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=402952k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=8388608k)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=402948k,mode=700,uid=1000,gid=1000)

Poun64

Bonsoir Nico, bonsoir toul'monde,

Je viens de le tester...
Quand on ajoute ta ligne au fichier "fstab" (cf. ton post #1), l'entrée

tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=8388608k)

s'ajoute quand on lance mount|grep tmpfs

Par contre, le mode=1777 n'y apparaît pas et je me demande l'intérêt d'encadrer la taille maxi de /tmp ?

Nico89

Effectivement j'ai testé la commande en enlevant la ligne du fstab et celà indique bien si le /tmp est ram ou non.

Du coup j'ai voulu tester la vitesse d'écriture, toutefois , je ne sais pas si ma démarche est bonne. En effet je n'ai pas tout a fait effectué la démarche donné par Zahkar, j'ai juste utilisé la commande

dd if=/dev/urandom of=/tmp/file1Go bs=1M count=1024

/tmp sur le SSD :

xxx@xxx:~$ mount|grep tmpfs
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=1969160k,nr_inodes=492290,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=402952k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=402948k,mode=700,uid=1000,gid=1000)
xxx@xxx:~$ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;
[sudo] Mot de passe de moi :        
3
xxx@xxx:~$ dd if=/dev/urandom of=/tmp/file1Go bs=1M count=1024
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 9,72592 s, 110 MB/s
xxx@xxx:~$

/tmp en RAM

xxx@xxx:~$ mount|grep tmpfs
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=1969164k,nr_inodes=492291,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=402956k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=8388608k)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=402952k,mode=700,uid=1000,gid=1000)
xxx@xxx:~$ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;
[sudo] Mot de passe de moi :        
3
xxx@xxx:~$ dd if=/dev/urandom of=/tmp/file1Go bs=1M count=1024
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 5,47474 s, 196 MB/s
xxx@xxx:~$

Pour ta question

Par contre, le mode=1777 n'y apparaît pas et je me demande l'intérêt d'encadrer la taille maxi de /tmp ?

Je ne m'y connait pas suffisamment pour répondre à ta question.

Poun64

Bonjour Nico, bonjour toul'monde !

De ton post précédent, je retiens :

1) /tmp sur le SSD :
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 9,72592 s, 110 MB/s

2) /tmp en RAM
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 5,47474 s, 196 MB/s

3) Pour ce qui est de la taille maxi que l'on peut imposer à un dossier mis en "tmpfs"
- Il est dit au paragraphe 3.2.3 ici : La doc de tmpfs
L'option size permet de définir la quantité de mémoire allouée.
Si elle n'est pas définie, le système attribuera la moitié de la quantité de la mémoire physique.
- Et au paragraphe 2 de cette même page, il est dit :
"Un tmpfs de 1 GO ne prendra 1 GO de place dans la RAM que s'il est plein, en effet il ne prendra que la place des fichiers qu'il contient."

Autant lui allouer la taille de sa RAM, non ?
Ou alors ne pas mettre l'option "Size" pour ne lui en allouer que la moitié...

Nico89

Bonjour à tout le monde,

poun64 a écritAutant lui allouer la taille de sa RAM, non ?

désolé, mais je ne comprends pas ce que tu a essayé de me dire. Je sais qu'il y a message 🙂

Quand je demandais si ma démarche était la bonne, c'était surtout si la commande suivante était la bonne :

dd if=/dev/urandom of=/tmp/file2Go bs=1M count=2048

Car Zahkar donnait aussi ces commandes :

dd if=/tmp/file2Go of=/tmp/file2Go_copie bs=1M
dd if=/tmp/file2Go of=~/hdd/file2Go_copie bs=1M

Sur cette commande

dd if=/dev/urandom of=/tmp/file2Go bs=1M count=2048

, les données sont écrites en RAM , puis lues ?

Poun64

Bonjour Nico, bonjour toul'monde !

...les données sont écrites en RAM, puis lues ?

A priori oui pour la 1ère commande, en tout cas chez-moi. La preuve en image :

poun@HP-Poun:~$ dd if=/dev/urandom of=/tmp/file2Go bs=1M count=2048
2048+0 enregistrements lus
2048+0 enregistrements écrits
2147483648 octets (2,1 GB, 2,0 GiB) copiés, 13,4123 s, 160 MB/s

J'ai également surveillé pendant les copies de ces fichiers de 2Go, le remplissage de la RAM avec la commande

df | grep -E 'tmpfs|bloc'

et avec l'utilitaire "Moniteur système".

J'ai fait ces tests sur mon PC de secours qui a 4Go de RAM et une partition Swap de 8Go.
Arbitrairement, j'ai donné une taille de 8Go à /tmp de "tmpfs" dans le fichier fstab :

tmpfs /tmp tmpfs defaults,relatime,mode=1777,nosuid,size=8G 0 0

Constat, quand la RAM est pleine, on bascule bien sur le Swap.

D'où ma question : quelle taille faut-il allouer à /tmp que l'on bascule en RAM ?
- Ne pas renseigner la taille (et c'est la moitié de la RAM qui est prise par défaut) ?
- Renseigner la taille maxi (RAM + Swap), dans mon cas 4 + 8 Go ?
- Y mettre une taille intermédiaire, sachant qu'avant de faire notre bidouille, /tmp était limité à l'espace disponible sur le disque...

Edit :
Je suis allé un peu plus loin dans la protection de mes SSD :
- J'ai mis en RAM les "/temp" de Firefox et de Thunderbird, infos au §4.3 ici : https://doc.ubuntu-fr.org/tmpfs
- J'ai stoppé la compression des fichiers "log", infos au §4.3 ici : https://doc.ubuntu-fr.org/logrotate#la_compression

😛

Nico89

Bonjour Poun64,

2048+0 enregistrements lus
2048+0 enregistrements écrits

Ces deux lignes sont les seules qui indiquent la l'écriture et la lecture. Je n'ai rien trouvé dans la doc à ce sujet.

J'ai suivi une partie de ce tuto https://sebsauvage.net/wiki/doku.php?id=mint_customization_19 au paragraphe "réduire les écritures disque (1).

D'où ma question : quelle taille faut-il allouer à /tmp que l'on bascule en RAM ?
- Ne pas renseigner la taille (et c'est la moitié de la RAM qui est prise par défaut) ?
- Renseigner la taille maxi (RAM + Swap), dans mon cas 4 + 8 Go ?
- Y mettre une taille intermédiaire, sachant qu'avant de faire notre bidouille, /tmp était limité à l'espace disponible sur le disque...

Ton questionnement m'intéresse car j'ai 4go de Ram et j'ai paramétré un /tmp de 8go.

- J'ai stoppé la compression des fichiers "log", infos au §4.3 ici : https://doc.ubuntu-fr.org/logrotate#la_compression

ça m'intéresse beaucoup.
Par curiosité, j'ai été voir la taille des fichiers log (/var/log). Le plus gros fichier en cours d'écriture est dpkg.log.1 qui fait 1,4Mo, tous les autres en cours d'écriture font moins de 1 Mo.
Par curiosité, j'ai décompressé quelques archives log. Il ont tous une compression d'environ 80%.
Finalement la question de laisser la compression se pose, car les fichiers log ne sont vraiment pas très gros. Est-ce que ça impacte sensiblement les performances ? Quels sont les risques de ne pas compresser ?

Du coup comment fais-tu pour stopper la compression, car voici mon fichier /etc/logrotate.conf :

# see "man logrotate" for details
# rotate log files weekly
weekly

# use the adm group by default, since this is the owning group
# of /var/log/syslog.
su root adm

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may be also be configured here.

on s'aperçoit que la compression est déjà inactive car commentée. Du coup je ne comprends pas pourquoi les logs sont compressés!!
Même si les fichiers log dans /etc/logrotate.d sont effectivement parametrés pour compesser, le fichier qui commande tout est /etc/logrotate.conf ?

Poun64

Salut Nico, salut toul'monde !

2048+0 enregistrements lus
2048+0 enregistrements écrits

Si j'ai bien compris, la commande :

dd if=/dev/urandom of=/tmp/file2Go bs=1M count=2048

...copie (enregistrements lus) un fichier de données aléatoires (avec "urandon") pour les écrire dans "/tmp".

Outre l'application graphique que j'évoque au post #10, tu peux voir augmenter l'utilisation de ta RAM avec "top" lancé dans un terminal.
Ou mieux, en installant "htop" et en le lançant toujours dans un terminal.
Si tu as 4Go de RAM et mis un "/tmp" de 8Go, le complément ira vers le Swap. Au fait, as-tu optimisé ton basculement RAM vers le Swap ?
Voir ici : https://doc.ubuntu-fr.org/swap#ameliorer_l_utilisation_du_fichier_d_echange_swap

Du coup comment fais-tu pour stopper la compression, car voici mon fichier /etc/logrotate.conf :

En fin de fichier, il est écrit :

# packages drop log rotation information into this directory
include /etc/logrotate.d

Il faut donc éditer tous les fichiers contenus dans ce dossier "/etc/logrotate.d/" et remplacer quand elles existent, les entrées :
- compress par nocompress
- delaycompress par nodelaycompress

bruno

Bonjour,

8Go pour monter /tmp en RAM cela me paraît énorme. J'ai rarement vu un dossier /tmp dépasser 1Mo
Pour voir l'espace occupé par /tmp sur le disque :

sudo du -sh /tmp

Les fichiers de logs sont de simples fichiers texte qui prennent généralement peu de place. Sauf si un processus se met à écrire massivement dans les logs, et là cela peu très vite atteindre des poids conséquents. De plus la compression de fichiers texte est rapide et très efficace.AMHA, désactiver la compression après rotation est donc une mauvaise idée.

Du point de vue des performance globales du système ce type d'« optimisation », montage de /tmp en RAM ou désactivation de la compression des logs et sans doute tout à fait inutile tant le gain sera minime.

Pour ce qui est de limiter les écritures sur un SSD, je vous invite à chercher les différentes études faites sur la fiabilité et la durée de vie des SSD, notamment celle issues de gros datacenters. Là encore ce type d'optimisation n'apporte probablement pas grand chose.

Poun64

8Go pour monter /tmp en RAM cela me paraît énorme. J'ai rarement vu un dossier /tmp dépasser 1Mo

Certes... mais qu'en est-il quand on télécharge des vidéos par exemple ?

Les fichiers de logs sont de simples fichiers texte qui prennent généralement peu de place.

Quel est alors l'intérêt de les compresser ?
Autant les laisser en l'état, ça limite (au moins un tout petit peu) les sollicitations des CPU, des HDD et des SSD...

bruno

Au temps pour moi je n'avais pas pensé aux téléchargements de gros fichiers, donc Ok pour 8Gio. Par contres en termes de performances je ne suis pas sûr que tu y gagnes. Le fichier est copié en RAM pendant le téléchargement puis de la RAM au disque dès que celui-ci est fini au lieu d'une seule copie directe sur le disque (le déplacement de /tmp à un autre dossier ne compte pas).

L’intérêt de compresser les logs c'est d'occuper moins de place sur le disque pour les archiver. Exemple :

du -h /var/log/sys*
408K    /var/log/syslog
580K    /var/log/syslog.1
60K     /var/log/syslog.2.gz
64K     /var/log/syslog.3.gz
72K     /var/log/syslog.4.gz
64K     /var/log/syslog.5.gz
40K     /var/log/syslog.6.gz
40K     /var/log/syslog.7.gz

.
soit au total 1328 Kio pour syslog au lieu d'environ 4400 Kio avec des fichiers non compressés. C'est loin d'être négligeable quand on additionne tous les fichiers de logs. Et en cas de problème tu peux te retrouver avec des logs qui font plusieurs centaines de Mio, voire plusieurs Gio, à multiplier par la valeur du paramètre rotate pour le log concerné. Encore une fois compresser avec gzip un fichier texte est très rapide et prend très peu de ressources,. Cela me paraît donc idiot de s'en priver.

Nico89

Bonjour Bruno et merci de nous avoir rejoint.

Les fichiers de logs sont de simples fichiers texte qui prennent généralement peu de place. Sauf si un processus se met à écrire massivement dans les logs, et là cela peu très vite atteindre des poids conséquents.

ça m'est déjà arrivé. J'avais un jour paramétré ufw et gufw pour avoir une journalisation complète, que j'avais oublié d'enlever.
Je me suis retrouver avec des fichiers textes qui faisaient 30go avant compression et des archives de ces mêmes log qui faisaient 2 ou 3 Go.
Je m'en suis rendu compte car mon PC n'avait plus de place sur le SSD (SSD de 128 Go). Mais je m'était aperçu avant cela qu'à intervalles régulier mon PC se mettait à ventiler, chauffer et à ramer. C'est après coup que j'ai compris que c'était la compression des log qui provoquait la saturation du processeur.
Tout ça pour dire que je ne sais pas s'il faut enlever la compression. Mon cas était un cas extreme, mais c'est parce que j'avais plus de place sur le SSD que je me suis aperçu du problème.

Nico89

J'ai 8go de RAM, 2Go de swap.
Est-ce censé de mettre un /tmp de 8go ?

Poun64

Et en cas de problème tu peux te retrouver avec des logs qui font plusieurs centaines de Mio, voire plusieurs Gio, à multiplier par la valeur du paramètre rotate pour le log concerné

Justement, je me demandais l'intérêt de conserver des fichiers logs vieux de 7 semaines...
Je pensais limiter ça à 3 ou 4...

Poun64

Nico a écritJ'ai 8go de RAM, 2Go de swap. Est-ce censé de mettre un /tmp de 8go ?

Ton Swap est-il un fichier "swapfile" ou sur une partition dédiée ?
Dans le cas d'un fichier "swapfile", je ne sais pas si le système peut maintenant augmenter sa taille automatiquement en cas de besoin...

Dans la Documentation il est écrit :
"Par défaut, Ubuntu calcule et s'attribue automatiquement un espace d'échange suffisant ou recommandé lors de son installation."

Comme je suis amené à faire joujou avec des fichiers vidéos, j'ai opté pour une partition Swap assez volumineuse...

Nico89

Dans le dossier /var/log/
si je prends l'exemple du kern.log,
j'ai 5 fichiers :
_kern.log => celui actuellement écrit
_kern.log.1 => fichier texte non compressé
_kern.log.2.gz => fichier compressé
_kern.log.3.gz => fichier compressé
_kern.log.4.gz => fichier compressé

Le paramétrage du fichier kern.log est dans /etc/logrotate.d/rsyslog. La rotation est donné pour 4
Je ne comprends pas la présence du fichier texte kern.log.1
Est-ce un fichier en attente de compression ?
Du coup un nouveau log est créé chaque jour, à chaque démarrage, autre ?

Page suivante »