Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve prometheus gpu_type fetching #90

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nurbal
Copy link
Collaborator

@nurbal nurbal commented Nov 28, 2023

Fixes the update_allocated_gpu_type function to increase gpu_type detection

https://mila-iqia.atlassian.net/browse/SARC-232

Tested on 2023-09-01 - 2023-11-27, results:

From 60696 jobs with prometheus stats:
38793 jobs with gpu_type detected
4709 jobs with gpu_type that were not detected before
0 regressions (jobs with gpu_type that were detected before but not anymore)
21903 jobs with no gpu_type detected

@nurbal nurbal requested a review from bouthilx November 28, 2023 03:21
@nurbal
Copy link
Collaborator Author

nurbal commented Nov 28, 2023

Le plantage lors de la génération de doc est un problème intriduit par le merge de la PR #86 . Apperemment j'ai été un peu trop pressé de merger 😬, alors que la CI plantait lors dela génération de doc... du coup le même problème affecte aussi la PR #89.

Le problème vient du fait que les notebooks sont exécutés pendant la génération de la doc, alors qu'ils essaient de se connecter à la base mongo qui n'est pas disponible dans cet environnement. @notoraptor est sur le coup pour désactiver leur exécution pendant la génération de la doc. ( PR #91 )

@nurbal nurbal marked this pull request as draft November 29, 2023 05:25
@@ -286,7 +286,6 @@ def update_allocated_gpu_type(cluster: ClusterConfig, entry: SlurmJob) -> Option
output = get_job_time_series(
job=entry,
metric="slurm_job_utilization_gpu_memory",
max_points=1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

J'ai peur que de carrément enlever max_points rende le query beaucoup plus couteux pour les longues jobs. Est-ce que d'augmenter max_points pourrait régler le problème? C'est un peu bizarre aussi comme problème, peut-être qu'il y a un bug dans get_job_time_series avec l'argument max_points.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Essais sur la journée du 3 septembre sur le cluster Mila:
sans limite de points:

From 138 jobs with prometheus stats:
97 jobs with gpu_type detected

max_points=1 :

From 138 jobs with prometheus stats:
36 jobs with gpu_type detected

max_points=2 :

From 138 jobs with prometheus stats:
58 jobs with gpu_type detected

Donc non, je ne crois pas qu'augmenter max_points à une valeur arbitraire règle le problème.

Je vais regarder si get_job_time_series n'est pas bugguée...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Le code source de get_job_time_series a comme paramètres par défaut:

    min_interval: int = 30,
    max_points: int = 100,

Ce qui signifie que tout job inférieur à 30s a des chances de passer entre les mailles du filet.

Je vais voir si je peux modifier l’appel à prometheus pour les cas où max_points=1 ou max_points=0 afin d'être certain de récupérer des informations sur le job, et aussi tester si avec des valeurs plus faibles pour min_interval on obtient d'autres résultats...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants