Options d'E / S parallèles, en particulier HDF5 parallèle

J'ai une application qui peut être trivialement parallélisée mais ses performances sont dans une large mesure liées aux E / S. L'application lit un tableau d'entrée unique stocké dans un fichier qui est généralement de 2 à 5 Go (mais je m'attends à ce que ce nombre augmente à l'avenir). Un calcul typique applique la même opération à chaque ligne ou colonne de ce tableau. Pour les opérations gourmandes en CPU, j'obtiens une très bonne évolutivité jusqu'à environ 100 processeurs, mais pour les opérations plus lentes, les E / S et la communication associée (accès NFS) dominent et je ne peux pas utiliser plus de quelques processeurs efficacement.

Quelles sont les options efficaces et portables (idéalement portatives) dans une telle situation? Le HDF5 parallèle semble prometteur. Quelqu'un a-t-il une expérience de la vie réelle avec cela?

Est-ce que MPI-I / O mérite d'être étudié? Peut-il fonctionner efficacement avec une disposition de fichier donnée, ou dois-je tout adapter?

Les E / S parallèles peuvent vous aider dans ce cas, mais si vous utilisez NFS (intrinsèquement assez sériel) pour servir vos fichiers, cela ne produira pas le plein effet que vous pourriez souhaiter - il y aura un goulot d'étranglement série au niveau serveur de fichiers et avoir des centaines de processus faisant des demandes au serveur unique ne vous donnera pas des facteurs d'accélération des centaines de le faire à travers un seul processus. Pourtant, cela pourrait aider jusqu'à un certain point, d'autant plus qu'il semble que le goulot d'étranglement est en train de lire plutôt que d'écrire, et ce sera une grande amélioration si votre système est mis à niveau vers un système de fichiers entièrement parallèle.

MPI-IO est de très bas niveau; il vaut la peine de comprendre quelque chose à ce sujet pour savoir ce qui se passe "sous le capot" avec HDF5 parallèle, NetCDF4 ou ADIOS , mais l'utiliser vous-même n'est vraiment bien adapté que pour les données binaires brutes où la structure est bien connue au moment de la compilation. HDF5 et NetCDF4 sont beaucoup plus flexibles.

Notez que si vos données sont relativement simples - par exemple, les structures de Big Data sont principalement des tableaux ou vecteurs à n dimensions - je recommande NetCDF4 (qui est également parallèle et basé sur HDF5) plutôt que HDF5; il est nettement plus simple à utiliser. HDF5 est plus compliqué, et en échange de cette complexité, il permet des modèles de données très compliqués. Mais si c'est une fonctionnalité dont vous n'avez pas besoin, il est plus rapide de démarrer dans NetCDF4.

Dans notre centre, nous avons un cours d'une après-midi et d'une journée sur les E / S parallèles où nous parlons des concepts de base, MPI-IO, HDF5 et NetCDF4; les diapositives sont disponibles ici .

Nous obtenons une bonne mise à l'échelle de l'ensemble du XT6 à ORNL en utilisant MPI / IO pour générer des vecteurs. Voici le code . Les sous-systèmes d'E / S pour de nombreuses machines ne sont pas conçus pour un parallélisme massif, donc je pense que @Dan a raison d'essayer de minimiser les E / S en n'écrivant que quelques étapes ou une autre stratégie d'agglomération.

En ce qui concerne l'écriture flexible de la sortie de manière évolutive, j'ai de l'expérience avec XDMF , qui peut être effectuée par de grandes écritures binaires parallèles en utilisant HDF5 (comme PETSc VecView ) couplées à une petite quantité de code XML écrit en série pour décrire la mise en page. Cela peut être lu par des packages de visualisation comme Paraview ou MayaVi2 . Une autre façon de le faire est d'utiliser le format VTK avec des données binaires ajoutées, mais cela nécessite que vous sachiez tout ce que vous voulez écrire à l'avance.

Je suppose que votre problème d'évolutivité est lié à la sortie et non à l'entrée. L'entrée parallèle est plutôt simple - ce que je fais, c'est que chaque CPU ouvre le fichier NetCDF d'entrée et lit la partie du tableau qui appartient à sa tuile (il peut y avoir une limite au nombre de lecteurs pouvant ouvrir le même fichier NetCDF mais je ne suis pas sûr ). La sortie parallèle est plus problématique.

Ce que je fais actuellement n'est pas tout à fait optimal, mais fonctionne pour l'instant. Je rassemble le tout sur un processeur et fais la sortie série. En attendant, d'autres joueurs attendent la fin de l'écrivain. Cela a bien fonctionné pour moi car j'ai réussi à maintenir le rapport de calcul sur la sortie assez élevé - donc l'évolutivité serait bonne pour bien plus de 200 CPU. Mais ce n'est pas la solution que vous recherchez.

Une autre solution est ce que Yann a suggéré - écrire en série sur N fichiers et demander à un processeur de drone d'assembler les tuiles en une seule pièce - si la RAM le permet.

Outre les bibliothèques d'E / S parallèles suggérées dans les réponses précédentes, vous souhaiterez peut-être également consulter Parallel NetCDF http://trac.mcs.anl.gov/projects/parallel-netcdf , car vous êtes déjà à l'aise avec NetCDF et MPI. Je ne l'ai pas utilisé dans la pratique, mais je prévois d'aller dans cette direction lorsque je frapperai le mur avec la collecte + les E / S série.