I / O lié et CPU lié

Il je.

J’utilise Node.JS avec child_process pour générer des processus bash. J’essaie de comprendre si je fais des liaisons I / O, CPU ou les deux.

J’utilise pdftotext pour extraire le texte de 10k + fichiers. Pour contrôler les concurrences, j’utilise async .

Code:

 let spawn = require('child_process').spawn; let async = require('async'); let files = [ { path: 'path_for_file' ... }, ... ]; let maxNumber = 5; async.mapLimit(files, maxNumber, (file, callback) => { let process = child_process.spawn('pdftotext', [ "-layout", "-enc", "UTF-8", file.path, "-" ]); let result = ''; let error = ''; process.stdout.on('data', function(chunk) { result += chunk.toSsortingng(); }); process.stderr.on('error', function(chunk) { error += chunk.toSsortingng(); }); process.on('close', function(data) { if (error) { return callback(error, null); } callback(null, result); }); }, function(error, files) { if (error) { throw new Error(error); } console.log(files); });

Je surveille mon utilisation d’Ubuntu et mon processeur et ma mémoire sont très élevés lorsque j’exécute le programme. Parfois, un seul fichier est en cours de traitement. Est-ce normal? Quel pourrait être le problème??

J’essaie de comprendre le concept de processus_enfant. Est-ce que pdftotext est un processus enfant de Node.JS ? Tous les processus enfants ne s’exécutent que dans un seul kernel? Et, comment puis-je rendre plus souple pour mon ordinateur traiter les fichiers?

Cool image de glancer:

entrez la description de l'image ici

Cette utilisation de Node.JS est-elle due au processus child_process ??

entrez la description de l'image ici

Merci.

Si vos tâches nécessitent beaucoup de ressources processeur, le nombre optimal de tâches à exécuter est généralement égal au nombre de cœurs (ou au double de ce nombre si le processeur utilise l’hyperthreading). Donc, si vous avez une machine 4 cœurs, vous verrez généralement la vitesse optimale en exécutant 4 tâches en parallèle.

Cependant, les processeurs modernes dépendent fortement des caches. Il est donc difficile de prévoir le nombre optimal de travaux à exécuter en parallèle. Ajoutez la latence des disques et cela rendra la tâche encore plus difficile.

J’ai même vu des travaux sur des systèmes dans lesquels les cœurs partageaient le cache du processeur et où il était plus rapide d’exécuter un travail à la fois, simplement parce qu’il pouvait alors utiliser le cache complet du processeur.

En raison de cette expérience, mon conseil a toujours été: Mesurer.

Donc, si vous avez 10 000 tâches à exécuter, essayez alors d’exécuter 100 tâches aléatoires avec un nombre différent de tâches en parallèle pour voir quel est le nombre optimal pour vous. Il est important de choisir au hasard pour pouvoir également mesurer les E / S du disque. Si la taille des fichiers est très différente, exécutez le test plusieurs fois.

 find pdfdir -type f > files mytest() { shuf files | head -n 100 | parallel -j $1 pdftotext -layout -enc UTF-8 {} - > out; } export -f mytest # Test with 1..10 parallel jobs. Sort by JobRuntime. seq 10 | parallel -j1 --joblog - mytest | sort -nk 4

Ne vous inquiétez pas pour que vos processeurs fonctionnent à 100%. Cela signifie simplement que vous obtenez un retour pour tout l’argent que vous avez dépensé au magasin d’informatique.

Votre RAM n’est un problème que si le cache disque est faible (754 Mo n’est pas faible dans votre capture d’écran. Lorsqu’il est inférieur à 100 Mo, il est bas), car cela pourrait provoquer l’échange de votre ordinateur, ce qui pourrait le ralentir.

Votre code Node.js est lié à I / O. Il ne fait presque rien du travail du processeur. Vous pouvez voir dans votre code que vous créez uniquement des tâches externes et que vous vous déplacez dans la sortie de ces tâches. Vous n’utilisez pas de boucles longues ni de calculs mathématiques lourds. Vous voyez des nombres de processeurs élevés pour le processus Node.js, car les processus pdftotext sont ses processus enfants et, par conséquent, vous voyez ses valeurs de processeurs agrégées.