Réponses:
/dev/shm
est 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 .
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é.)
/tmp
est 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/shm
plutôt /tmp
que 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/shm
présence, 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 cela /tmp
peut 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/shm
est 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.
/dev/shm
. /dev/shm
est la 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 n’a pas l’importance d’importer). /tmp
peut être tmpfs ou non selon la configuration de l'administrateur. Il n'y a aucune bonne raison d'utiliser /dev/shm
dans vos scripts.
/tmp
c'est l'emplacement normal (avec la $TMPDIR
priorité). Le choix de faire /tmp
sauvegarder par swap, autre espace disque ou rien est à l'administrateur.
En 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 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:
Édition conservatrice (mélange de conventions de FHS et d'utilisation courante):
/tmp
./var/tmp
pour les données volumineuses qui ne rentrent pas facilement dans le bélier./var/tmp
cette option pour conserver des données lors de redémarrages (comme un cache)./dev/shm
comme 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.mktemp
programme respecte la TMPDIR
variable d'environnement.Édition pragmatique:
Utiliser /dev/shm
quand il est important d'utiliser tmpfs, /var/tmp
quand il est important de ne pas le faire, sinon /tmp
.
fsync
est 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 fsync
leç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.
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_centisecs
infini 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.
fsync
bien sûr.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:
mount -t tmpfs "jarno is great" /mnt/jarno
si 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.
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.
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.
1>/dev/null 2>&1
. Je le ferais plusieurs milliers de fois pour qu'un tmpfs soit bien. Cependant, si je publie le script /tmp
pour /dev/shm
lequel 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.
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.
/ 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.
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.
/dev/shm
existe, l'utiliser si c'est le cas, ou y revenir/tmp
. Est-ce que ça sonne bien?