Page de référence : Anglais (US English).
Retour au sommaire de SETI@home.
Informations sur SETI et
SETI@home :
Calendrier
des opérations.
État du
serveur.
Rapports techniques :
Aidez-nous.
Utilisez SETI@home.
Statistiques et résultats.
|
Les rapports techniques sur SETI@home.
Avril 2001.
- Lundi 30 avril 2001.
- Hier, le moteur Informix servant notre base de données scientifique s'est bloqué, apparemment à cause d'une contention de ressource. Cela s'est
à nouveau produit aujourd'hui. Nous en recherchons activement la cause. Nous avons profité de l'interruption pour mettre à niveau la machine de la base de
données scientifique (un des Sun E450). Nous lui avons ajouté 2 processeurs supplémentaires, et encore 0,5 Go de mémoire centrale.
- Mercredi 25 avril 2001.
- Nous avons enrichi nos pages de liens avec des nouvelles descriptions de sites sur les outils complémentaires SETI@home et les ressources éducatives.
- Lundi 23 avril 2001.
- Comme beaucoup le savent, notre option "View last 10 workunits" (voir les 10 derniers résultats) sur la page de statistiques
personnelles d'un utilisateur a été suspendue à cause d'une surcharge du serveur. Nous travaillons en ce moment pour rétablir cette fonctionnalité sur la
base de données en ligne (grâce à la migration en cours de notre base d'analyse scientifique). Bientôt en ligne !
- Jeudi 5 avril 2001.
- Nous avons bien avancé dans la phase d'audit qualité des données résultant de l'analyse des 80 millions d'unités de travail distribuées jusqu'ici.
Pour vérifier la qualité des données, chaque unité de travail est analysée par 2 ou 3 (parfois plus) clients et les résultats redondants sont comparés
mutuellement entre eux. Nous choisissons un des résultats dans l'ensemble associé à chaque unité de travail, et l'insérons dans notre nouvelle base de
données scientifique principale. Cette base principale ne contiendra donc qu'un résultat canonique et un seul pour chaque unité analysée. Les références
à tous les participants qui ont contribué aux résultats de chaque unité de travail sont maintenus dans la base de données scientifique en ligne.
- Nous appelons le programme qui choisit le résultat canonique le "vérificateur de redondances" ou "VR" ("redundancy checker"
ou "RC" en Anglais). Le VR détermine le résultat canonique en se basant sur l'accord avec les autres résultats de la même unité de
travail. Un accord est est trouvé quand les signaux contenus dans un résultat correspondent valeur par valeur avec ceux de signaux contenus dans un autre
résultat du même ensemble. Nous n'insistons pas sur une égalité stricte, car les signaux qui s'accordent réellement peuvent varier légèrement à cause
des arrondis de calculs et des effets du "dechirping" (suppression de l'effet d'accélération Doppler) qui est réalisé de façon
différentielle par les clients. Nous sommes heureux de constater que seule une infime portion des résultats ne passe pas l'étape de vérification des
redondances. Attendez une discussion détaillée de l'algorithme du VR et des statistiques dans un futur bulletin scientifique. Maintenant puisque cette page
concerne les nouvelles des opérations, venons-en à une discussion sur notre nouveau serveur.
- SETI@home avait à l'origine 2 bases de données sur des serveurs indépendants, pour distribuer les unités de travail aux processeurs finaux (les
clients), recevoir leurs résultats et garder la trace des statistiques des utilisateurs. Nous avions pensé pouvoir conduire l'analyse scientifique
directement sur la base de données qui collecte et stocke les résultats des unités de travail depuis les processeurs finaux. Au bout d'un moment on s'est
aperçu qu'il n'était guère possible de conduire une analyse poussée en même temps que nous recevions effectivement les résultats. Une des fonctions
avait un trop grand impact sur l'autre. Aussi nous avons établi qu'il nous fallait répliquer la base de données en ligne vers un serveur séparé, de sorte
qu'on pourrait mener une analyse hors-ligne sans faire souffrir les temps de réponse du serveur.
- La base de données en ligne est une configuration multiprocesseur à base de SUN 450 Enterprise, avec 2 Go de RAM ECC et près de 400 Go
de disques RAIDs. Nous utilisons plusieurs contrôleurs SCSI dotés de 64 Mo de cache dans des configurations RAID 0+1. Nous utilisons le logiciel Informix
Dynamic Server pour gérer nos bases de données à haute performance. Cette base de données en ligne accepte de recevoir plusieurs résultats redondants
pour chaque unité de travail. Aussi, la taille de la base de données en ligne pourrait être réduite de 66 % à 75 % une fois les résultats
canoniques sélectionnés.
- La nouvelle base de données scientifique maître est maintenant en cours de chargement par le RC. Le nouveau serveur est une machine bien moins
puissante, basée sur un Compaq 570r avec 2 processeurs et 1 Go de RAM ECC tournant sous Solaris avec Informix. Il dispose de 2
contrôleurs SCSI-2W et de 144 Go sur 16 disques. Nous pensons que la plus grande partie du processus de chargement de ce serveur prendra autour de 50 à
90 jours. Alorsnous pourrons reconduire un processus périodique pour le mettre à jour avec les nouveaux résultats parvenus dans la base de données en
ligne.
- Nous avons pu définir la base de donnée en utilisant la fonction de "fragmentation" des tables. Celle-ci permet à Informix de
distribuer équitablement une table ligne par ligne suivant la valeur numérique de leur identifiant, et sur autant de disques que l'administrateur pense
nécessaire (Informix définit des fonctions dites de "hachage" utilisables pour créer une clé pseudo-aléatoire pour cette fragmentation).
Bien que nous n'atteindrons pas la capacité brute d'E/S des configurations RAID, il est possible d'optimiser la capacité en bande passante d'E/S suivant les
caractéristiques de l'application et les besoins de tables spécifiques.
Actuellement la table des Signaux de crête (où nous stockons tous les signaux de crête rapportés) est la structure la plus large et la plus souvent
sollicitée dans la base de données. Aussi un soin particulier a été donné pour s'assurer que cette table et ses index serait éclatée sur un nombre de
disques exclusifs, et n'aurait aucun conflit d'E/S avec les autres tables. Nous avons eu quelques problèmes pour répartir les index exactement où nous le
voulions, puisque Informix définit un positionnement fixe pour les index obligatoires et implicites. En fin de compte, nous nous sommes assurés que
ces emplacements fixes auraient assez d'espace disque et des chemins d'accès minimisant les files d'attente d'E/S durant les activités sur de gros volumes.
En pratique, la nouvelle base de donnée s'est avérée assez performante.
|