L'exécution sur tmpfs ne sera plus rapide que si vous avez beaucoup d'E/S disque qui ne sont pas remplies à partir du cache de page.
Si les E/S sont lues et que les fichiers sont déjà en cache, tmpfs ne fera aucune différence.
Si les E/S sont des écritures asynchrones sans vidage et que la charge de travail est en rafale plutôt que continue et qu'il y a suffisamment de cache pour absorber une rafale d'écritures et que les écritures peuvent être vidées en arrière-plan entre les rafales, tmpfs ne fera aucune différence.
S'il n'y a pas d'E/S disque à effectuer, tmpfs ne fera aucune différence.
Si vous avez beaucoup d'E/S disque et que votre processus est bloqué en attendant que le stockage se rattrape, l'exécution sur tmpfs fera une énorme différence. Plus vos disques sont lents, plus cela fera de différence, jusqu'au point où vous deviendrez un goulot d'étranglement du processeur.
(4) L'exécutable est exécuté à partir d'un conteneur Docker, et l'exécutable et tous les fichiers impliqués se trouvent dans un dossier tmpfs créé à partir du conteneur, sous un lecteur "interne" (qui ne persiste pas après l'arrêt du conteneur).
(5) L'exécutable est exécuté à partir d'un conteneur Docker, et l'exécutable et tous les fichiers impliqués se trouvent dans des dossiers de disque "normaux".
Mis à part Tmpfs (qui a déjà été traité), vous ne remarquerez aucune différence entre l'exécution d'exécutables sur l'hôte et depuis un conteneur Docker. Même chose avec le stockage de volume. Docker fonctionne à la fois en utilisant un système de fichiers superposé et il y a probablement un très petit coup de performance pour la superposition mais l'hôte voit l'exécutable s'exécuter comme un processus comme s'il avait été démarré sur l'hôte.
De manière réaliste, il devrait y avoir une différence proche de zéro ou nulle. Il peut y avoir des raisons valables pour faire une telle chose, mais j'ose dire que dans 99,9 % des cas, c'est une anti-optimisation.
Les E/S normales iront dans le cache tampon et les pages modifiées seront écrites de manière asynchrone par un thread du noyau. Bande passante =vitesse de la RAM, délai =délai de la RAM (plus, peut-être quelques µs pour un défaut de page ici et là).
Lorsque le système manque de RAM physique, vous bloquez (évidemment), il n'y a pas d'autre moyen. Lorsqu'il ne reste plus de pages sur lesquelles vous pourriez écrire, vous devrez attendre que certaines soient libérées. Il n'y a pas d'autre moyen.
Cependant, manquer de RAM est, par définition, peu susceptible (ou possible) de se produire dans votre cas particulier. Sinon, s'il existe une possibilité réelle de manquer de RAM, l'idée de créer un tmpfs serait tout à fait stupide en premier lieu.
Les E/S vers tmpfs iront vers... le cache du tampon. Oui, maintenant il fonctionne sous un nom différent, mais en réalité c'est exactement le même, en raison du système de VM unifié. La bande passante et le délai sont donc exactement les mêmes (à peu près 1 % de différence en raison de subtilités du système de fichiers qui peuvent être légèrement différentes). Aucune écriture différée ne se produit, oui. Mais peu importe, voir comment cela se passerait de manière asynchrone, de toute façon. Au contraire, maintenant vous n'avez plus le luxe que quelqu'un libère des pages sales en arrière-plan, donc la probabilité d'atteindre le plafond, si c'est possible, est en fait plus élevée.
Lorsque le système manque de RAM physique, vous n'écrivez toujours que sur des pages mappées en mémoire, donc en théorie, vous devriez pouvoir le faire plus rapidement. Cependant, dans la pratique, il n'y a encore que tant et tant de RAM physique, et vous en manquez! Bien sûr, il peut encore y avoir de la place dans vos tmpfs, mais pour une raison quelconque, vous aussi besoin d'écrire une page de mémoire sinon, et il n'y en a plus.
Donc le noyau doit faire quelque chose pour maintenir le système en marche. Il doit d'une manière ou d'une autre réorganiser ses ressources pour atténuer le problème (éventuellement échanger le processus docker et l'ensemble du conteneur ?!). Le noyau fera de son mieux, mais ce n'est pas comme s'il pouvait faire de la magie, il doit faire quelque chose , et ses choix sont limités. De plus, vous avez délibérément supprimé un grand nombre de pages qu'il pourrait autrement utiliser librement selon les besoins à n'importe quelle fin (y compris la demande qui doit être servie maintenant).