Nous avons un problème qui est embarrassant parallèle - nous exécutons un grand nombre d'instances d'un seul programme avec un ensemble de données différent pour chacun; Nous faisons cela simplement en soumettant l'application à plusieurs reprises à la file d'attente des lots avec différents paramètres à chaque fois.
Toutefois, avec un grand nombre d'emplois, pas tous terminés. Il ne semble pas être un problème dans la file d'attente - tous les emplois sont démarrés.
Le problème semble être celui avec un grand nombre d'instances de l'application en cours d'exécution, de nombreux travaux se terminent à peu près au même moment et tentent donc d'écrire leurs données sur le système de fichiers parallèle à peu près au même moment. .
Le problème semble alors que le programme est incapable d'écrire sur le système de fichiers et de se bloquer d'une certaine manière, ou si il suffit d'attendre d'écrire et que le système de file d'attente de lot tue le travail après qu'il a été assis trop longtemps. . (D'après ce que j'ai rassemblé sur le problème, la plupart des travaux qui ne fonctionnent pas, sinon tout, ne laissent pas de fichiers principaux)
Quelle est la meilleure façon de planifier les écrivies de disque pour éviter ce problème? Je mentionne que notre programme est embarrassant parallèle à mettre en évidence le fait que chaque processus n'est pas au courant des autres - ils ne peuvent pas se parler pour planifier leurs écritures de quelque manière que ce soit.
Bien que j'ai le code source du programme, nous aimerions résoudre le problème sans avoir à le modifier si possible si possible, car nous ne le maintenons ni ne le développent (plus la plupart des commentaires sont en italien). < / p>
J'ai eu quelques réflexions sur la question:
Entre-temps, j'ai besoin de pester mes superviseurs pour plus d'informations sur l'erreur elle-même - je ne l'ai jamais couru personnellement, mais je n'ai pas eu à utiliser le programme pour un très grand nombre de jeux de données (encore).
Dans le cas où il est utile: nous courons Solaris sur notre système HPC avec le système de file d'attente SGE (Sun Gridengine). Le système de fichiers est NFS4 et les serveurs de stockage exécutent également Solaris. Les nœuds de HPC et les serveurs de stockage communiquent sur des liaisons de canal de fibres.
3 Réponses :
Il est difficile de décider si vous ne savez pas ce qui cause exactement le crash. Si vous pensez que c'est une erreur liée aux performances du système de fichiers, vous pouvez essayer un système de fichiers distribués: http://hadoop.apache.org/common/docs/r0.20.0/hdfs_user_guide.html
Si vous souhaitez implémenter le système maître / esclave, peut-être que Hadoop peut être la réponse.
Mais tout d'abord, j'essaierais de découvrir ce qui provoque le crash ...
La plupart des systèmes de fichiers parallèles, en particulier ceux des centres de superinformation, sont ciblés pour les applications HPC, plutôt que des trucs de type série-Ferme. En conséquence, ils sont minutieusement optimisés pour la bande passante, pas pour les iops (Offices d'E / S par seconde) - c'est-à-dire qu'ils sont destinés aux emplois gros (1000+ processus) qui rédigent une poignée de fichiers de mammouth, plutôt que des zillions de petit Emplois émettant des octillions de petits fichiers minuscules. Il est tout à fait facile pour les utilisateurs de courir quelque chose qui fonctionne bien (ish) sur leur bureau et à l'échelle naïvement jusqu'à des centaines d'emplois simultanés pour affamer le système d'iops, suspendre leurs emplois et généralement d'autres sur les mêmes systèmes.
La principale chose que vous pouvez faire ici est globate, agrégat, agrégat. Il serait préférable que vous puissiez nous dire où vous courez afin que nous puissions obtenir plus d'informations sur le système. Mais certaines stratégies éprouvées:
Les suggestions ci-dessus profiteront aux performances d'E / S de votre code partout , pas seulement des systèmes de fichiers parallèles. IO est lent partout et plus vous pouvez faire en mémoire et moins les opérations d'Io réelles que vous exécutez, plus elle ira plus vite. Certains systèmes peuvent être plus sensibles que d'autres, vous ne le remarquerez pas beaucoup sur votre ordinateur portable, mais cela aidera.
De même, avoir moins de gros fichiers plutôt que de nombreux petits fichiers accéléreront tout des listes d'annuaires aux sauvegardes de votre système de fichiers; C'est bon tout autour.
S'il vous plaît pourriez-vous développer ce que vous voulez dire quand vous avez dit - "Dites-nous où suis-je en cours d'exécution"? Comme vous l'avez deviné, le système est optimisé pour le travail HPC (certains emplois que nous courons ici utilisent des milliers de noyaux pendant plus d'une demi-année).
Chaque travail se lit dans 3 fichiers (~ 5kb, 100 kb, 15 kb) et génère un couple de fichiers typiquement assez petits (~ 1 Mo et 5 Ko). Aucune recherche continue, cela ajoute simplement des informations aux fichiers de sortie. Ce comportement lui-même ne peut pas vraiment être changé. Binaire pourrait devenir un problème - les données peuvent être transférées à un système avec une endansion différente. Tarring peut être une bonne option. Comme je l'ai dit, je ne peux pas vraiment changer le comportement de l'application elle-même, il faudrait donc être associé à la rédaction des données ASCII sur un disque local, puis de passer des gares et de les transférer.
Oui, un autre problème est que d'autres emplois d'autres utilisateurs sont en cours d'exécution sur le même système, et parfois ceux-ci ne jouent pas si gentil.
Vous pouvez parcourir nos ressources informatiques ici si c'est ce que vous voulez dire: ICC.DUR .ac.uk / index.php? content = informatique / calcul - Bien qu'il manque notre dernier système pour une raison quelconque.
Ouais, je me demandais simplement ce que le système de fichiers était, bloque était, des choses comme ça. En outre, si vous utilisiez probablement plusieurs travaux par nœud - êtes-vous? Je n'ai pas réalisé que vous étiez à la CPI; Le code est-il quelque chose que je reconnais? Et dis-tu que le 1MB est ASCII? Ce n'est pas vraiment bon, pour les raisons de la vitesse et des iops que j'ai suggéré. HDF5 ou NetCDF, sont de beaux formats binaires qui font la conversion de Endian pour vous.
OUI 1MB est ASCII. Le code calcule la densité d'énergie spectrale de la galaxie en tenant compte des effets de l'absorption de la poussière et de la réémission et s'appelle Grasil. Ce n'est pas quelque chose que nous avons développé à Durham - il a été développé par groupe à Trieste. Vous pouvez trouver Info + code source d'une ancienne version du programme ici ici AdLibitum .oat.ts.tro.it / Silva / Grasil / Grasil.html
Oh et oui, avec des travaux parallèles embarrassants, il pourrait y avoir des travaux sans rapport sur le même noeud. Avec des travaux parallèles, vous pouvez le définir pour que vos processus fonctionnent uniquement sur chaque nœud. Bien que cela ne soit que la manière dont le système de lots est configuré - je pourrais peut-être demander que le travail ne sera exécuté que exclusivement sur les nœuds - je demanderai à la Sysadmin demain.
Je vois ce que vous voulez dire de ne pas pouvoir changer le comportement - on dirait qu'ils ne distribuent pas la source? Bah. Si vous pouvez prendre tout un nœud (probablement si vous demandez une valeur de nœud de nœuds, vous serez préférentiellement planifiée) Vous pouvez utiliser GNU parallèle (par exemple, support.scinet.utoronto.ca/wiki/index.php/... ) Pour exécuter n (ou peut-être 2-3 n) tâches dans un travail; Ensuite, celui-ci peut mettre en place toutes les entrées sur le disque local, faites tout ce que l'on écrit des sorties sur le disque local, puis le goudron qui définit les résultats et l'envoyer à / les données tout en une fois.
Non, avec des emplois parallèles embarrassants, vous ne demandez pas de noix de cœurs - vous venez de dire que je souhaite exécuter 1000 emplois, et dès qu'un noyau unique libère le système de lots commencera l'un de ces travaux. Donc, vous pouvez vous retrouver avec 1000 fonctionnant à la fois ou juste quelques-uns selon vos autres emplois en cours d'exécution / en file d'attente. Nous avons le code source de la version que nous utilisons, mais depuis son développement de l'extérieur, nous devrions leur demander d'accepter nos modifications.
adlibitum.to.ts.astro.it/silva/grasil/download. HTM - mais comme je le dis que c'est assez vieux.
D'accord, mais que font-ils pour des emplois parallèles non d'embarrasement? Vraisemblablement, vous pouvez obtenir des multiples de nœuds entiers de cette façon; Et si c'est la meilleure façon de lotter vos emplois série, alors soyez-le. Nous exigons fondamentalement des utilisateurs de tâches en série de le faire de cette façon. Si cela améliore les performances du système de fichiers, vous penseriez que les Sysadmins seraient heureux. À l'URL fournie, où est la source? J'ai tiré tous les fichiers .tgz et obtenez simplement des fichiers de données et un exécutable précompilé, aucune source à trouver.
AAH mon erreur, mes excuses, le code source est pas public alors. Oui, je vais demander à la Sysadmin demain sur le comportement et si nous pouvons le changer, il existe donc une limite sur le nombre maximum d'exécution à la fois. Ensuite, regardez un groupe d'emplois sur un nœud entier et combinant leur sortie en un transfert dans le système de fichiers partagé.
Les OSES ne se comportent pas toujours bien quand ils manquent de ressources; Parfois, ils abandonnent simplement le processus qui demande la première unité de ressources que le système d'exploitation ne peut pas fournir. De nombreux OSES ont des limites de ressources de la poignée de fichiers (Windows, Windows, Windows, a une ressource de plusieurs milliers de manipulations, que vous pouvez heurter dans des circonstances telles que la vôtre) et que vous ne trouvez pas de manche libre signifie généralement que le système d'exploitation fait de mauvaises choses au processus de requête.
Une solution simple nécessitant un changement de programme, est d'accepter que plus de N de vos nombreux emplois ne peut écrire à la fois. Vous aurez besoin d'un sémaphore partagé que tous les emplois peuvent voir; La plupart des OSES vous fourniront des installations pour un, souvent en tant que ressource nommée (!). Initialiser le sémaphore à n avant de lancer un travail. Demandez à chaque travail d'écriture acquiert une unité de ressource à partir du sémaphore lorsque le travail est sur le point d'écrire et de libérer cette unité de ressources lorsqu'elle est terminée. La quantité de code pour accomplir cela devrait être une poignée de lignes insérées une fois dans votre application hautement parallèle. Ensuite, vous ajustez n jusqu'à ce que vous n'aviez plus le problème. N == 1 1 le résoudra sûrement et vous pouvez probablement faire beaucoup mieux que cela.
Je pense que plus d'informations sur l'erreur sont nécessaires. Si l'application se bloque, c'est clairement plus qu'un simple goulot d'échelle d'E / S.
Sonne familier. Je surcharge régulièrement notre serveur NFS avec trop d'emplois.
Je ne peux que convenir - je suis la personne qui a été dit de résoudre le problème! D'après ce que je rassemble la plupart (sinon toutes) des travaux omis de terminer ne laissez pas de fichiers principaux. Je mettrai à jour demain avec plus d'informations quand je l'obtiens. J'aurais peut-être dû demander de bonnes stratégies pour éviter un goulot d'étranglement.
Vous devez étrangler l'écriture d'une manière comme un démarrage au profilage et à diagnostiquer ce qui cause le cou de la bouteille. Il y a toujours une ressource partagée finie dans chaque système parallèle, les E / S étant toujours l'un d'entre eux.
Qu'en est-il de l'utilisation des installations du système de file d'attente de lot? Peut-être commencer les emplois dans des groupes échelonnés? Ou si le problème est simplement que trop d'emplois fonctionnent pour certaines ressources, définissez une limite sur le nombre d'emplois simultanés. À moins que vous ne souhaitiez essayer au hasard des solutions, vous devez déterminer la cause des accidents.