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


Quand devrais-je utiliser /dev/shm/ et quand devrais-je utiliser /tmp/? Puis-je toujours compter sur eux tous les deux sur les Unices?


104
2017-09-22 23:26


origine




Réponses:


/dev/shm est un système de fichiers de stockage de fichiers temporaire, 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 IPC.

De Wikipedia:

Les versions récentes du noyau Linux 2.6 ont commencé à offrir / dev / shm comme mémoire partagée sous la forme d'un disque virtuel, plus précisément comme un répertoire accessible en écriture dans le monde entier, 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 le plus utilisé par l'application Pulseaudio.   (Accentuation ajoutée.)

/tmp est l'emplacement des fichiers temporaires tels que définis dans le Norme de hiérarchie du système de fichiers, qui est suivi par presque toutes les distributions Unix et Linux.

Comme la RAM est beaucoup plus rapide que le stockage sur disque, vous pouvez utilisation /dev/shm au lieu de /tmp pour l'amélioration de la performance, si votre processus est intensif et utilise intensivement des fichiers temporaires.

Pour répondre à vos questions: non, vous ne pouvez pas toujours compter sur /dev/shm être présent, certainement pas sur les machines attachées à la mémoire. Tu devrais utiliser /tmp à moins d'avoir une très bonne raison d'utiliser /dev/shm.

Rappelez-vous que /tmp peut faire partie de la / système de fichiers au lieu d'un montage séparé, et peut donc croître selon les besoins. La taille de /dev/shm est limité par un excès de RAM sur le système, et vous risquez donc de manquer d'espace sur ce système de fichiers.


79
2017-09-23 10:18



Je vais l'utiliser pour rediriger la sortie de la sortie d'erreur standard d'une commande vers un fichier. Ensuite, je vais lire ce fichier et le traiter. 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. Je suppose que je vais vérifier si /dev/shm existe, utilisez-le s'il le fait, ou revenez à /tmp. Est-ce que ça sonne bien? - Deleted
J'ajouterais également une vérification de la taille minimale et du niveau d'utilisation actuel de / dev / shm pour éviter de le remplir par inadvertance. - nagul
Sous Linux 2.6 et versions ultérieures, le fichier / dev / shm doit être monté pour que le système de mémoire partagée POSIX fonctionne comme shm_open (). En d'autres termes, certains programmes se briseront si ce n'est pas monté - il devrait en être ainsi. Ce n'est pas juste un disque RAM. Donc, vous devriez vous assurer que certains fichiers / dev / shm sont gratuits. - EdH
Il n'y a pas de gain de performance en utilisant /dev/shm. /dev/shm est une mémoire (tmpfs) sauvegardée par le disque (swap). /var/tmp est 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 pas assez important). /tmp peut être tmpfs ou non selon la manière dont l'administrateur l'a configurée. Il n'y a pas de bonne raison d'utiliser /dev/shm dans vos scripts. - Gilles
@GaretClaborn Il y a beaucoup de bonnes raisons d'utiliser la mémoire sauvegardée par swap, mais cela s'appelle la mémoire de processus normale. Si vous utilisez un fichier, il s'appelle un système de fichiers, et tous les systèmes de fichiers sont de la mémoire (cache), qui est sauvegardée par swap si le système de fichiers est quelque chose comme tmpfs. L'allocation d'espace disque entre le swap et les autres zones de stockage se situe généralement dans la réalité de l'administrateur. Si une application veut des fichiers qui ont tendance à rester dans la RAM, /tmpest l'emplacement normal (avec $TMPDIR pour annuler). Le choix de faire /tmp soutenu par swap, autre espace disque ou rien sont les administrateurs. - Gilles


Dans l'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 Linux spécifique tmpfs point de montage par rapport à un répertoire défini de manière portable mai be tmpfs (en fonction de votre administrateur système et de ce qui est par défaut pour votre distribution), votre question comporte deux aspects, sur lesquels d’autres réponses ont insisté différemment:

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

Bonnes pratiques

Édition conservatrice (mélange de conventions de FHS et usage commun):

  • En cas de doute, utilisez /tmp.
  • Utilisation /var/tmp pour les données volumineuses qui ne correspondent pas forcément à RAM.
  • Utilisation /var/tmp pour les données utiles pour éviter les redémarrages (comme un cache).
  • Utilisation /dev/shm comme effet secondaire de l'appel shm_open(). Le public visé est constitué de tampons limités écrasés à l'infini. Il s’agit donc de fichiers de longue durée dont le contenu est volatile et peu volumineux.
  • En cas de doute, fournissez à l'utilisateur un moyen de remplacer. Par exemple, le mktemp programme honore le TMPDIR variable d'environnement.

Edition pragmatique:

Utilisation /dev/shm quand il est important d'utiliser tmpfs, /var/tmp quand il est important de ne pas le faire, sinon /tmp.

Où tmpfs excelle

fsync est un no-op sur tmpfs. Ce syscall est l’ennemi numéro un des performances (IO) (et de la longévité des flashs, si vous vous en souciez), mais si vous utilisez tmpfs (ou mangermydata) 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 adaptées à votre objectif - vous êtes clairement disposé à ignorer certains points d’enregistrement pour des performances optimales, car vous êtes désormais passé à l’exception de leur sabotage - rarement du meilleur compromis. En outre, il s’agit ici de la performance des transactions, où certains des plus grands avantages de disposer d’un disque SSD sont: tout disque SSD décent sera performant par rapport à ce qu’un disque tournant peut éventuellement prendre (7200 tr / min = 120 Hz). , si vous y accédez de plus en plus), sans parler des cartes mémoire flash, qui varient énormément selon cette mesure (en particulier parce qu’il s’agit d’un compromis avec les performances séquentielles, ce qui est leur note, par exemple la classe SD). Alors, méfiez-vous, les développeurs qui ont des SSD ultra-rapides, pour 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 consistait à "mettre à jour" un groupe de bases de données Sqlite (conservées sous forme de cas-tests) dans un format en constante évolution. Le framework "upgrade" exécutera un tas de scripts, effectuant 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 un puissant processeur à 8 cœurs). Mais comme je l'ai découvert, il n'y avait aucune accélération de parallélisation que ce soit (plutôt un léger frappé) parce que le processus était entièrement lié à IO. Hilariously, en encapsulant la structure de mise à niveau dans un script qui copiait chaque base de données /dev/shm, mis à niveau là-bas, et copié sur le disque était comme 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 retour en écriture, comme réglage /proc/sys/vm/dirty_writeback_centisecs à l'infini sur un système de fichiers régulier.

Cela a très peu à voir avec les performances, et à défaut, il est beaucoup moins important que d'abuser de fsync: le délai de réécriture détermine le temps de mise à jour du contenu du disque après le contenu de pagecache. - une application peut écraser un fichier aussi souvent qu’il le souhaite, en mémoire cache, mais le contenu du disque n’est mis à jour qu’une fois toutes les 5 secondes. Sauf si l'application le force à traverser avec fsync. Pensez au nombre de fois où une application peut générer un petit fichier en ce moment, et vous voyez pourquoi la synchronisation de chaque fichier serait un problème beaucoup plus important.

Qu'est-ce que tmpfs ne peut pas vous aider avec

  • Lire les performances. Si vos données sont chaudes (ce qui serait mieux si vous envisagez de les conserver dans tmpfs), vous frapperez le pagecache quand même. La différence est quand ne pas frapper la 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 sale pages) avant d’être écrit. Sauf si vous le forcez avec fsync bien sûr.

Où tmpfs sux

En gardant du froid Les données. Vous pourriez être tenté de penser que servir des fichiers en swap est 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’ya rien que les périphériques de stockage contemporains (disque dur ou flash) aiment plus que lire des fichiers assez séquentiels bien organisés par un système de fichiers adéquat. Il est peu probable que l'échange de blocs de 4 Ko soit amélioré.
  • Le coût caché: permutation en dehors. Les pages Tmpfs sont sale - ils doivent être écrits quelque part (pour échanger) pour être expulsés de Pagecache, par opposition à un fichier sauvegardé nettoyer des pages qui peuvent être supprimées instantanément. Ceci est une pénalité supplémentaire en écriture pour tout ce qui est en concurrence pour la mémoire - affecte quelque chose d'autre à un moment différent de l'utilisation de ces pages tmpfs.

40
2018-01-24 21:20



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
@jarno Premièrement, en économisant le nombre de points de montage tmpfs, j'appellerais un détail d'implémentation. Deuxièmement, ne laissez pas le nom de périphérique vous confondre - regardez dans / proc / mounts (c'est le bon endroit pour regarder), et vous verrez que le type est "tmpfs" tandis que le dispositif est ce qui est "aucun" ici. Oui, le nom du périphérique ne signifie rien dans tmpfs - vous pouvez mount -t tmpfs "jarno is great" /mnt/jarno si tu veux! 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
Existe-t-il une option qui alloue une taille de RAM fixe et promet de ne jamais utiliser le swap? - palswim
@palswim: Ce serait un disque virtuel. Je ne vois pas d'option pour cela dans tmpfs, à part que le prédécesseur de tmpfs ne supportait pas le swapping. Les processus peuvent verrouiller leurs pages dans ram, ce qui est sans doute moins fou que de verrouiller les pages tmpfs dans ram, étant donné que le tueur de MOO ne peut pas libérer ce dernier, si vous manquez de mémoire. - user2394284


Ok, voici la réalité.

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

Le tmpfs utilise la mémoire et swapspace car il stocke un système de fichiers utilisant une zone spécifique du disque, ni la taille du système de fichiers, il est tout à fait possible d'avoir un tmpfs de 200 Go sur une machine avec moins de Go si vous avez assez d'espace

La différence réside dans l'écriture des données sur le disque. Pour un tmpfs, les données sont écrites UNIQUEMENT lorsque la mémoire devient trop pleine ou que les données risquent de ne pas être utilisées rapidement. Les systèmes de fichiers Linux les plus normaux sont conçus pour avoir toujours 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, j'ai l'habitude d'avoir des systèmes d'exploitation qui ne plantent pas 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 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 en tant que 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)

Ce contrôle fréquent signifie que des données inutiles sont continuellement écrites sur le disque, même pour / tmp.

Le résultat est 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 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 êtes sûr qu'il existe (ce n'est pas un standard) et que la machine dispose de suffisamment de mémoire + swap disponible.


16
2017-12-31 17:03



D'accord, sauf pour la conclusion, "NE JAMAIS utiliser / dev / shm". Vous souhaitez utiliser / dev / shm dans les cas où vous ne souhaitez pas qu'un fichier soit écrit sur le disque et que vous souhaitiez minimiser les E / S disque. Par exemple, je dois télécharger de très gros fichiers zip depuis un serveur FTP, les décompresser et les importer dans une base de données. Je décompresse le fichier dans / dev / shm de sorte que pour les opérations de décompression et d'importation, le disque dur ne doit effectuer que la moitié des opérations plutôt que de se déplacer entre la source et la destination. Cela accélère énormément le processus. C'est un exemple parmi tant d'autres, mais je suis d'accord pour dire que c'est un outil de niche. - Nathan Stretch


Utilisez / tmp / pour les fichiers temporaires. Utilisez / dev / shm / lorsque vous voulez de la mémoire partagée (c'est-à-dire une communication interprocessus via des fichiers).

Vous pouvez compter sur / tmp / être là, mais / dev / shm / est une chose Linux relativement récente.


4
2017-09-23 00:03



N'y a-t-il pas aussi un aspect performance? Comme / dev / shm est le plus souvent monté sur un volume tmpfs et essentiellement un disque RAM? - Deleted
Vous pouvez aussi 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 (principalement l'utilisation de la RAM, mais mon netbook a de loin plus de RAM qu'il n'en a généralement besoin). - David Spillett
Pour mon cas particulier, je l'utilisais pour une sorte de communication de processus. Je capture la sortie de l'erreur standard à partir d'une application et agit sur le contenu (et j'ai toujours besoin de la sortie standard intacte, donc je ne peux faire aucune 1>/dev/null 2>&1. Je le ferais plusieurs milliers de fois, donc un tmpfs serait bien. Toutefois, si je libère le script, je ne peux pas compter sur tmpfs utilisé pour /tmp comme je pense que ce n'est pas si commun. Si c'est plus commun pour /dev/shm alors c'est mieux pour moi. Mais je cherche des directives concernant la portabilité, etc. - Deleted


/ dev / shm est utilisé pour les programmes et pilotes de périphériques 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 va double 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 partition tmpfs générique. Au lieu de cela, vous devez simplement créer une autre partition tmpfs si vous en voulez une pour votre répertoire temporaire.


0
2017-10-11 23:22





En PERL, avec un minimum de 8 Go sur toutes les machines (toutes sous Linux Mint), je pense que c'est 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 d'écritures avec / dev / shm

Dans d’autres langues, ne pas avoir de gig An partout, pour éviter les démarrages et les arrêts du transfert réseau (travailler localement sur un fichier situé sur un serveur dans une atmosphère client-serveur), en utilisant un fichier batch de quelque type, je copierai le fichier entier (300-900 Mo) à la fois dans / dev / shm, exécutez le programme avec la sortie dans / dev / shm, réécrivez les résultats sur le serveur et supprimez-le 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 correspondant à la moitié de votre RAM disponible. Cependant, l'utilisation ordinaire de la RAM est constante. Donc, vous ne pouvez vraiment pas le faire sur un appareil avec 2 Go ou moins. Pour transformer une paraphrase en hyperbole, il y a souvent des choses dans la RAM que même le système ne rapporte pas bien.


0
2017-09-27 21:02



(Je pense que c'est dans l'esprit de ce qui a été demandé à l'origine.) Ce que je veux dire en gros, c'est que je suis à l'aise avec / dev / shm en tant que disque RAM tant que j'ai suffisamment de mémoire. S'il est inefficace de le faire d'une manière ou d'une autre, cela ne devrait pas vous en dissuader, mais devrait déclencher une question comme "Comment puis-je avoir un disque RAM sous Linux?". La réponse est / dev / shm - David Grove