Quand dois-je utiliser /dev/shm/ et quand dois-je utiliser /tmp/?

/dev/shm est un système de fichiers de stockage de fichiers temporaires, c'est-à-dire tmpfs, qui utilise la RAM pour le magasin de sauvegarde. Il peut fonctionner comme une implémentation de mémoire partagée qui facilite l'IPC.

De Wikipédia :

Les versions récentes du noyau Linux 2.6 ont commencé à proposer /dev/shm en tant que mémoire partagée sous la forme d'un disque virtuel, plus précisément en tant que répertoire inscriptible par le monde stocké en mémoire avec une limite définie dans /etc/default/tmpfs. La prise en charge de /dev/shm est complètement facultative dans le fichier de configuration du noyau. Il est inclus par défaut dans les distributions Fedora et Ubuntu, où il est le plus largement utilisé par l'application Pulseaudio.

/tmp est l'emplacement des fichiers temporaires tel que défini dans le Filesystem Hierarchy Standard, qui est suivi par presque toutes les distributions Unix et Linux.

Étant donné que la RAM est nettement plus rapide que le stockage sur disque, vous pouvez utiliser /dev/shm au lieu de /tmp pour l'amélioration des performances, si votre processus est intensif en E/S et utilise beaucoup de fichiers temporaires.

Pour répondre à vos questions :Non, vous ne pouvez pas toujours compter sur /dev/shm étant présent, certainement pas sur des machines à court de mémoire. Vous devez utiliser /tmp sauf si vous avez une très bonne raison d'utiliser /dev/shm .

N'oubliez pas que /tmp peut faire partie du / système de fichiers au lieu d'un montage séparé, et peut donc évoluer selon les besoins. La taille de /dev/shm est limité par un excès de RAM sur le système, et par conséquent, vous êtes plus susceptible de manquer d'espace sur ce système de fichiers.

Par ordre décroissant de tmpfs probabilité :

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Puisque vous posez des questions sur un tmpfs spécifique à Linux point de montage par rapport à un répertoire défini de manière portable qui peut être tmpfs (selon votre administrateur système et ce qui est par défaut pour votre distribution), votre question a deux aspects, que d'autres réponses ont soulignés différemment :

1. Utilisation appropriée des différents répertoires tmp
2. Utilisation appropriée de tmpfs

Utilisation appropriée des différents répertoires tmp

Basé sur l'ancien Filesystem Hierarchy Standard et sur ce que Systemd dit à ce sujet.

• En cas de doute, utilisez /tmp .
• Utilisez /var/tmp pour les données qui doivent persister après les redémarrages.
• Utilisez /var/tmp pour les données volumineuses qui peuvent ne pas tenir facilement dans la RAM (en supposant que /var/tmp a plus d'espace disponible - habituellement une hypothèse juste).
• Utilisez /dev/shm uniquement comme effet secondaire de l'appel de shm_open() . Le public visé est constitué de tampons limités qui sont écrasés à l'infini. C'est donc pour les fichiers à longue durée de vie dont le contenu est volatil et pas très volumineux.
• N'utilisez certainement pas /dev/shm pour les exécutables (de tout type), car il est généralement monté noexec .
• En cas de doute, fournissez à l'utilisateur un moyen de passer outre. Pour le moins de surprise possible, faites comme mktemp et respectez le TMPDIR variable d'environnement.

Où tmpfs excelle

Il est important de dire que là où tmpfs excelle vraiment, c'est avant tout pour cacher un bogue de performances qui est douloureusement significatif sur un disque en rotation. Donc, si le réparer est une option, c'est bien sûr l'utilisation inappropriée de tmpfs :

fsync est un no-op sur tmpfs. Cet appel système indique au système d'exploitation de vider son cache de pages associé à un fichier, jusqu'à vider le cache d'écriture du périphérique de stockage concerné, tout en empêchant le programme qui l'a émis de progresser - une barrière d'écriture très grossière . C'est un outil nécessaire dans la boîte uniquement parce que les protocoles de stockage ne sont pas conçus pour les transactions. Et la mise en cache est là en premier lieu pour permettre aux programmes d'effectuer des millions de petites écritures dans un fichier sans remarquer à quel point il est lent d'écrire sur un périphérique de stockage - toute écriture réelle se produit de manière asynchrone, ou jusqu'à fsync est appelé, qui est le seul endroit où les performances d'écriture sont directement ressenties par le programme.

Donc, si vous vous retrouvez à utiliser tmpfs (ou eatmydata) juste pour vaincre fsync, alors vous (ou un autre développeur de la chaîne) faites quelque chose de mal. Cela signifie que les transactions vers le périphérique de stockage sont inutilement fines pour votre objectif - vous êtes clairement disposé à ignorer certains points de sauvegarde pour les performances, car vous êtes maintenant allé à l'extrême en les sabotant tous - rarement le meilleur compromis. En outre, c'est ici, dans le domaine des performances de transaction, que se trouvent certains des plus grands avantages d'avoir un SSD - tout SSD digne de ce nom va fonctionner hors de ce monde par rapport à ce qu'un disque en rotation peut éventuellement prendre (7200 tr/min =120 Hz, si rien d'autre n'y accède). Les cartes mémoire flash varient également considérablement sur cette métrique (il s'agit d'un compromis avec les performances séquentielles, et la classification de la carte SD ne prend en compte que cette dernière). Alors méfiez-vous, développeurs avec des SSD ultra rapides, de ne pas forcer vos utilisateurs dans ce cas d'utilisation !

Vous voulez entendre une histoire ridicule? Mon premier fsync leçon :J'avais un travail qui impliquait de "mettre à niveau" régulièrement un tas de bases de données Sqlite (conservées comme cas de test) vers un format actuel en constante évolution. Le cadre de "mise à niveau" exécuterait un ensemble de scripts, effectuant au moins une transaction chacun, pour mettre à niveau une base de données. Bien sûr, j'ai mis à jour mes bases de données en parallèle (8 en parallèle, puisque j'ai eu la chance d'avoir un puissant processeur à 8 cœurs). Mais comme je l'ai découvert, il n'y avait aucune accélération de la parallélisation (plutôt un léger hit ) parce que le processus était entièrement lié à IO. De manière hilarante, encapsuler le framework de mise à niveau dans un script qui copie chaque base de données vers /dev/shm , l'a mis à niveau là-bas et l'a copié sur le disque était 100 fois plus rapide (toujours avec 8 en parallèle). En prime, le PC était utilisable aussi, lors de la mise à niveau des bases de données.

Où tmpfs est approprié

L'utilisation appropriée de tmpfs consiste à éviter l'écriture inutile de données volatiles. Désactiver efficacement l'écriture différée , comme le réglage /proc/sys/vm/dirty_writeback_centisecs à l'infini sur un système de fichiers normal.

Cela a très peu à voir avec les performances, et échouer est une préoccupation bien moindre que d'abuser de fsync :le délai d'attente de réécriture détermine la lenteur avec laquelle le contenu du disque est mis à jour après le contenu de la pagecache, et la valeur par défaut de 5 secondes est longue pour un ordinateur – une application peut écraser un fichier aussi souvent qu'elle le souhaite, en pagecache, mais le contenu sur disque n'est mis à jour qu'environ une fois toutes les 5 secondes. À moins que l'application ne le force avec fsync, c'est-à-dire. Pensez au nombre de fois qu'une application peut générer un petit fichier pendant ce temps, et vous comprendrez pourquoi la synchronisation de chacun d'entre eux serait un problème beaucoup plus important.

Ce que tmpfs ne peut pas vous aider

• Lire les performances. Si vos données sont chaudes (ce qui est préférable si vous envisagez de les conserver dans tmpfs), vous accéderez quand même au pagecache. La différence réside dans le fait de ne pas toucher le pagecache ; si tel est le cas, allez à "Où tmpfs sux", ci-dessous.
• Fichiers de courte durée. Ceux-ci peuvent vivre toute leur vie dans le pagecache (comme sales pages) avant même d'être écrites. Sauf si vous le forcez avec fsync bien sûr.

Où tmpfs sux

Garder froid Les données. Vous pourriez être tenté de penser que servir des fichiers hors swap est tout aussi efficace qu'un système de fichiers normal, mais il y a plusieurs raisons pour lesquelles ce n'est pas le cas :

• La raison la plus simple :il n'y a rien que les périphériques de stockage contemporains (qu'ils soient basés sur disque dur ou flash) aiment plus que la lecture de fichiers assez séquentiels soigneusement organisés par un système de fichiers approprié. Il est peu probable que l'échange de blocs de 4 Kio améliore ce point.
• Le coût caché :échanger hors . Les pages Tmpfs sont sales - ils doivent être écrits quelque part (pour échanger) pour être expulsés de pagecache, par opposition au fichier sauvegardé propre pages qui peuvent être supprimées instantanément. Il s'agit d'une pénalité d'écriture supplémentaire sur tout ce qui est en compétition pour la mémoire - affecte autre chose à un moment différent de l'utilisation de ces pages tmpfs.

D'accord, voici la réalité.

tmpfs et un système de fichiers normal sont tous deux un cache mémoire sur disque.

Le tmpfs utilise de la mémoire et de l'espace d'échange car il sauvegarde un système de fichiers utilise une zone spécifique du disque, la taille du système de fichiers ne peut pas être limitée, il est tout à fait possible d'avoir un tmpfs de 200 Go sur une machine avec moins d'un Go de RAM si vous avez suffisamment d'espace d'échange.

La différence réside dans le moment où les données sont écrites sur le disque. Pour un tmpfs, les données sont écrites UNIQUEMENT lorsque la mémoire est trop pleine ou que les données ne seront probablement pas utilisées bientôt. La plupart des systèmes de fichiers Linux normaux d'OTOH sont conçus pour toujours avoir un ensemble de données plus ou moins cohérent sur le disque, donc si l'utilisateur débranche la prise, il ne perd pas tout.

Personnellement, j'ai l'habitude d'avoir des systèmes d'exploitation qui ne plantent pas et des systèmes UPS (par exemple:batteries d'ordinateurs portables), donc je pense que les systèmes de fichiers ext2/3 sont trop paranoïaques avec leur intervalle de point de contrôle de 5 à 10 secondes. Le système de fichiers ext4 est meilleur avec un point de contrôle de 10 minutes, sauf qu'il traite les données utilisateur comme de seconde classe et ne les protège pas. (ext3 est le même mais vous ne le remarquez pas à cause du point de contrôle de 5 secondes)

Ces points de contrôle fréquents signifient que des données inutiles sont continuellement écrites sur le disque, même pour /tmp.

Le résultat est donc que vous devez créer un espace d'échange aussi grand que nécessaire pour votre /tmp (même si vous devez créer un fichier d'échange) et utiliser cet espace pour monter un tmpfs de la taille requise sur /tmp.

N'utilisez JAMAIS /dev/shm.

À moins que vous ne l'utilisiez pour de très petits fichiers IPC (probablement mmap'd) et que vous soyez sûr qu'il existe (ce n'est pas un standard) et que la machine a plus qu'assez de mémoire + swap disponible.