Exécuter l'optimisation pour un HealthOmics flux de travail privé

Le type de stockage d'exécution a un impact sur les performances d'exécution et le temps de provisionnement de l'exécution. Le stockage à exécution dynamique s'approvisionne plus rapidement et ne manque jamais de mémoire, car il évolue de manière dynamique en fonction de vos besoins en stockage d'exécution. Le stockage dynamique convient également aux flux de travail en cours de développement, dans lesquels vous pouvez souvent démarrer et arrêter un flux de travail pour résoudre des problèmes.

Le stockage à exécution statique nécessite des temps de provisionnement du système de fichiers plus longs, mais peut effectuer certaines exécutions plus rapidement, généralement si les exécutions comportent une grande simultanéité des tâches ou nécessitent une capacité de système de fichiers supérieure à 9,6 TiB. Le stockage statique convient parfaitement aux flux de travail de longue durée soumis à des I/O exigences élevées.

Pour vous aider à évaluer le coût par rapport aux performances de chaque type de stockage exécuté pour un cycle donné, vous pouvez effectuer des tests A/B pour déterminer quel type de stockage d'exécution offre les meilleures performances. Pensez également à utiliser le stockage dynamique pour vos cycles de développement, puis à utiliser le stockage statique pour les cycles de production à grande échelle.

Pour plus d'informations sur les types de stockage d'exécution Exécuter les types de stockage dans les HealthOmics flux de travail

Si le calcul des tâches de votre flux de travail est limité par des goulots d'I/O, consider over-provisioning the static run storage. Storage cost increases with its size, but maximum throughput of the file system also increases. If an expensive compute task is experiencing I/Oétranglement, l'augmentation de la taille du système de fichiers pour réduire le temps d'exécution des tâches peut réduire le coût global.

Lorsque chaque tâche démarre, HealthOmics charge le conteneur que vous avez spécifié pour la tâche. Les grands conteneurs prennent plus de temps à charger. Optimisez vos conteneurs pour qu'ils soient aussi petits que possible afin d'améliorer l'efficacité du lancement de nouvelles tâches. Si vous ajoutez de grands ensembles de données à vos conteneurs, envisagez de les stocker dans S3 et de demander à votre flux de travail d'importer les données depuis S3. Pour les tailles maximales de conteneurs HealthOmics compatibles, voirHealthOmics quotas de taille fixe du flux de travail.

Vous pouvez combiner de petites tâches séquentielles en une seule tâche afin de gagner du temps dans le provisionnement des tâches. De plus, la durée minimale des tâches HealthOmics est facturée d'une minute, de sorte que la combinaison des tâches peut réduire les coûts. Dans le cadre de la tâche combinée, vous pourrez peut-être utiliser des canaux Unix pour éviter les I/O coûts liés à la sérialisation et à la désérialisation des fichiers.

Évitez de trop compresser les fichiers intermédiaires du flux de travail. La plupart des formats génomiques utilisent la compression « gzip » ou « block gzip ». La décompression du fichier d'entrée de tâche et la recompression du fichier de sortie de tâche peuvent consommer un pourcentage important de l'utilisation totale du processeur de la tâche. Certaines applications de génomique vous permettent de définir le niveau de compression lors de la sérialisation des sorties. En réduisant le niveau de compression, vous pouvez réduire le temps du processeur, même si des fichiers plus volumineux augmentent le temps passé à écrire sur le disque. En fonction de la tâche et de l'application, vous pouvez trouver le niveau de compression optimal pour les fichiers intermédiaires dont le temps d'exécution est le plus court. Nous vous recommandons de commencer par cibler les tâches dont les fichiers de sortie sont les plus volumineux. Un niveau de compression de 2 fonctionne bien pour plusieurs scénarios. Vous pouvez commencer par ce niveau pour votre cas d'utilisation et comparer les résultats en essayant d'autres niveaux de compression.

Si vous spécifiez des threads dans votre définition de tâche, définissez le nombre de threads sur la même valeur que le nombre de threads demandésCPUs.

Si vous ne spécifiez pas de mémoire ou de ressources de calcul dans votre tâche, HealthOmics attribuez le type d'instance le plus petit (omics.c.large) par défaut. Déclarez explicitement vos besoins en mémoire et en calcul si vous HealthOmics souhaitez attribuer un type d'instance plus important.

HealthOmics alloue le nombre de ressources vCPUs, de mémoire et de GPU que vous demandez. Par exemple, si vous demandez 15 V CPUs et 33 Go, HealthOmics alloue une instance omics.m.4xl (16 V, 64 Go) à votre tâcheCPUs, mais celle-ci ne peut utiliser que 15 V et 33 Go. CPUs Par conséquent, nous vous recommandons de demander des ressources v CPUs et mémoire qui correspondent à une instance omics.

Comme le provisionnement du système de fichiers prend du temps au début de l'exécution, vous pouvez gagner du temps en regroupant plusieurs échantillons dans le même cycle. Tenez compte des facteurs suivants avant de choisir cette approche :

Paramétrez les images de vos conteneurs plutôt que de les intégrer URIs dans le flux de travail. Lorsqu'il s'agit de paramètres d'exécution, cela HealthOmics confirme que l'exécution a accès à vos conteneurs avant le début de l'exécution. Dans le cas contraire, la tâche échoue pendant l'exécution, lorsque vous avez engagé des frais pour toutes les tâches terminées. De plus, comme il s'agit d'entrées paramétrées, il HealthOmics génère une somme de contrôle dans le manifeste d'exécution, ce qui améliore la provenance des exécutions.

Utilisez un linter pour détecter les erreurs de flux de travail courantes avant d'exécuter un nouveau flux de travail. Pour de plus amples informations, veuillez consulter Linters de flux de travail dans HealthOmics.

Utilisez des alertes EventBridge personnalisées pour détecter les anomalies spécifiques à votre logique métier.

Envisagez d'utiliser un magasin de séquences pour vos données sources afin de réduire les coûts de stockage. Pour plus d'informations, consultez le billet de HealthOmics blog intitulé Store omics data de manière rentable à n'importe quelle échelle.

Essayez d'utiliser des données de test présentant une variance représentative pendant le développement.

Utilisez l'outil Run Analyzer sur divers échantillons pour tenir compte de la variation de la taille des données.

Vous pouvez utiliser l'analyseur de cycles pour comprendre la variance entre les cycles dans vos échantillons de données de production. Utilisez --batch le mode dans Run Analyzer pour générer des statistiques pour un lot d'exécutions et analyser les ressources de calcul maximales requises pour gérer les valeurs aberrantes de vos ensembles de données.

Par exemple, vous pouvez attribuer à Run Analyzer une cellule à flux complet de données en mode batch afin de comprendre les pics d'utilisation du vCPU et de la mémoire pour la cellule à flux complet.

Si vous constatez une forte variation de la taille des échantillons, vous pouvez diviser les échantillons en amont HealthOmics et sélectionner des tailles de système de fichiers différentes pour chaque lot afin de réduire les coûts de stockage.

Dans WDL, utilisez la size fonction pour bifurquer l'allocation des ressources pour les tâches individuelles pour les grands échantillons par rapport aux petits échantillons. Appliquez cette stratégie à vos tâches les plus coûteuses afin d'avoir le plus d'impact possible.

Dans Nextflow, utilisez des ressources conditionnelles pour hiérarchiser l'allocation des ressources en fonction de la taille ou du nom du fichier. Pour plus d'informations, consultez la section Ressources relatives aux processus conditionnels sur le GitHub site Nextflow.

Finalisez le code et la logique de votre flux de travail avant d'investir dans d'importants efforts d'optimisation des performances. La modification de votre code peut avoir un impact significatif sur les ressources requises. Si vous optimisez une exécution trop tôt dans le processus de développement, vous risquez de suroptimiser ou de devoir l'optimiser à nouveau si la définition du flux de travail change ultérieurement.

Si vous modifiez la définition de votre flux de travail au fil du temps ou si la variance de votre échantillon change, exécutez régulièrement l'outil Run Analyzer pour vous aider à effectuer des optimisations supplémentaires.