hachage le plus rapide dans un environnement Unix?

Je dois examiner la sortie d’un certain script 1000 fois sur une plate-forme Unix et vérifier si l’une d’elles a changé par rapport à avant.

J’ai fait ça:

(script_stuff) | md5sum

et stocker cette valeur. En fait, je n’ai pas vraiment besoin de “md5”, juste une simple fonction de hachage que je peux comparer à une valeur stockée pour voir si elle a changé. C’est correct s’il y a un faux positif occasionnel.

Y a-t-il quelque chose de mieux que md5sum qui fonctionne plus rapidement et génère une valeur de hachage assez utilisable? Le script lui-même génère quelques lignes de texte – peut-être 10-20 en moyenne à environ 100 ou plus.

J’ai jeté un œil sur md5sum rapide sur des millions de chaînes dans bash / ubuntu – c’est formidable, mais je ne peux pas comstackr un nouveau programme. Besoin d’un utilitaire système … 🙁

Détails supplémentaires “d’arrière-plan”:

On m’a demandé de surveiller l’enregistrement DNS d’un ensemble d’environ 1000 domaines et d’appeler immédiatement certains autres scripts en cas de changement. J’ai l’intention de faire une instruction dig xyz + short et de hacher sa sortie et de la stocker, puis de la vérifier avec une valeur précédemment stockée. Tout changement déclenchera l’autre script, sinon il continue. En ce moment, nous prévoyons d’utiliser cron pour un ensemble de ces 1000, mais nous pouvons penser complètement différemment pour une utilisation “sérieusement lourde” – environ 20 000 environ.

Je n’ai aucune idée de ce que serait l’utilisation d’un tel système, je le fais simplement comme travail pour quelqu’un d’autre …

L’utilitaire cksum calcule une sum de contrôle CRC non cryptographique.

Quelle est la taille de la sortie que vous vérifiez? Une centaine de lignes max. Je voudrais juste sauvegarder le fichier original complet, puis utiliser cmp pour voir s’il a été modifié. Etant donné qu’un calcul de hachage devra de toute façon lire chaque octet, le seul moyen d’obtenir un avantage d’un calcul de type de sum de contrôle est que le coût de cette opération soit inférieur à la lecture de deux fichiers de cette taille.

Et cmp ne vous donnera aucun faux positif ou négatif 🙂

 pax> echo hello >qq1.txt pax> echo goodbye >qq2.txt pax> cp qq1.txt qq3.txt pax> cmp qq1.txt qq2.txt >/dev/null pax> echo $? 1 pax> cmp qq1.txt qq3.txt >/dev/null pax> echo $? 0

Basé sur la mise à jour de votre question:

On m’a demandé de surveiller l’enregistrement DNS d’un ensemble d’environ 1000 domaines et d’appeler immédiatement certains autres scripts en cas de changement. J’ai l’intention de faire une instruction dig xyz + short et de hacher sa sortie et de la stocker, puis de la vérifier avec une valeur précédemment stockée. Tout changement déclenchera l’autre script, sinon il continue. En ce moment, nous prévoyons d’utiliser cron pour un ensemble de ces 1000, mais nous pouvons penser complètement différemment pour une utilisation “sérieusement lourde” – environ 20 000 environ.

Je ne suis pas sûr que vous ayez besoin de trop vous soucier du fichier E / S. Le script suivant a été exécuté avec dig microsoft.com +short 5000 fois tout d’abord avec le fichier I / O puis avec la sortie dans /dev/null (en changeant les commentaires).

 #!/bin/bash rm -rf qqtemp mkdir qqtemp ((i = 0)) while [[ $i -ne 5000 ]] ; do #dig microsoft.com +short >qqtemp/microsoft.com.$i dig microsoft.com +short >/dev/null ((i = i + 1)) done

Les temps écoulés à 5 courses chacun sont:

 File I/O | /dev/null ----------+----------- 3:09 | 1:52 2:54 | 2:33 2:43 | 3:04 2:49 | 2:38 2:33 | 3:08

Après avoir supprimé les valeurs aberrantes et la moyenne, les résultats sont 2:49 pour le fichier I / O et 2:45 pour le fichier /dev/null . La différence de temps est de quatre secondes pour 5000 itérations, seulement ¹ / _1250ème de seconde par article.

Cependant, comme une itération sur le 5000 prend jusqu’à trois minutes, c’est le temps maximum nécessaire pour détecter un problème (une minute et demie en moyenne). Si ce n’est pas acceptable, vous devez vous déplacer de bash vers un autre outil.

Étant donné qu’une simple dig ne prend que 0,012 seconde, vous devriez en théorie faire 5000 en 60 secondes, en supposant que votre outil de vérification ne prenne pas du temps. Vous devriez peut-être faire quelque chose comme cela en Perl et utiliser un tableau associatif pour stocker la sortie de dig .

La nature semi-compilée de Perl signifie qu’il fonctionnera probablement beaucoup plus vite qu’un script bash et que les trucs fantastiques de Perl faciliteront beaucoup le travail. Cependant, il est peu probable que vous ayez beaucoup moins de temps que 60 secondes, car c’est le temps nécessaire pour exécuter les commandes dig .