Limiter la taille du tuyau et écrire dans un fichier temporaire comme solution de secours

J'ai une question un peu délicate. Je veux transmettre le résultat d'une commande à une autre, mais comme je travaille sur un système avec une mémoire limitée, je veux m'assurer que le tuyau n'en utilisera pas trop. Mais je ne veux pas que ça casse quand il atteint la limite, passez simplement à l’utilisation du disque en tant que fichier temporaire.

Le cas d'utilisation est le suivant. Je télécharge un gros fichier en utilisant curl ou wget. Je dirige le résultat vers un autre programme (vers un canal nommé, en fait, mais ce canal nommé est immédiatement transmis à une autre commande). Si tout se passe bien, la deuxième commande est en mesure de consommer l’entrée plus rapidement que curl ne peut la sortir (le téléchargement est plus lent que le traitement de la deuxième commande).

Mais parfois, les choses tournent mal et la deuxième commande a besoin de temps pour commencer à le consommer. Ce sera probablement le cas, éventuellement, mais comme cette seconde commande nécessite un peu de RAM et que cette ressource est limitée, je souhaite passer à l'écriture sur disque si le canal commence à utiliser plus de 200 Mo de RAM, par exemple.

Cette deuxième commande peut même nécessiter plus de temps pour démarrer que le temps nécessaire pour télécharger le fichier. Dans ce cas, le fichier téléchargé doit être entièrement écrit sur le disque afin que le second processus puisse le consommer ultérieurement.

Y at-il une solution pour un problème aussi stupide?

— Anonymouse
source

Votre question est similaire à celle-ci: utilisez un tampon sauvegardé sur disque entre les tubes , où la réponse est mbuffer -T /path/to/file. La différence réside dans votre idée de combiner des tampons:

Je souhaite passer à l'écriture sur disque si le tube commence à utiliser plus de, disons, 200 Mo de RAM.

Connectez deux tampons comme ceci:

feeder | mbuffer -T /path/to/file -m 2G | mbuffer -m 200M | consumer

Les données circulent aussi loin que possible, de sorte que la mémoire tampon de 200 Mio sera remplie en premier (si jamais). Ce n’est qu’alors que le tampon sur disque de 2 Gio commencera à contenir des données.

Remarques:

Il semble que le fichier soit alloué dans sa taille maximale au tout début. S'il n'y a plus d'espace disponible sur le périphérique, tout le tuyau échouera tôt. Cela introduit cependant un certain retard initial.
Dans mes tests, la première mbufferécriture dans le fichier, même lorsque la seconde lit immédiatement dans le tuyau. Je pense que le premier pourrait transmettre les données sans toucher au fichier; mais ce n'est pas le cas et la totalité du tube est limitée par la vitesse du disque, même si le tampon basé sur le disque n'est pas utilisé du tout.

— Kamil Maciorowski
source

Est-ce que cela n'écrira pas toujours sur le disque, même pour un bref instant, puisque le tampon basé sur le disque est entre le chargeur et celui basé sur la mémoire? Ou peut-être que mbuffer écrit uniquement sur le disque si rien ne le reçoit? Je ne comprends pas complètement comment cela fonctionne.

— Anonymouse

Mais peut-être qu'il n'écrit pas toujours sur le disque. «Tandis que la réception ZFS ne peut pas recevoir, les tampons de mbuffer, lorsque zfs peut recevoir, mbuffer lui envoie les données aussi rapidement que possible» - c'est ce que j'ai trouvé ici . Si mbuffers a un moyen de savoir si quelque chose en reçoit, il pourrait se comporter de cette façon. Peut-être que quelqu'un d'autre ici sait quelque chose à ce sujet? Ce qui me dérange le plus avec deux tubes, je me demande si cela affecte considérablement l'utilisation de la RAM.

— Anonymouse

@ Anonymouse Malheureusement, mes tests récents montrent que vos doutes sont justifiés. Je lis /dev/zerovia deux- mbufferà /dev/null. Avec deux tampons basés sur la mémoire, c'était rapide. Avec un tampon basé sur disque et un tampon basé sur la mémoire, le débit était limité et correspondait à la vitesse du disque.

— Kamil Maciorowski

C'est dommage. Mais ce qui peut aider dans mon cas, c'est que le processus d'envoi sera généralement plus lent que la vitesse du disque, de sorte que le processus de lecture aura le temps de rattraper son retard. Je laisserais toujours cette réponse car cela pourrait aider quelqu'un. J'accepterais le vôtre, car cela pourrait vraiment être utile dans mon cas, mais je ne veux pas décourager les autres de publier quelque chose qui pourrait être meilleur. En tout cas, merci!

— Anonymouse

Génial, on attendra ensemble alors. :-)

— Anonymouse