RaphAstronome

mercredi, 7 mai 2008

Vitesse de hachage de fichiers

Non non, je ne mange pas de la purée de fichier tous les matins ! Le hachage des fichiers permet d'avoir une empreinte permettant de vérifier l'intégrité du fichier, par exemple pour vérifier si un téléchargement c'est bien passé. Il est aussi très utilisé pour éviter de mettre les mots de passe en clair quelque part.

Pour les mots de passe le problème de vitesse ne ce pose pas trop car les codes sont très courts (de 8 à 32 octets en général) mais pour les fichiers la vitesse peut être un critère si on gère de gros volumes ou que l'on est sur un serveur mutualisé. Il existe différentes méthodes pour hasher un fichier ici on teste :

  • La somme (sum), dans la pratique vivement déconseillé
  • Le crc (cksum), un peu mieux mais pas top
  • md5 (md5sum)
  • divers algorithmes sha (sha1 sur 160 bits, et les versions 224, 256 et 512 bits), le sha512 est le plus sûr de tous ceux qui sont testés

Les tests ont été faits sur un iso de la distribution Linux Debian qui fait 158,9 Mo. Les temps d'accès au disque ne comptent pas, on suppose qu'il est toujours en mémoire cache. Pour un disque dur moyen (50 Mo/s) il faudrait ajouter a peu près 3,2s.

Les tests mesurent le temps d'exécution réel des commandes Linux indiquées. Pour plus de précision on teste 5 fois et on extrait la valeur médiane :

sum       : 0,563s
cksum     : 0,703s
md5sum    : 0,524s
sha1sum   : 0,892s
sha224sum : 1,577s
sha256sum : 1,572s
sha512sum : 1,085s

vitesse ckecksum

On remarque que c'est le md5sum qui est le plus rapide, encore plus que le "sum" et "cksum". Pour les SHA on évitera les versions 224 et 256 bits, trop lentes et utilisera les versions 160bits ou 512bits.

jeudi, 31 janvier 2008

Time avec paramètres : marche pas.

Pour voir la durée d'exécution d'un programme de manière un peu plus précise et simple qu'avec un chronomètre il y a la commande time. De plus le temps CPU dédié au processus (user) et système (sys) est affiché :

$ time sleep 10
real    0m10.023s
user    0m0.004s
sys     0m0.000s

Ici l'instruction "sleep 10", attend 10 secondes et ne consomme presque pas de CPU.

On va mettre en forme tout ça pour par exemple l'utiliser dans un script pour ça il y a l'option --format, qui peut éventuellement être réduit à -f mais ici :

$ time -f "%e" sleep 10
bash: -f : commande introuvable
real    0m0.157s
user    0m0.116s
sys     0m0.028s

Baf ! Marche pas il à essayé d'exécuter la commande "-f" au lieu de sleep.

Ce problème est bizarre mais quelques part il fallait s'y attendre : mais comment bash et time peut deviner où est la commande et où sont les paramètres ? En fait la solution est elle aussi bizarre car on peut résoudre le problème en mettant le chemin complet de la commande time :

$ /usr/bin/time -f "%e" sleep 10
10.00

Ca marche ! Le temps d'exécution de la commande sleep est bien de 10 secondes.

Si quelqu'un sait pourquoi il y a un tel changement qu'il me le dise, merci.

mercredi, 13 juin 2007

Charge du système

Un processeur (simple core) ne peut exécuter qu'un seul programme à la fois. Pour pouvoir en exécuter plusieurs simultanément l'ordonnanceur du système d'exploitation (ex: Windows, Linux ...) va exécuter les programmes par intermittence. Par exemple si 2 processus tournent le premier sera exécuté pendant, par exemple, 5 milli-secondes puis le deuxième prend le relais 5ms et ainsi de suite jusqu'a ce que les processus soit terminées, ou déactivés d'une manière ou d'une autre (attente d'une action de l'utilisateur par exemple). Cette méthode permet à l'utilisateur de voir les 2 processus ce dérouler simultanément, et pourquoi pas interagir entre eux.

Sur les système de type Unix (et donc Linux) il existe un nombre qui permet d'avoir une idée de l'utilisation de l'ordinateur par les différents processus : la charge système ou load average.

  • Vous comprendrez vite que si il n'y a aucun processus en cours d'exécution, le processeur ne sera pas du tout utilisé (charge = 0).
  • Si il y a des processus lancés mais qu'ils n'utilisent pas totalement le processeur la charge est entre 0 et 1 . C'est le cas le plus courant sur les machines domestiques lorsqu'on fait du traitement de texte ou une autre activité qui ne consomme que peu de ressources du processeur.
  • Si le processeur est juste suffisant pour exécuter toutes les requêtes sans avoir à les mettre en attente la charge est de 1 mais c'est bien entendu très rare.
  • Si l'ordinateur travaille à fond mais n'arrive pas à exécuter toutes les requêtes lorsque les processus le désirerait la charge devient supérieure à 1, les requêtes sont alors mises en attente.

On pourrait penser qu'une charge supérieure à 1 provoquerait la mise en attente d'une liste de plus en plus importante requêtes jusqu'au plantage. Ceci peut arriver mais dans la pratique il faut une charge de plusieurs dizaines voire centaines pour que ça arrive. En effet de nombreux facteurs font que ce n'est pas si grave :

  • Les tâches sont exécutés plus tard ils demandent donc un temps supplémentaire plus tardivement, il en résulte un ralentissement des programmes.
  • Les tâches peuvent avoir des priorité différentes (paramètre "nice") le processeur exécutera en priorité certains processus. Boinc par exemple effectue ces calcul sur le temps inutilisé du processeur ce qui fait que la charge est toujours supérieure à 1 mais qu'il n'y est pas de ralentissement des autres programmes puisque ce dernier laisse place aux processus prioritaires.

Attention toutefois ce nombre inclus aussi les latences des entrées sorties (accès disque, réseau etc...) Ce fait est très important lorsqu'on veut réduire la charge : en effet avec une charge de 2.6 on pourrait penser qu'il faut un processeur 2.6 fois plus puissant. En fait pas forcément ça peut venir de beaucoup de choses et les remèdes sont variées :

  • Disque dur très sollicité (SWAP ou cache disque trop petit) : augmentez la RAM, si c'est pour un serveur de fichiers il est possible de mettre des disques en RAID pour augmenter leur débit.
  • Processeur(s) a 100% : c'est lui qui est limitant il en faut un plus puissant.
  • La carte graphique : ce voit surtout sur les jeux, activez la sycro verticale histoire de ne pas gaspiller les performances du GPU. Si vous le programmez utilisez si possible les listes d'affichages et VBO plutôt que le mode rendu immédiat.
  • Il est possible que ce soit dû à plusieurs éléments ou des composants qui ne sont pas dans cette liste.

L'utilisation le logiciels plus léger ou leur répartition sur plusieurs ordinateurs peut bien sur améliorer les choses ;) !

Certains programmes de calcul ou de jeu s'octroie autant de processeur qu'il le peuvent, à cause de leur conception, plus la machine est puissante plus il calculera vite, il collera toujours le processeur à 100%. Si c'est un jeu ça ne pose pas de problème car il est rare de jouer et faire être chose en même temps. Si le besoin ce fait sentir on peut augmenter le paramètre "nice" pour que ce processus soit traité avec une priorité plus faible mais avec un risque de saccades.

La charge est donnée par processeur donc sur les machines qui en possèdent plusieurs (ou multi-core) la charge normale sera celle du nombre de cores.

mardi, 29 mai 2007

Faire un .deb automatiquement

Vous venez de trouver un logiciel open-source que vous voudriez installer. Seulement il n'existe pas de paquet pour votre système d'exploitation et/ou architecture. La solution est alors de télécharger le code source et le compiler vous même pour ce faire il faut d'habitude extraire l'archive et entrer ces commandes dans une console :

./configure
make
sudo make install

Le programme sera alors installé toutefois il n'appairera pas parmi vos paquets. Pour ce faire il faut utiliser "checkinstall" au lieu de "sudo make install". Checkinstall génère un paquet prêt à l'emploi au lieu de l'installer tout de suite. Et tant qu'a faire nous allons programmer un script bash qui permettra de compiler et faire le paquet automatiquement en quelques clics :

#!/bin/sh

tar -xf "$@"
cd `tar -tf "$@" | head --lines=1`
./configure
make
checkinstall --fstrans
mv *.deb ..

Tout d'abord on extrait l'archive : il contient un répertoire dans lequel on ce rend. Ensuite on fait les classiques ./configure et make puis on utilise checkinstall avec une option qui permet d'éviter d'avoir à ce mettre en "root". Remarquez que le deb généré sera minimal, pas de description, ni dépendances, ni tout autre élément d'information. Pour une diffusion il faudrait être plus précis mais pour un paquet juste pour nous ça va.

Ce script bash est prévu pour être placé dans les scripts du menu contextuel de gnome : il faut le placer dans ~/.gnome2/nautilus-scripts, il apparaîtra normalement dans le menu lorsque vous ferez un clic droit sur un fichier.

Quelques remarques :

  • Durant le traitement aucun affichage n'est effectué, ça prend souvent plusieurs minutes, ne lancez pas deux fois le script et attendez que le .deb apparaisse. En cas d'erreur le programme ce finit sans message d'erreur, si vous voulez voir ce qu'il se passe je vous conseille de l'utiliser en mode console.
  • Pour la ligne avec cd il faut bien mettre ` et pas '. N'oubliez pas d'en faire un exécutable avec "chmod".
  • Pour fonctionner il faut bien sur que vous ayez installé ce qu'il faut pour compiler et checkinstall.
  • Ce script est prévu pour les archives de sources répondant au format classique de l'open-source, des archives atypiques ont de grandes chances de ne pas être traités comme il faut et être extrait dans le répertoire courant au lieu d'un sous répertoire.
  • Le dossier de l'archive est conservé pour une éventuelle réutilisation mais si vous n'en avez pas besoin vous pouvez le supprimer.
  • Il doit être possible de générer un rpm ou un paquet Slackware avec mais il faut alors le modifier.
  • Étrangement cet utilitaire ne semble pas marcher avec une archive placée sur le bureau.
  • Le script est sous licence BSD.

page 5 de 5 -