MemJobs - Revision history

Abailly: /* Configuration des worker nodes */

2017-04-27T14:06:15Z

Configuration des worker nodes

← Version précédente		Version du 16:06, 27 avril 2017
Ligne 78:		Ligne 78:
	\| Torque Maui		\| Torque Maui
	\| 2Go		\| 2Go
	~~\| Y~~
	~~\| vmem (pvmem)~~
	~~\| 4Go vmem, 3Go vmem/core (multicore)~~
	\| N		\| N
			\|
			\|
			\|
	\|		\|
	\|-		\|-

Sgadrat: /* CMS */

2017-03-27T16:59:19Z

CMS

← Version précédente		Version du 18:59, 27 mars 2017
Ligne 155:		Ligne 155:

	[Informations glanées en mars 2017]		[Informations glanées en mars 2017]

	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).		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).

Sgadrat: /* CMS */

2017-03-27T16:59:04Z

CMS

← Version précédente		Version du 18:59, 27 mars 2017
Ligne 153:		Ligne 153:

	===== CMS =====		===== CMS =====

			[Informations glanées en mars 2017]
	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).		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).

Sgadrat: /* CMS */

2017-03-27T16:40:55Z

CMS

← Version précédente		Version du 18:40, 27 mars 2017
Ligne 155:		Ligne 155:
	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).		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].		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]. Il s'agit donc essentiellement d'un monitoring ~temps réel effectué à partir des informations renvoyées par les pilotes tournant sur le site (rapport entre les ressources allouées par le site, et les ressources réellement consommées).

	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 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.

Khalfa: /* LHCb */

2017-03-24T16:02:09Z

LHCb

← Version précédente		Version du 18:02, 24 mars 2017
Ligne 172:		Ligne 172:

	===== LHCb =====		===== 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 ===		=== Besoins des sites ===

Khalfa: /* Consommation des jobs */

2017-03-24T09:26:54Z

Consommation des jobs

← Version précédente		Version du 11:26, 24 mars 2017
Ligne 104:		Ligne 104:
	T1prod: 1-1.5 GB		T1prod: 1-1.5 GB
	\| 3,5 GB (défaut CMS 2 GB en RSS)		\| 3,5 GB (défaut CMS 2 GB en RSS)
	\| 2 GB RSS 2 GB PSS		\| 2 GB RSS et 2 GB PSS
	\|		\|
	\|-		\|-

Khalfa: /* Consommation des jobs */

2017-03-24T09:22:04Z

Consommation des jobs

← Version précédente		Version du 11:22, 24 mars 2017
Ligne 104:		Ligne 104:
	T1prod: 1-1.5 GB		T1prod: 1-1.5 GB
	\| 3,5 GB (défaut CMS 2 GB en RSS)		\| 3,5 GB (défaut CMS 2 GB en RSS)
	\| 2 GB RSS		\| 2 GB RSS 2 GB PSS
	\| 2 GB PSS
	\|		\|
	\|-		\|-

Khalfa: /* Consommation des jobs */

2017-03-24T09:21:37Z

Consommation des jobs

← Version précédente		Version du 11:21, 24 mars 2017
Ligne 105:		Ligne 105:
	\| 3,5 GB (défaut CMS 2 GB en RSS)		\| 3,5 GB (défaut CMS 2 GB en RSS)
	\| 2 GB RSS		\| 2 GB RSS
			\| 2 GB PSS
	\|		\|
	\|-		\|-

Khalfa: /* Consommation des jobs */

2017-03-24T09:19:03Z

Consommation des jobs

← Version précédente		Version du 11:19, 24 mars 2017
Ligne 104:		Ligne 104:
	T1prod: 1-1.5 GB		T1prod: 1-1.5 GB
	\| 3,5 GB (défaut CMS 2 GB en RSS)		\| 3,5 GB (défaut CMS 2 GB en RSS)
	\| x		\| 2 GB RSS
	\|		\|
	\|-		\|-

Sgadrat: /* CMS */

2017-03-23T15:53:33Z

CMS

← Version précédente		Version du 17:53, 23 mars 2017
Ligne 154:		Ligne 154:
	===== CMS =====		===== 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).		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 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.