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


139

Quand devrais-je utiliser /dev/shm/et quand devrais-je utiliser /tmp/? Puis-je toujours compter sur leur présence à la fois sur Unices?

Réponses:


101

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

De Wikipedia :

Les versions récentes du noyau Linux 2.6 ont commencé à offrir / dev / shm en tant que mémoire partagée sous la forme d'un disque mémoire, plus précisément en tant que répertoire accessible en écriture, stocké en mémoire avec une limite définie dans / etc / default / tmpfs.  Le support de / dev / shm est complètement facultatif dans le fichier de configuration du noyau.   Il est inclus par défaut dans les distributions Fedora et Ubuntu, où il est principalement utilisé par l'application Pulseaudio.             (Soulignement ajouté.)

/tmpest l'emplacement des fichiers temporaires tels que définis dans la norme de hiérarchie du système de fichiers , suivie de presque toutes les distributions Unix et Linux.

Étant donné que la mémoire RAM est nettement plus rapide que le stockage sur disque, vous pouvez utiliser /dev/shmplutôt /tmpque l'amélioration des performances , si votre processus nécessite beaucoup d'E / S et utilise abondamment des fichiers temporaires.

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

N'oubliez pas que cela /tmppeut faire partie du /système de fichiers au lieu d'un montage séparé, et peut donc croître selon les besoins. La taille de /dev/shmest limitée par l'excès de RAM sur le système et vous risquez donc davantage de manquer d'espace sur ce système de fichiers.


1
Je vais l'utiliser pour rediriger la sortie d'erreur standard d'une commande vers un fichier. Ensuite, je lirai ce fichier et le traiterai. Je le ferai plusieurs milliers de fois (cela fait partie de la condition d'une construction de boucle). Je pensais que la mémoire serait bien dans ce cas. Mais je veux aussi que ce soit portable. J'imagine que je vais vérifier s'il /dev/shmexiste, l'utiliser si c'est le cas, ou y revenir /tmp. Est-ce que ça sonne bien?
Supprimé

1
J'ajouterais également une vérification de la taille minimale et du niveau d'utilisation actuel de / dev / shm pour éviter tout remplissage par inadvertance.
Nagul

4
Sous Linux 2.6 et les versions ultérieures, le répertoire / dev / shm doit être monté pour que les appels système à mémoire partagée POSIX tels que shm_open () fonctionnent. En d’autres termes, certains programmes s’arrêteront s’ils ne sont pas montés - comme il se doit. Ce n'est pas juste un disque RAM. Vous devriez donc vous assurer que certains de / dev / shm sont libres.
EdH

7
Il n'y a pas d'amélioration des performances en utilisant /dev/shm. /dev/shmest la mémoire (tmpfs) sauvegardée par le disque (swap). /var/tmpest la mémoire (cache disque) sauvegardée par le disque (système de fichiers sur disque). En pratique, les performances sont à peu près les mêmes (tmpfs a un léger avantage mais n’a pas l’importance d’importer). /tmppeut être tmpfs ou non selon la configuration de l'administrateur. Il n'y a aucune bonne raison d'utiliser /dev/shmdans vos scripts.
Gilles

3
@GaretClaborn Il existe de nombreuses bonnes raisons d'utiliser une mémoire sauvegardée par swap, mais cela s'appelle une mémoire de processus normale. Si vous utilisez un fichier, cela s'appelle un système de fichiers et tous les systèmes de fichiers sont en mémoire (cache), et sont sauvegardés par swap si le système de fichiers ressemble à tmpfs. L'allocation d'espace disque entre le swap et d'autres zones de stockage est généralement effectuée par l'administrateur. Si une application souhaite conserver des fichiers qui ont tendance à rester dans la RAM, /tmpc'est l'emplacement normal (avec la $TMPDIRpriorité). Le choix de faire /tmpsauvegarder par swap, autre espace disque ou rien est à l'administrateur.
Gilles

61

En ordre décroissant de tmpfsprobabilité:

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

Puisque vous vous interrogez sur un point de montage tmpfs spécifique à Linux et sur un répertoire défini de manière portable qui peut être tmpfs (en fonction de votre administrateur système et de la valeur par défaut de votre distribution), votre question comporte deux aspects que d'autres réponses ont mis en évidence différemment:

  1. Quand utiliser ces répertoires, selon les bonnes pratiques
  2. Quand il convient d'utiliser tmpfs

Bonnes pratiques

Édition conservatrice (mélange de conventions de FHS et d'utilisation courante):

  • En cas de doute, utilisez /tmp.
  • Utilisez cette option /var/tmppour les données volumineuses qui ne rentrent pas facilement dans le bélier.
  • Utilisez /var/tmpcette option pour conserver des données lors de redémarrages (comme un cache).
  • Utiliser /dev/shmcomme un effet secondaire de l'appel shm_open(). Le public visé est constitué de tampons délimités qui sont écrasés à l'infini. Il s’agit donc de fichiers de longue durée dont le contenu est volatile et pas très volumineux.
  • Si le doute persiste, donnez à l'utilisateur le moyen de le remplacer. Par exemple, le mktempprogramme respecte la TMPDIRvariable d'environnement.

Édition pragmatique:

Utiliser /dev/shmquand il est important d'utiliser tmpfs, /var/tmpquand il est important de ne pas le faire, sinon /tmp.

Où tmpfs excelle

fsyncest un no-op sur tmpfs. Cet appel système est l’ennemi numéro un des performances (E / S) (et de la longévité des flashs, si vous en tenez à cela), mais si vous utilisez des 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 précises - vous êtes clairement disposé à ignorer certains points de sauvegarde pour améliorer les performances, car vous êtes maintenant sur le point de tout saboter - ce qui est rarement le meilleur compromis. En outre, c’est ici, dans le domaine des performances transactionnelles, que l’un des meilleurs avantages d’avoir un disque SSD est - tout disque SSD décent fonctionnera hors de ce monde par rapport à ce qu’un disque rotatif peut éventuellement supporter (7200 tr / min = 120 Hz). , si les autres utilisateurs y ont accès), sans parler des cartes mémoire flash, qui varient beaucoup sur cette mesure (notamment parce qu’il s’agit d’un compromis entre performances séquentielles, ce qui correspond à leur classification, par exemple la classification de la carte SD). Alors méfiez-vous,

Tu veux entendre une histoire ridicule? Ma première fsyncleçon: mon travail consistait à "mettre à jour" régulièrement un ensemble de bases de données SQLite (conservées sous forme de cas de test) vers un format en constante évolution. Le cadre de "mise à niveau" exécuterait un ensemble de scripts, faisant au moins une transaction chacun, pour mettre à niveau une base de données. Bien sûr, j'ai mis à niveau mes bases de données en parallèle (8 en parallèle, car j'avais la chance de disposer d'un processeur puissant à 8 cœurs). Mais comme je l'ai découvert, il n'y a pas eu d'accélération de la parallélisation (plutôt qu'un léger impact ), car le processus était entièrement lié à l'IO. De manière hilarante, emballer la structure de mise à niveau dans un script qui copiait chaque base de données /dev/shm, la mettait à niveau et la recopiait 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 est d'éviter toute écriture inutile de données volatiles. Désactiver efficacement l' écriture différée , comme si vous définissiez l' /proc/sys/vm/dirty_writeback_centisecsinfini sur un système de fichiers standard.

Cela a très peu à voir avec les performances et ne pas le faire est un problème beaucoup moins important que l'abus de fsync: le délai d'écriture en retour détermine le temps nécessaire à la mise à jour du contenu du disque après le contenu de la pagecache, et le délai par défaut de 5 secondes est trop long pour un ordinateur - une application peut écraser un fichier aussi souvent qu'elle le souhaite, en pagecache, mais le contenu sur le disque n'est mis à jour que toutes les 5 secondes environ. Sauf si l'application le force avec fsync, c'est-à-dire. Pensez au nombre de fois qu'une application peut générer un petit fichier à ce moment-là et vous comprendrez pourquoi la synchronisation de chaque fichier constituerait un problème beaucoup plus important.

Quels tmpfs ne peuvent pas vous aider

  • Lire la performance. Si vos données sont chaudes (ce qui est préférable si vous envisagez de les conserver dans tmpfs), vous frapperez quand même la pagecache. La différence est lorsque vous ne frappez pas le pagecache; Si tel est le cas, allez à "Where tmpfs sux", ci-dessous.
  • Fichiers de courte durée. Ceux-ci peuvent vivre toute leur vie dans le pagecache (sous forme de pages sales ) avant même d'être écrits. Sauf si vous le forcez avec fsyncbien sûr.

Où tmpfs sux

Garder les données froides . Vous pourriez être tenté de penser que la gestion de fichiers en mode swap est aussi efficace qu'un système de fichiers normal, mais il existe plusieurs raisons pour lesquelles ce n'est pas le cas:

  • La raison la plus simple: il n’ya rien que les périphériques de stockage contemporains (qu’il soit basé sur un disque dur ou sur une clé USB) n’apprécient plus que la lecture de fichiers assez séquentiels organisés avec soin par un système de fichiers approprié. L'échange en blocs de 4 Ko est peu susceptible de l'améliorer.
  • Le coût caché: Permutation out . Pages TMPFS sont sales - ils doivent être écrit quelque part (à swap) être évincé de pagecache, par opposition à fichier sauvegardé propres pages qui peuvent être sautées instantanément. Il s’agit d’une pénalité d’écriture supplémentaire pour tout ce qui est en concurrence pour la mémoire - affecte quelque chose d’autre à un moment différent de celui de l’utilisation de ces pages tmpfs.

Dans mon Ubuntu 14.04 / dev / shm est un lien vers / run / shm, qui a le système de fichiers "none" selon la commande df. La taille est d'environ 2G, cependant.
Jarno

3
@ jarno Tout d'abord, en réduisant le nombre de points de montage tmpfs, nous appellerions un détail d'implémentation. Deuxièmement, ne laissez pas le nom de l’appareil vous confondre - regardez dans / proc / mounts (c’est le bon endroit à regarder), et vous verrez que le type est "tmpfs", tandis que l’ appareil correspond à "none". Oui, le nom de l'appareil ne signifie rien dans tmpfs - vous pouvez mount -t tmpfs "jarno is great" /mnt/jarnosi vous voulez! Troisièmement, la taille par défaut est la moitié de la quantité de RAM. Je parie que vous avez 4 Go de RAM.
user2394284

1
Existe-t-il une option qui alloue une taille de RAM fixe et promet de ne jamais utiliser de swap?
palswim

@ palswim: Ce serait un disque mémoire. Je ne vois pas d'option pour cela dans tmpfs , sauf que le prédécesseur de tmpfs ne supportait pas l'échange. Les processus peuvent verrouiller leurs pages dans la RAM, ce qui est sans doute moins fou que de verrouiller les pages tmpfs dans la RAM, étant donné que le tueur de MOO est incapable de libérer cette dernière si vous manquez de mémoire.
user2394284

18

Ok, voici la réalité.

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

Tmpfs utilise la mémoire et l’espace swap, son système de fichiers utilise une zone spécifique du disque. La taille du système de fichiers n’est pas 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 assez d'espace d'échange.

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

Personnellement, je suis habitué à avoir des systèmes d’exploitation qui ne tombent pas en panne et des systèmes UPS (par exemple, des 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 préférable avec un point de contrôle de 10 minutes, sauf qu'il traite les données utilisateur en deuxième classe et ne les protège pas. (ext3 est le même mais vous ne le remarquez pas à cause du checkpoint de 5 secondes)

Cette vérification fréquente signifie 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 que votre / tmp soit (même si vous devez créer un fichier d'échange) et utiliser cet espace pour monter un fichier 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 une norme) et que la machine dispose de suffisamment de mémoire + swap disponible.


24
D'accord, à l'exception de la conclusion "NE JAMAIS utiliser / dev / shm". Vous voulez utiliser / dev / shm dans les cas où vous ne voulez pas du tout qu'un fichier soit écrit sur le disque et que vous voulez minimiser les entrées / sorties sur le disque. Par exemple, je dois télécharger de très gros fichiers zip à partir d’un serveur FTP, les décompresser, puis les importer dans une base de données. Je décompressez dans / dev / shm pour que le disque dur ne nécessite que la moitié des opérations de décompression et d'importation, au lieu de basculer entre la source et la destination. Cela accélère immensément le processus. C’est un exemple parmi d’autres, mais je conviens que c’est un outil de niche.
Nathan Stretch

4

Utilisez / tmp / pour les fichiers temporaires. Utilisez / dev / shm / lorsque vous souhaitez utiliser de la mémoire partagée (c.-à-d. Une communication interprocessus via des fichiers).

Vous pouvez compter sur / tmp /, mais / dev / shm / est une seule chose relativement récente pour Linux.


N'y a-t-il pas aussi un aspect performance? Comme / dev / shm est le plus souvent monté en tant que volume tmpfs et essentiellement un disque RAM?
Supprimé

Vous pouvez également monter / tmp en tant que système de fichiers tmpfs. Je le fais sur mon netbook pour accélérer certaines choses en réduisant les écritures sur le SSD (lent). Bien sûr, il y a des inconvénients à le faire (principalement l'utilisation de RAM, mais mon netbook dispose de beaucoup plus de RAM que nécessaire).
David Spillett

Dans mon cas particulier, je l’utiliserais pour une sorte de communication de processus. Je capture la sortie d'erreur standard d'une application et agis sur le contenu (et j'ai toujours besoin de la sortie standard intacte, donc je ne peux en faire aucune 1>/dev/null 2>&1. Je le ferais plusieurs milliers de fois pour qu'un tmpfs soit bien. Cependant, si je publie le script /tmppour /dev/shmlequel je ne peux pas compter sur l'utilisation de tmpfs car je pense que ce n'est pas si courant. Si c'est plus courant, c'est mieux pour moi. Mais je cherche des directives concernant la portabilité, etc.
Supprimé le

1

Une autre fois où vous devriez utiliser / dev / shm (pour Linux 2.6 et supérieur), c’est quand vous avez besoin d’un système de fichiers garanti par tmpfs, car vous ne savez pas si vous pouvez écrire sur le disque.

Un système de surveillance que je connais bien doit écrire des fichiers temporaires tout en créant son rapport pour le soumettre à un serveur central. En pratique, il est beaucoup plus probable que quelque chose empêche les écritures sur un système de fichiers (que ce soit faute d'espace disque ou d'une défaillance du RAID sous-jacent qui a poussé le système dans un mode de lecture seule), mais vous pourrez toujours booster pour alerter. à ce sujet que si quelque chose spirale toute la mémoire disponible de telle sorte que tmpfs sera inutilisable (et la boîte ne sera pas morte). Dans de tels cas, un système de surveillance préférera écrire dans la RAM afin de pouvoir éventuellement envoyer une alerte concernant un disque plein ou un matériel mort / en train de mourir.


0

/ dev / shm est utilisé pour les pilotes de périphérique et les programmes spécifiques au système de mémoire virtuelle partagée.

Si vous créez un programme qui nécessite un segment de mémoire virtuelle qui doit être mappé à la mémoire virtuelle. Cela double donc si vous avez besoin de plusieurs processus ou threads pour pouvoir accéder en toute sécurité à cette mémoire.

Le fait est que ce n'est pas parce que le pilote utilise une version spéciale de tmpfs que vous devez l'utiliser comme une partition générique de tmpfs. Au lieu de cela, vous devriez simplement créer une autre partition tmpfs si vous en voulez une pour votre répertoire temporaire.


0

Dans PERL, avec un minimum de 8 Go sur n’importe quel ordinateur (tous exécutant Linux Mint), je suis d’habitude une bonne habitude de faire des algorithmes complexes basés sur DB_File (structure de données dans un fichier) avec des millions de lectures et écritures à l’aide de / dev / shm

Dans d’autres langues, sans avoir gigether partout, pour éviter les démarrages et les arrêts de transfert réseau (travailler localement sur un fichier situé sur un serveur dans une atmosphère client-serveur), en utilisant un fichier de commandes de type quelconque, je vais copier le tout le fichier (300-900MB) en une fois dans / dev / shm, exécutez le programme avec la sortie dans / dev / shm, écrivez les résultats sur le serveur et supprimez-les de / dev / shm

Naturellement, si j'avais moins de RAM, je ne le ferais pas. Normalement, le système de fichiers en mémoire de / dev / shm se lit comme une taille représentant la moitié de votre RAM disponible. Cependant, l'utilisation ordinaire de la RAM est constante. Donc, vous ne pouvez vraiment pas faire cela sur un appareil avec 2 Go ou moins. Pour transformer la paraphrase en hyperbole, il existe souvent des éléments de la RAM que même le système ne rend pas bien compte.


(Je pense que c'est dans l'esprit de ce qui avait été demandé à l'origine.) Ce que je veux dire en gros, c'est que je suis à l'aise avec l'utilisation de / dev / shm en tant que disque RAM tant que ma mémoire est suffisante. S'il est inefficace de le faire, cela ne devrait pas vous en dissuader, mais devrait déclencher une question du type "Comment puis-je avoir un disque virtuel sur Linux?". La réponse est / dev / shm
David Grove
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.