lcgwiki - Contributions [en]

MemJobs

2017-03-24T16:02:09Z

Khalfa: /* LHCb */

=== Introduction ===

Cette page est destinée à centraliser les informations concernant la gestion de la mémoire des jobs LHC sur les worker des sites LCG France.
Les membres du projet LCG France sont invités à fournir sur cette page tout type d'information permettant au projet d'améliorer la gestion de la mémoire.
Voici quelques finalités :

* les achats de RAM sont-il adaptés ?
* les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire
* des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire
* ...

=== Configuration des worker nodes ===

Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.

{| class="wikitable"
|-
! Site

! Système de batch

! RAM/core

! Limitation mémoire
sur jobs (Y/N)

! Type de limite

! Seuil (GB)

! Dependance
selon VO (Y/N)

! Informations
Supplémentaires
|-
| CCIN2P3
| UGE
| 3GB
| Y
| vmem & rss
| [3-4] GB RSS
| Y
| Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.
|-
| CPPM
| Torque Maui
| 2, 2.5, 3 Go (selon wn)
| N
|
|
|
|
|-
| GRIF-LAL
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LLR
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LPNHE
| Torque Maui
| 2Go
| Y
| vmem (pvmem)
| 4Go vmem, 3Go vmem/core (multicore)
| N
|
|-
|}

=== Consommation des jobs ===

On reporte ici les valeurs typiques de consommation mémoire moyenne ''observée'' sur les workers (sur dashboard de site ou dashboard expérience). La mémoire peut être exprimée en VMEM, RSS ou PSS, et en GB/core

{| class="wikitable"
|-
! Site
! ALICE
! ATLAS
! CMS
! LHCb
! Observations
|-
| CCIN2P3
| 2.5 GB RSS
| T1pmc: 7.5 GB PSS vs 15 GB RSS
T1prod: 1-1.5 GB
| 3,5 GB (défaut CMS 2 GB en RSS)
| 2 GB RSS et 2 GB PSS
|
|-
| GRIF-LAL
| x
| x
| x
| 3.44 Go VMEM
|
|-
| GRIF-LLR
| x
| x
| x
| 3.31 Go VMEM
|
|-
| GRIF-LPNHE
| x
| x
| x
| 3.18 Go VMEM
|
|-
|}

=== Vision des expériences ===

Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.
La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...

===== ALICE =====
Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier.
Neanmoins on observe regulierement de grosses consommations de memoire, mais il est difficile de savoir aujourd'hui si ces valeurs sont transitoires ou constantes, d'ou la necessite d'analyser la consommation au fur et a mesure que le job se deroule.

===== ATLAS =====
Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/

- Recommendation: Mémoire 2Go/coeurs: couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'est fait mettre limite au moins 3x la mémoire.

-Au niveau de l'envoi des jobs de ATLAS, la sélection du site est fait en fonction de la mémoire demandée ( la mémoire nécessaire n'est pas remplie par l'utilisateur mais "calculée" je sais pas trop comment), donc un job demandant plus de 2 Go de mémoire n'est possible que sur les sites ayant une queue high memory. ATLAS n'insiste pas vraiment pour que les sites mettent à disposition ces queues, ie un petit nombre de site leur suffit.

[[image:Memjob_atlas-recommandation.pdf]]

===== CMS =====
Depuis le passage au multicore, la mémoire (RSS) est gérée "globalement" au niveau du pilote lui-même qui va essayer d'utiliser au mieux les ressources auxquelles il a accès (mémoire, CPU, disque). Le pilote adaptera ainsi les "types" de jobs (différentes configurations [job x core] possibles) et les payloads exécutés pour optimiser l'utilisation des ressources. Les ressources auxquelles il a accès dépendent du site, et sont configurés "en dur" au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la "VO Id card", mais celles-ci peuvent être modifiées en accord avec le site (c'est par exemple le cas du CC qui fournit plus de mémoire).

Pour le moment, CMS surveille ("monitore") la perte de ressources par rapport à ce que le site fournit. Un monitoring succinct est disponible [http://submit-3.t2.ucsd.edu/CSstoragePath/aperez/HTML/site_status/status_mcore_T1_FR_CCIN2P3.html ici].

CMS recommande de ne poser '''aucune limitation sur la mémoire''' (et en particulier sur la VMEM [*]). CMSSW utilise JEMALLOC pour l'allocation mémoire (la mémoire virtuelle est réellement allouée en RAM) mais aussi MADV_DONTNEED pour nettoyer la mémoire des pages non utilisées. Ce qui fait que la VMEM va nécessairement augmenter (et dans certains cas dans des proportions importantes, facteur ~5) alors que la mémoire RSS utilisée restera sous contrôle : stats pour des jobs 1-core obtenues sur 1 semaine : RSS ~1,5 GB, queue de la VMEM ~9,6 GB.

CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II).

[*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.

Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :
* Don't do any limits based on VSIZE.
* Don't enable swap.
* Do limit memory usage based on cgroups.
* No particular guidance on hard vs soft limits for cgroups. We have found hard limits are less problematic - seems there are a lot of kernel bugs around the reclaim path. But that's a very light suggestion.

===== LHCb =====

Pour lhcb, le changement de la limitation de la mémoire par MaxRSS au lieu MaxVMEM n'a pas rapporté aucun changement sur l'efficacité ou sur la quantité des jobs lhcb au CCIN2P3, parce que les jobs de lhcb au CCIN2P3 ne consomment pas trop mémoire.

Mais l'expérience considère depuis toujours que cette solution (MaxRSS + tuer le job) n'est pas du tout idéale parce que ça augmente le nombre des jobs tués à cause de débordement de la mémoire. C'est pour cela lhcb préfère d'utiliser cgroups pour limiter l'utilisation de RSS à 3GB par exemple, avec un espace de swap toujours disponible, mais sans tuer les jobs en aucun cas, c-a-d les jobs restent toujours running même s'il y a un de débordement de la mémoire.

=== Besoins des sites ===

Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.
Vous pouvez parler de monitoring, de communication avec les VOs ou sites, d'infrastructure matérielle, de documentation, ce que vous n'avez pas et que vous voudriez avoir.

MemJobs

2017-03-24T09:26:54Z

Khalfa: /* Consommation des jobs */

=== Introduction ===

Cette page est destinée à centraliser les informations concernant la gestion de la mémoire des jobs LHC sur les worker des sites LCG France.
Les membres du projet LCG France sont invités à fournir sur cette page tout type d'information permettant au projet d'améliorer la gestion de la mémoire.
Voici quelques finalités :

* les achats de RAM sont-il adaptés ?
* les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire
* des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire
* ...

=== Configuration des worker nodes ===

Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.

{| class="wikitable"
|-
! Site

! Système de batch

! RAM/core

! Limitation mémoire
sur jobs (Y/N)

! Type de limite

! Seuil (GB)

! Dependance
selon VO (Y/N)

! Informations
Supplémentaires
|-
| CCIN2P3
| UGE
| 3GB
| Y
| vmem & rss
| [3-4] GB RSS
| Y
| Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.
|-
| CPPM
| Torque Maui
| 2, 2.5, 3 Go (selon wn)
| N
|
|
|
|
|-
| GRIF-LAL
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LLR
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LPNHE
| Torque Maui
| 2Go
| Y
| vmem (pvmem)
| 4Go vmem, 3Go vmem/core (multicore)
| N
|
|-
|}

=== Consommation des jobs ===

On reporte ici les valeurs typiques de consommation mémoire moyenne ''observée'' sur les workers (sur dashboard de site ou dashboard expérience). La mémoire peut être exprimée en VMEM, RSS ou PSS, et en GB/core

{| class="wikitable"
|-
! Site
! ALICE
! ATLAS
! CMS
! LHCb
! Observations
|-
| CCIN2P3
| 2.5 GB RSS
| T1pmc: 7.5 GB PSS vs 15 GB RSS
T1prod: 1-1.5 GB
| 3,5 GB (défaut CMS 2 GB en RSS)
| 2 GB RSS et 2 GB PSS
|
|-
| GRIF-LAL
| x
| x
| x
| 3.44 Go VMEM
|
|-
| GRIF-LLR
| x
| x
| x
| 3.31 Go VMEM
|
|-
| GRIF-LPNHE
| x
| x
| x
| 3.18 Go VMEM
|
|-
|}

=== Vision des expériences ===

Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.
La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...

===== ALICE =====
Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier.
Neanmoins on observe regulierement de grosses consommations de memoire, mais il est difficile de savoir aujourd'hui si ces valeurs sont transitoires ou constantes, d'ou la necessite d'analyser la consommation au fur et a mesure que le job se deroule.

===== ATLAS =====
Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/

- Recommendation: Mémoire 2Go/coeurs: couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'est fait mettre limite au moins 3x la mémoire.

-Au niveau de l'envoi des jobs de ATLAS, la sélection du site est fait en fonction de la mémoire demandée ( la mémoire nécessaire n'est pas remplie par l'utilisateur mais "calculée" je sais pas trop comment), donc un job demandant plus de 2 Go de mémoire n'est possible que sur les sites ayant une queue high memory. ATLAS n'insiste pas vraiment pour que les sites mettent à disposition ces queues, ie un petit nombre de site leur suffit.

[[image:Memjob_atlas-recommandation.pdf]]

===== CMS =====
Depuis le passage au multicore, la mémoire (RSS) est gérée "globalement" au niveau du pilote lui-même qui va essayer d'utiliser au mieux les ressources auxquelles il a accès (mémoire, CPU, disque). Le pilote adaptera ainsi les "types" de jobs (différentes configurations [job x core] possibles) et les payloads exécutés pour optimiser l'utilisation des ressources. Les ressources auxquelles il a accès dépendent du site, et sont configurés "en dur" au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la "VO Id card", mais celles-ci peuvent être modifiées en accord avec le site (c'est par exemple le cas du CC qui fournit plus de mémoire).

Pour le moment, CMS surveille ("monitore") la perte de ressources par rapport à ce que le site fournit. Un monitoring succinct est disponible [http://submit-3.t2.ucsd.edu/CSstoragePath/aperez/HTML/site_status/status_mcore_T1_FR_CCIN2P3.html ici].

CMS recommande de ne poser '''aucune limitation sur la mémoire''' (et en particulier sur la VMEM [*]). CMSSW utilise JEMALLOC pour l'allocation mémoire (la mémoire virtuelle est réellement allouée en RAM) mais aussi MADV_DONTNEED pour nettoyer la mémoire des pages non utilisées. Ce qui fait que la VMEM va nécessairement augmenter (et dans certains cas dans des proportions importantes, facteur ~5) alors que la mémoire RSS utilisée restera sous contrôle : stats pour des jobs 1-core obtenues sur 1 semaine : RSS ~1,5 GB, queue de la VMEM ~9,6 GB.

CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II).

[*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.

Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :
* Don't do any limits based on VSIZE.
* Don't enable swap.
* Do limit memory usage based on cgroups.
* No particular guidance on hard vs soft limits for cgroups. We have found hard limits are less problematic - seems there are a lot of kernel bugs around the reclaim path. But that's a very light suggestion.

===== LHCb =====

=== Besoins des sites ===

Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.
Vous pouvez parler de monitoring, de communication avec les VOs ou sites, d'infrastructure matérielle, de documentation, ce que vous n'avez pas et que vous voudriez avoir.

MemJobs

2017-03-24T09:22:04Z

Khalfa: /* Consommation des jobs */

=== Introduction ===

Cette page est destinée à centraliser les informations concernant la gestion de la mémoire des jobs LHC sur les worker des sites LCG France.
Les membres du projet LCG France sont invités à fournir sur cette page tout type d'information permettant au projet d'améliorer la gestion de la mémoire.
Voici quelques finalités :

* les achats de RAM sont-il adaptés ?
* les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire
* des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire
* ...

=== Configuration des worker nodes ===

Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.

{| class="wikitable"
|-
! Site

! Système de batch

! RAM/core

! Limitation mémoire
sur jobs (Y/N)

! Type de limite

! Seuil (GB)

! Dependance
selon VO (Y/N)

! Informations
Supplémentaires
|-
| CCIN2P3
| UGE
| 3GB
| Y
| vmem & rss
| [3-4] GB RSS
| Y
| Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.
|-
| CPPM
| Torque Maui
| 2, 2.5, 3 Go (selon wn)
| N
|
|
|
|
|-
| GRIF-LAL
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LLR
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LPNHE
| Torque Maui
| 2Go
| Y
| vmem (pvmem)
| 4Go vmem, 3Go vmem/core (multicore)
| N
|
|-
|}

=== Consommation des jobs ===

On reporte ici les valeurs typiques de consommation mémoire moyenne ''observée'' sur les workers (sur dashboard de site ou dashboard expérience). La mémoire peut être exprimée en VMEM, RSS ou PSS, et en GB/core

{| class="wikitable"
|-
! Site
! ALICE
! ATLAS
! CMS
! LHCb
! Observations
|-
| CCIN2P3
| 2.5 GB RSS
| T1pmc: 7.5 GB PSS vs 15 GB RSS
T1prod: 1-1.5 GB
| 3,5 GB (défaut CMS 2 GB en RSS)
| 2 GB RSS 2 GB PSS
|
|-
| GRIF-LAL
| x
| x
| x
| 3.44 Go VMEM
|
|-
| GRIF-LLR
| x
| x
| x
| 3.31 Go VMEM
|
|-
| GRIF-LPNHE
| x
| x
| x
| 3.18 Go VMEM
|
|-
|}

=== Vision des expériences ===

Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.
La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...

===== ALICE =====
Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier.
Neanmoins on observe regulierement de grosses consommations de memoire, mais il est difficile de savoir aujourd'hui si ces valeurs sont transitoires ou constantes, d'ou la necessite d'analyser la consommation au fur et a mesure que le job se deroule.

===== ATLAS =====
Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/

- Recommendation: Mémoire 2Go/coeurs: couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'est fait mettre limite au moins 3x la mémoire.

-Au niveau de l'envoi des jobs de ATLAS, la sélection du site est fait en fonction de la mémoire demandée ( la mémoire nécessaire n'est pas remplie par l'utilisateur mais "calculée" je sais pas trop comment), donc un job demandant plus de 2 Go de mémoire n'est possible que sur les sites ayant une queue high memory. ATLAS n'insiste pas vraiment pour que les sites mettent à disposition ces queues, ie un petit nombre de site leur suffit.

[[image:Memjob_atlas-recommandation.pdf]]

===== CMS =====
Depuis le passage au multicore, la mémoire (RSS) est gérée "globalement" au niveau du pilote lui-même qui va essayer d'utiliser au mieux les ressources auxquelles il a accès (mémoire, CPU, disque). Le pilote adaptera ainsi les "types" de jobs (différentes configurations [job x core] possibles) et les payloads exécutés pour optimiser l'utilisation des ressources. Les ressources auxquelles il a accès dépendent du site, et sont configurés "en dur" au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la "VO Id card", mais celles-ci peuvent être modifiées en accord avec le site (c'est par exemple le cas du CC qui fournit plus de mémoire).

Pour le moment, CMS surveille ("monitore") la perte de ressources par rapport à ce que le site fournit. Un monitoring succinct est disponible [http://submit-3.t2.ucsd.edu/CSstoragePath/aperez/HTML/site_status/status_mcore_T1_FR_CCIN2P3.html ici].

CMS recommande de ne poser '''aucune limitation sur la mémoire''' (et en particulier sur la VMEM [*]). CMSSW utilise JEMALLOC pour l'allocation mémoire (la mémoire virtuelle est réellement allouée en RAM) mais aussi MADV_DONTNEED pour nettoyer la mémoire des pages non utilisées. Ce qui fait que la VMEM va nécessairement augmenter (et dans certains cas dans des proportions importantes, facteur ~5) alors que la mémoire RSS utilisée restera sous contrôle : stats pour des jobs 1-core obtenues sur 1 semaine : RSS ~1,5 GB, queue de la VMEM ~9,6 GB.

CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II).

[*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.

Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :
* Don't do any limits based on VSIZE.
* Don't enable swap.
* Do limit memory usage based on cgroups.
* No particular guidance on hard vs soft limits for cgroups. We have found hard limits are less problematic - seems there are a lot of kernel bugs around the reclaim path. But that's a very light suggestion.

===== LHCb =====

=== Besoins des sites ===

Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.
Vous pouvez parler de monitoring, de communication avec les VOs ou sites, d'infrastructure matérielle, de documentation, ce que vous n'avez pas et que vous voudriez avoir.

MemJobs

2017-03-24T09:21:37Z

Khalfa: /* Consommation des jobs */

=== Introduction ===

Cette page est destinée à centraliser les informations concernant la gestion de la mémoire des jobs LHC sur les worker des sites LCG France.
Les membres du projet LCG France sont invités à fournir sur cette page tout type d'information permettant au projet d'améliorer la gestion de la mémoire.
Voici quelques finalités :

* les achats de RAM sont-il adaptés ?
* les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire
* des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire
* ...

=== Configuration des worker nodes ===

Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.

{| class="wikitable"
|-
! Site

! Système de batch

! RAM/core

! Limitation mémoire
sur jobs (Y/N)

! Type de limite

! Seuil (GB)

! Dependance
selon VO (Y/N)

! Informations
Supplémentaires
|-
| CCIN2P3
| UGE
| 3GB
| Y
| vmem & rss
| [3-4] GB RSS
| Y
| Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.
|-
| CPPM
| Torque Maui
| 2, 2.5, 3 Go (selon wn)
| N
|
|
|
|
|-
| GRIF-LAL
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LLR
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LPNHE
| Torque Maui
| 2Go
| Y
| vmem (pvmem)
| 4Go vmem, 3Go vmem/core (multicore)
| N
|
|-
|}

=== Consommation des jobs ===

On reporte ici les valeurs typiques de consommation mémoire moyenne ''observée'' sur les workers (sur dashboard de site ou dashboard expérience). La mémoire peut être exprimée en VMEM, RSS ou PSS, et en GB/core

{| class="wikitable"
|-
! Site
! ALICE
! ATLAS
! CMS
! LHCb
! Observations
|-
| CCIN2P3
| 2.5 GB RSS
| T1pmc: 7.5 GB PSS vs 15 GB RSS
T1prod: 1-1.5 GB
| 3,5 GB (défaut CMS 2 GB en RSS)
| 2 GB RSS
| 2 GB PSS
|
|-
| GRIF-LAL
| x
| x
| x
| 3.44 Go VMEM
|
|-
| GRIF-LLR
| x
| x
| x
| 3.31 Go VMEM
|
|-
| GRIF-LPNHE
| x
| x
| x
| 3.18 Go VMEM
|
|-
|}

=== Vision des expériences ===

Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.
La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...

===== ALICE =====
Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier.
Neanmoins on observe regulierement de grosses consommations de memoire, mais il est difficile de savoir aujourd'hui si ces valeurs sont transitoires ou constantes, d'ou la necessite d'analyser la consommation au fur et a mesure que le job se deroule.

===== ATLAS =====
Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/

- Recommendation: Mémoire 2Go/coeurs: couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'est fait mettre limite au moins 3x la mémoire.

-Au niveau de l'envoi des jobs de ATLAS, la sélection du site est fait en fonction de la mémoire demandée ( la mémoire nécessaire n'est pas remplie par l'utilisateur mais "calculée" je sais pas trop comment), donc un job demandant plus de 2 Go de mémoire n'est possible que sur les sites ayant une queue high memory. ATLAS n'insiste pas vraiment pour que les sites mettent à disposition ces queues, ie un petit nombre de site leur suffit.

[[image:Memjob_atlas-recommandation.pdf]]

===== CMS =====
Depuis le passage au multicore, la mémoire (RSS) est gérée "globalement" au niveau du pilote lui-même qui va essayer d'utiliser au mieux les ressources auxquelles il a accès (mémoire, CPU, disque). Le pilote adaptera ainsi les "types" de jobs (différentes configurations [job x core] possibles) et les payloads exécutés pour optimiser l'utilisation des ressources. Les ressources auxquelles il a accès dépendent du site, et sont configurés "en dur" au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la "VO Id card", mais celles-ci peuvent être modifiées en accord avec le site (c'est par exemple le cas du CC qui fournit plus de mémoire).

Pour le moment, CMS surveille ("monitore") la perte de ressources par rapport à ce que le site fournit. Un monitoring succinct est disponible [http://submit-3.t2.ucsd.edu/CSstoragePath/aperez/HTML/site_status/status_mcore_T1_FR_CCIN2P3.html ici].

CMS recommande de ne poser '''aucune limitation sur la mémoire''' (et en particulier sur la VMEM [*]). CMSSW utilise JEMALLOC pour l'allocation mémoire (la mémoire virtuelle est réellement allouée en RAM) mais aussi MADV_DONTNEED pour nettoyer la mémoire des pages non utilisées. Ce qui fait que la VMEM va nécessairement augmenter (et dans certains cas dans des proportions importantes, facteur ~5) alors que la mémoire RSS utilisée restera sous contrôle : stats pour des jobs 1-core obtenues sur 1 semaine : RSS ~1,5 GB, queue de la VMEM ~9,6 GB.

CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II).

[*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.

Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :
* Don't do any limits based on VSIZE.
* Don't enable swap.
* Do limit memory usage based on cgroups.
* No particular guidance on hard vs soft limits for cgroups. We have found hard limits are less problematic - seems there are a lot of kernel bugs around the reclaim path. But that's a very light suggestion.

===== LHCb =====

=== Besoins des sites ===

Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.
Vous pouvez parler de monitoring, de communication avec les VOs ou sites, d'infrastructure matérielle, de documentation, ce que vous n'avez pas et que vous voudriez avoir.

MemJobs

2017-03-24T09:19:03Z

Khalfa: /* Consommation des jobs */

=== Introduction ===

Cette page est destinée à centraliser les informations concernant la gestion de la mémoire des jobs LHC sur les worker des sites LCG France.
Les membres du projet LCG France sont invités à fournir sur cette page tout type d'information permettant au projet d'améliorer la gestion de la mémoire.
Voici quelques finalités :

* les achats de RAM sont-il adaptés ?
* les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire
* des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire
* ...

=== Configuration des worker nodes ===

Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.

{| class="wikitable"
|-
! Site

! Système de batch

! RAM/core

! Limitation mémoire
sur jobs (Y/N)

! Type de limite

! Seuil (GB)

! Dependance
selon VO (Y/N)

! Informations
Supplémentaires
|-
| CCIN2P3
| UGE
| 3GB
| Y
| vmem & rss
| [3-4] GB RSS
| Y
| Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.
|-
| CPPM
| Torque Maui
| 2, 2.5, 3 Go (selon wn)
| N
|
|
|
|
|-
| GRIF-LAL
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LLR
| HTCondor
| 2Go
| N
|
|
|
|
|-
| GRIF-LPNHE
| Torque Maui
| 2Go
| Y
| vmem (pvmem)
| 4Go vmem, 3Go vmem/core (multicore)
| N
|
|-
|}

=== Consommation des jobs ===

On reporte ici les valeurs typiques de consommation mémoire moyenne ''observée'' sur les workers (sur dashboard de site ou dashboard expérience). La mémoire peut être exprimée en VMEM, RSS ou PSS, et en GB/core

{| class="wikitable"
|-
! Site
! ALICE
! ATLAS
! CMS
! LHCb
! Observations
|-
| CCIN2P3
| 2.5 GB RSS
| T1pmc: 7.5 GB PSS vs 15 GB RSS
T1prod: 1-1.5 GB
| 3,5 GB (défaut CMS 2 GB en RSS)
| 2 GB RSS
|
|-
| GRIF-LAL
| x
| x
| x
| 3.44 Go VMEM
|
|-
| GRIF-LLR
| x
| x
| x
| 3.31 Go VMEM
|
|-
| GRIF-LPNHE
| x
| x
| x
| 3.18 Go VMEM
|
|-
|}

=== Vision des expériences ===

Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.
La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...

===== ALICE =====
Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier.
Neanmoins on observe regulierement de grosses consommations de memoire, mais il est difficile de savoir aujourd'hui si ces valeurs sont transitoires ou constantes, d'ou la necessite d'analyser la consommation au fur et a mesure que le job se deroule.

===== ATLAS =====
Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/

- Recommendation: Mémoire 2Go/coeurs: couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'est fait mettre limite au moins 3x la mémoire.

-Au niveau de l'envoi des jobs de ATLAS, la sélection du site est fait en fonction de la mémoire demandée ( la mémoire nécessaire n'est pas remplie par l'utilisateur mais "calculée" je sais pas trop comment), donc un job demandant plus de 2 Go de mémoire n'est possible que sur les sites ayant une queue high memory. ATLAS n'insiste pas vraiment pour que les sites mettent à disposition ces queues, ie un petit nombre de site leur suffit.

[[image:Memjob_atlas-recommandation.pdf]]

===== CMS =====
Depuis le passage au multicore, la mémoire (RSS) est gérée "globalement" au niveau du pilote lui-même qui va essayer d'utiliser au mieux les ressources auxquelles il a accès (mémoire, CPU, disque). Le pilote adaptera ainsi les "types" de jobs (différentes configurations [job x core] possibles) et les payloads exécutés pour optimiser l'utilisation des ressources. Les ressources auxquelles il a accès dépendent du site, et sont configurés "en dur" au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la "VO Id card", mais celles-ci peuvent être modifiées en accord avec le site (c'est par exemple le cas du CC qui fournit plus de mémoire).

Pour le moment, CMS surveille ("monitore") la perte de ressources par rapport à ce que le site fournit. Un monitoring succinct est disponible [http://submit-3.t2.ucsd.edu/CSstoragePath/aperez/HTML/site_status/status_mcore_T1_FR_CCIN2P3.html ici].

CMS recommande de ne poser '''aucune limitation sur la mémoire''' (et en particulier sur la VMEM [*]). CMSSW utilise JEMALLOC pour l'allocation mémoire (la mémoire virtuelle est réellement allouée en RAM) mais aussi MADV_DONTNEED pour nettoyer la mémoire des pages non utilisées. Ce qui fait que la VMEM va nécessairement augmenter (et dans certains cas dans des proportions importantes, facteur ~5) alors que la mémoire RSS utilisée restera sous contrôle : stats pour des jobs 1-core obtenues sur 1 semaine : RSS ~1,5 GB, queue de la VMEM ~9,6 GB.

CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II).

[*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.

Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :
* Don't do any limits based on VSIZE.
* Don't enable swap.
* Do limit memory usage based on cgroups.
* No particular guidance on hard vs soft limits for cgroups. We have found hard limits are less problematic - seems there are a lot of kernel bugs around the reclaim path. But that's a very light suggestion.

===== LHCb =====

=== Besoins des sites ===

Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.
Vous pouvez parler de monitoring, de communication avec les VOs ou sites, d'infrastructure matérielle, de documentation, ce que vous n'avez pas et que vous voudriez avoir.