https://lcg.in2p3.fr/api.php?action=feedcontributions&feedformat=atom&user=Edith+Knoops 2026-04-17T09:25:01Z Contributions MediaWiki 1.43.1 https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8102 2017-03-23T10:00:35Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | 2.5 GB RSS<br /> | x<br /> | 3,5 GB (défaut CMS 2 GB en RSS)<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> - 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. <br /> <br /> -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 &quot;calculée&quot; 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. <br /> <br /> <br /> <br /> [[image:Memjob_atlas-recommandation.pdf]]<br /> <br /> <br /> <br /> ===== CMS =====<br /> Depuis le passage au multicore, la mémoire (RSS) est gérée &quot;globalement&quot; 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 &quot;types&quot; 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 &quot;en dur&quot; au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la &quot;VO Id card&quot;, 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).<br /> <br /> 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.<br /> <br /> CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II). <br /> <br /> <br /> [*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.<br /> <br /> <br /> Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :<br /> * Don't do any limits based on VSIZE.<br /> * Don't enable swap.<br /> * Do limit memory usage based on cgroups.<br /> * 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.<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8101 2017-03-23T09:54:41Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | 2.5 GB RSS<br /> | x<br /> | 3,5 GB (défaut CMS 2 GB en RSS)<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> - 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. <br /> <br /> -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 &quot;calculée&quot; 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. <br /> <br /> <br /> <br /> [[image:Memjob_atlas-recommandation.pdf]]<br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> Depuis le passage au multicore, la mémoire (RSS) est gérée &quot;globalement&quot; 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 &quot;types&quot; 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 &quot;en dur&quot; au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la &quot;VO Id card&quot;, 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).<br /> <br /> 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.<br /> <br /> CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II). <br /> <br /> <br /> [*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.<br /> <br /> <br /> Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :<br /> * Don't do any limits based on VSIZE.<br /> * Don't enable swap.<br /> * Do limit memory usage based on cgroups.<br /> * 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.<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8099 2017-03-23T09:51:50Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | 3,5 GB (défaut CMS 2 GB en RSS)<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> - 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. <br /> <br /> -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 &quot;calculée&quot; 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. <br /> <br /> <br /> <br /> [image:Memjob_atlas-recommandation.pdf]<br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> Depuis le passage au multicore, la mémoire (RSS) est gérée &quot;globalement&quot; 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 &quot;types&quot; 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 &quot;en dur&quot; au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la &quot;VO Id card&quot;, 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).<br /> <br /> 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.<br /> <br /> CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II). <br /> <br /> <br /> [*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.<br /> <br /> <br /> Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :<br /> * Don't do any limits based on VSIZE.<br /> * Don't enable swap.<br /> * Do limit memory usage based on cgroups.<br /> * 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.<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8098 2017-03-23T09:50:42Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | 3,5 GB (défaut CMS 2 GB en RSS)<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> - 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. <br /> <br /> -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 &quot;calculée&quot; 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. <br /> <br /> <br /> <br /> [image:Memjob_Atlas-recommandation.pdf]<br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> Depuis le passage au multicore, la mémoire (RSS) est gérée &quot;globalement&quot; 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 &quot;types&quot; 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 &quot;en dur&quot; au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la &quot;VO Id card&quot;, 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).<br /> <br /> 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.<br /> <br /> CMS utilise ~2GB par coeur (au 95ème centile pour les jobs de la phase II). <br /> <br /> <br /> [*] Ne pas empêcher l'overcommit de l'OS : vm.overcommit_memory mis à 0.<br /> <br /> <br /> Pour info, '''Brian's wishlist''' (CMS developer working on AAA/XRootD and HTCondor) :<br /> * Don't do any limits based on VSIZE.<br /> * Don't enable swap.<br /> * Do limit memory usage based on cgroups.<br /> * 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.<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=File:Memjob_atlas-recommandation.pdf&diff=8097 2017-03-23T09:47:07Z

<p>Edith Knoops: </p> <hr /> <div></div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8089 2017-03-22T14:12:18Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | 3,5 GB (défaut CMS 2 GB en RSS)<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> - 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. <br /> <br /> -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 &quot;calculée&quot; 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. <br /> <br /> <br /> <br /> <br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> Depuis le passage au multicore, la mémoire (RSS) est gérée &quot;globalement&quot; 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 &quot;types&quot; 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 &quot;en dur&quot; au niveau des factories. Par défaut, CMS se base sur les demandes de ressources figurant sur la &quot;VO Id card&quot;, 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).<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8086 2017-03-22T09:54:33Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | x<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> 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. <br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8085 2017-03-22T09:39:00Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | x<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> Recommendation: 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. <br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8084 2017-03-22T09:36:30Z

<p>Edith Knoops: /* ATLAS */</p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | x<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> Selon talk jamboree 2017 Alessandra Forti. https://indico.cern.ch/event/579473/<br /> <br /> recommendation couper sur smaps PSS ou cgroups RSS, couper sur vmem est déconseillé mais si c'st fait au moins 3x la mémoire. <br /> <br /> Memory<br /> ● Vmem: memory mapping in 64bit can be several times<br /> the actual memory used it doesn't mean it gets used. <br /> ● Smaps RSS: physical memory used by a job double<br /> counting the memory shared with other jobs <br /> ●<br /> ≠ from cgroups RSS<br /> ● Smaps PSS: physical memory used by a job without<br /> double counting ✓<br /> ● cgroups RSS: physical memory used by the jobs without<br /> double counting ✓<br /> ●<br /> Quantitatively similar smaps PSS<br /> What batch systems do?<br /> ●<br /> Batch systems without cgroups<br /> ● See the same RSS as reported in smaps<br /> ● Kill on vmem which is NOT a physical memory measure<br /> ●<br /> ●<br /> ●<br /> If you insist on this you need to set it at least 3 times the RAM<br /> requested by the job<br /> If you kill with the scheduler it is likely to the same problem<br /> Sites with cgroups<br /> ● Can setup soft and hard limits on the values the job reports<br /> ● Soft limit allows the kernel to decide if the job can keep on<br /> using the extra RAM or has to swap<br /> ● Hard limit will kill the job based on RAM<br /> ●<br /> Often set to 2 or 3 times the RAM requested by the job<br /> <br /> ===== CMS =====<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=MemJobs&diff=8083 2017-03-22T09:22:51Z

<p>Edith Knoops: </p> <hr /> <div>=== Introduction ===<br /> <br /> 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.<br /> 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.<br /> Voici quelques finalités :<br /> <br /> * les achats de RAM sont-il adaptés ?<br /> * les expériences sont-elles contente avec la façon dont les sites gèrent la mémoire<br /> * des efforts doivent-ils être fournis par les sites pour répondre à d'éventuels problèmes liés à la consommation de mémoire<br /> * ...<br /> <br /> === Configuration des worker nodes ===<br /> <br /> Merci d'indiquer dans cette section comment vos machines sont configurées pour gérer la mémoire consommée par les jobs.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> <br /> <br /> ! Système de batch<br /> <br /> <br /> ! RAM/core<br /> <br /> <br /> ! Limitation mémoire <br /> sur jobs (Y/N)<br /> <br /> ! Type de limite<br /> <br /> ! Seuil (GB)<br /> <br /> <br /> ! Dependance <br /> selon VO (Y/N)<br /> <br /> ! Informations<br /> Supplémentaires<br /> |-<br /> | CCIN2P3<br /> | UGE<br /> | 3GB<br /> | Y<br /> | vmem &amp; rss<br /> | [3-4] GB RSS<br /> | Y<br /> | Limites suffisent en general mais certains workloads speciaux ou temporaires peuvent necessiter des queues plus permissives.<br /> |-<br /> | CPPM<br /> | Torque Maui<br /> | 2, 2.5, 3 Go (selon wn)<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LAL<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LLR<br /> | HTCondor<br /> | 2Go<br /> | N<br /> | <br /> | <br /> | <br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | Torque Maui<br /> | 2Go<br /> | Y<br /> | vmem (pvmem)<br /> | 4Go vmem, 3Go vmem/core (multicore)<br /> | N<br /> |<br /> |-<br /> |}<br /> <br /> === Consommation des jobs ===<br /> <br /> 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<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Site<br /> ! ALICE<br /> ! ATLAS<br /> ! CMS<br /> ! LHCb<br /> ! Observations<br /> |-<br /> | CCIN2P3<br /> | x<br /> | x<br /> | x<br /> | x<br /> |<br /> |-<br /> | GRIF-LAL<br /> | x<br /> | x<br /> | x<br /> | 3.44 Go VMEM<br /> |<br /> |-<br /> | GRIF-LLR<br /> | x<br /> | x<br /> | x<br /> | 3.31 Go VMEM<br /> |<br /> |-<br /> | GRIF-LPNHE<br /> | x<br /> | x<br /> | x<br /> | 3.18 Go VMEM<br /> |<br /> |-<br /> |}<br /> <br /> === Vision des expériences ===<br /> <br /> Insérez ici ce que l’expérience souhaite comme type de limitation ou de gestion de la mémoire par les sites.<br /> La VMEM est-elle OK ? La RSS suffisante ? La PSS souhaitable ? ...<br /> <br /> ===== ALICE =====<br /> Pas d'etude serieuse menee jusqu'ici, et pas de besoin particulier. <br /> 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.<br /> <br /> ===== ATLAS =====<br /> <br /> ===== CMS =====<br /> <br /> ===== LHCb =====<br /> <br /> === Besoins des sites ===<br /> <br /> Insérez ici ce qu'il vous semble utile pour gérer efficacement la consommation de mémoire dans votre site.<br /> 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.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Tier_2:CPPM&diff=8013 2016-09-02T12:11:38Z

<p>Edith Knoops: </p> <hr /> <div>[[image:CPPMSmall.jpg]]<br /> *Responsable scientifique : François Touchard<br /> *Responsable technique : Edith Knoops<br /> *Autres personnes:<br /> **Site : Carlos Carranza, Thierry Mouthuy<br /> **ATLAS: Emmanuel Le Guirriec<br /> **LHCB : Andrei Tsaregorodtsev<br /> <br /> Le CPPM a installé en ses murs un noeud de calcul intégré à LCG pour permettre à ses physiciens de pouvoir participer efficacement aux analyses futures. Fin 2010 ce noeud passe du statut Tier3 à celui de Tier2 pour LCG<br /> <br /> Un projet M3AMU en collaboration avec le mesocentre de Marseille est en cours de demande financement(CPER/Feder). Il vise à mettre en ligne environ 5000 coeurs de calcul et un espace de stockage de l'ordre de 3-4 PO.<br /> <br /> &lt;b&gt;Pour le moment le site est équipé &lt;/b&gt;de : <br /> * 98 serveurs de calcul pour un total de 2000 coeurs<br /> en SL6 avec un scheduler Torque/maui<br /> <br /> &lt;b&gt;L'espace de stockage est un serveur DPM&lt;/b&gt;, séparé en :<br /> * marsedpm : Maître DPM.<br /> * 1,3 Po réparti sur 20 serveurs de disques connecté en 10 Gbps au réseau local.<br /> Données accessibles avec srm,gsiftp,xroot,dav <br /> <br /> <br /> <br /> &lt;b&gt;Réseau&lt;/b&gt; : Coeur de réseau 10 Gbit/s, double attachement 10 Gbps/s entre les switchs, 10 Gbit/s vers Renater<br /> <br /> Site information system: ldap://marbdii.in2p3.fr:2170/mds-vo-name=IN2P3-CPPM,o=grid<br /> &lt;br&gt;&lt;b&gt;Administrator contact&lt;/b&gt; : [mailto:gridadmin@cppm.in2p3.fr gridadmin@cppm.in2p3.fr]<br /> <br /> &lt;hr&gt;<br /> *LCG Grid Operations Centre's entry for this site: https://goc.egi.eu/portal/index.php?Page_Type=View_Object&amp;object_id=155&amp;grid_id=0 IN2P3-CPPM] ''(access granted by LCG user certificate)''<br /> *Supported LHC VOs: Atlas, LHCb<br /> *Supported non LHC VOs : Hone (H1), Biomed, Egeode, Esr, Dteam, Dzero<br /> *LCG Information System Monitor for this site: [http://goc.grid.sinica.edu.tw/gstat/IN2P3-CPPM/ IN2P3-CPPM]</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Tier_2:CPPM&diff=8012 2016-09-02T11:56:01Z

<p>Edith Knoops: </p> <hr /> <div>[[image:CPPMSmall.jpg]]<br /> *Responsable scientifique : François Touchard<br /> *Responsable technique : Edith Knoops<br /> *Autres personnes:<br /> **Site : Carlos Carranza, Thierry Mouthuy<br /> **ATLAS: Emmanuel Le Guirriec<br /> **LHCB : Andrei Tsaregorodtsev<br /> <br /> Le CPPM a installé en ses murs un noeud de calcul intégré à LCG pour permettre à ses physiciens de pouvoir participer efficacement aux analyses futures. Fin 2010 ce noeud passe du statut Tier3 à celui de Tier2 pour LCG<br /> <br /> Un projet M3AMU en collaboration avec le mesocentre de Marseille est en cours de demande financement(CPER/Feder). Il vise à mettre en ligne environ 5000 coeurs de calcul et un espace de stockage de l'ordre de 3-4 PO.<br /> <br /> &lt;b&gt;Pour le moment le site est équipé &lt;/b&gt;de : <br /> * 98 serveurs de calcul pour un total de 2000 coeurs<br /> en SL6 avec un scheduler Torque/maui<br /> <br /> &lt;b&gt;L'espace de stockage est un serveur DPM&lt;/b&gt;, séparé en :<br /> * marsedpm : Maître DPM.<br /> * 1Po réparti sur 20 serveurs de disques connecté en 10 Gbps au réseau local.<br /> Données accessibles avec srm,gsiftp,xroot,dav <br /> <br /> <br /> <br /> &lt;b&gt;Réseau&lt;/b&gt; : Coeur de réseau 10 Gbit/s, double attachement 10 Gbps/s entre les switchs, 10 Gbit/s vers Renater<br /> <br /> Site information system: ldap://marbdii.in2p3.fr:2170/mds-vo-name=IN2P3-CPPM,o=grid<br /> &lt;br&gt;&lt;b&gt;Administrator contact&lt;/b&gt; : [mailto:gridadmin@cppm.in2p3.fr gridadmin@cppm.in2p3.fr]<br /> <br /> &lt;hr&gt;<br /> *LCG Grid Operations Centre's entry for this site: https://goc.egi.eu/portal/index.php?Page_Type=View_Object&amp;object_id=155&amp;grid_id=0 IN2P3-CPPM] ''(access granted by LCG user certificate)''<br /> *Supported LHC VOs: Atlas, LHCb<br /> *Supported non LHC VOs : Hone (H1), Biomed, Egeode, Esr, Dteam, Dzero<br /> *LCG Information System Monitor for this site: [http://goc.grid.sinica.edu.tw/gstat/IN2P3-CPPM/ IN2P3-CPPM]</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=ExtensionGarantie&diff=6450 2012-05-15T07:31:05Z

<p>Edith Knoops: </p> <hr /> <div><br /> Point sur les extensions de garantie matérielle dans les sites LCG-France<br /> --[[User:Chollet]] 16:22, 7 mai 2012 (CEST)<br /> === LCG-France ===<br /> Règle actuelle : 4 ans pour toutes les ressources et tous les sites &lt;br&gt;<br /> Question ouverte : '''Est-il raisonnable de passer à 5 ans (au moins dur les disques) dans l'ensemble des sites, et ce à compter de 2010 ?'''<br /> <br /> === CC ===<br /> * Disque : 5 ans depuis 2010<br /> * CPU : 5 ans depuis 2011 (pas d'achat CPU en 2010)<br /> * MSS : A nas (à préciser pour les achats de lecteurs T10KC)<br /> <br /> === SUBATECH ===<br /> * CPU : 3 ans<br /> * Disque : 5 ans depuis 2009<br /> <br /> === LAPP ===<br /> * CPU : 5 ans à partir de 2012 ( 3 ans avant) <br /> * Disque : 5 ans à partir de 2012 ( 4 ans avant)<br /> <br /> === LPC ===<br /> * CPU : 4 ans à partir de fin 2011 ( 3 ans avant ) - 5 ans à partir de 2012 <br /> * Disque : 5 ans à partir de 2010 ( 3 ans avant )<br /> <br /> === CPPM ===<br /> * CPU : 3 ans<br /> * Disque : 4 ans</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Tier_2:CPPM&diff=5886 2010-09-21T13:40:07Z

<p>Edith Knoops: </p> <hr /> <div>[[image:CPPM.gif]]<br /> *Responsable scientifique : François Touchard<br /> *Responsable technique : Edith Knoops<br /> *Autres personnes:<br /> *Site : Carlos Carranza, Thierry Mouthuy, Michel Ricard<br /> *ATLAS: Emmanuel Le Guirriec<br /> *LHCB : Andrei Tsaregorodtsev<br /> <br /> Le CPPM a installé en ses murs un noeud de calcul intégré à LCG pour permettre à ses physiciens de pouvoir participer efficacement aux analyses futures. Fin 2010 ce moeud passe du statut Tier3 à celui de Tier2 pour LCG<br /> <br /> Un projet de grille de campus (LuminyGrid) est en cours d'étude. Il vise à mettre en ligne environ 6000 coeurs de calcul et un espace de stockage de l'ordre de 3PO.<br /> <br /> &lt;b&gt;Pour le moment le site est équipé &lt;/b&gt;de :<br /> * 8 serveurs bi-processeurs (Opteron 2.4 GHz) avec 4 GO de mémoire <br /> * 15 serveurs bi-processeurs bi-coeur (Opteron 2.2 GHz) avec 6 GO de mémoire (3 coeurs activés) <br /> * 10 serveurs (Opteron 2218 bi-processeurs bi-coeur) avec 8 GO de mémoire<br /> * 46 serveurs (Xeon 5420 bi-pro quadri-coeurs) avec 16 GO de mémoire<br /> * 11 serveur (Xeon X5650 bi-pro hexa-coeurs) avec 48 GO de mémire<br /> soit 645 noeuds de calcul. Les noeuds de calcul sont installés en SL5-64 bits avec les librairies compatibles. <br /> <br /> &lt;b&gt;L'espace de stockage est un serveur DPM&lt;/b&gt;, séparé en 10 serveurs :<br /> * marsedpm : Maitre DPM.<br /> * marjoe : Baie de disques avec des espaces communs, de groupe et réservés. L'espace utile total pour la grille est de l'ordre de 30 TO. Le serveur frontal est connecté au réseau local en mode &quot;trunk&quot; de 2x1Gbps.<br /> * marjack : Deux baies de 15 disques de 1TO brut chacune, soit 30 TO bruts. Le serveur frontal est connecté au réseau local en 10 Gbps<br /> * marbill : Connecté à un NETAPP capacité de 50 TO net. <br /> * 6 serveurs avec chacun 12 disques de 2 TO, connecté en 10 Gbps au réseau local.<br /> <br /> &lt;b&gt;Le site dispose également &lt;/b&gt;:<br /> * un WMS : marwms.in2p3.fr associé à une machine LB : marlb.in2p3.fr<br /> * un serveur VOMS (pour la VO CPPM) : marvoms.in2p3.fr<br /> * une interface utilisateur : marui.in2p3.fr<br /> <br /> &lt;b&gt;Réseau&lt;/b&gt; : Coeur de réseau 10 Gbit/s, double attachement 10 Gbps/s entre les switchs, 1 Gbit/s vers Renater<br /> <br /> Site information system: ldap://marbdii.in2p3.fr:2170/mds-vo-name=IN2P3-CPPM,o=grid<br /> &lt;br&gt;&lt;b&gt;Administrator contact&lt;/b&gt; : [mailto:gridadmin@cppm.in2p3.fr gridadmin@cppm.in2p3.fr]<br /> <br /> &lt;hr&gt;<br /> *LCG Grid Operations Centre's entry for this site: [https://goc.gridops.org/site/list?id=143 IN2P3-CPPM] ''(access granted by LCG user certificate)''<br /> *Supported LHC VOs: Atlas,LHCb<br /> *Supported non LHC VOs : Hone (H1), Biomed, Egeode, Esr, Dteam<br /> *LCG Information System Monitor for this site: [http://goc.grid.sinica.edu.tw/gstat/IN2P3-CPPM/ IN2P3-CPPM]</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Tier_2:CPPM&diff=5885 2010-09-21T13:35:21Z

<p>Edith Knoops: </p> <hr /> <div>[[image:CPPM.gif]]<br /> *Responsable scientifique : François Touchard<br /> *Responsable technique : Edith Knoops<br /> *Autres personnes: Carlos Carranza, Thierry Mouthuy, Michel Ricard<br /> <br /> Le CPPM a installé en ses murs un noeud de calcul intégré à LCG pour permettre à ses physiciens de pouvoir participer efficacement aux analyses futures. Fin 2010 ce moeud passe du statut Tier3 à celui de Tier2 pour LCG<br /> <br /> Un projet de grille de campus (LuminyGrid) est en cours d'étude. Il vise à mettre en ligne environ 6000 coeurs de calcul et un espace de stockage de l'ordre de 3PO.<br /> <br /> &lt;b&gt;Pour le moment le site est équipé &lt;/b&gt;de :<br /> * 8 serveurs bi-processeurs (Opteron 2.4 GHz) avec 4 GO de mémoire <br /> * 15 serveurs bi-processeurs bi-coeur (Opteron 2.2 GHz) avec 6 GO de mémoire (3 coeurs activés) <br /> * 10 serveurs (Opteron 2218 bi-processeurs bi-coeur) avec 8 GO de mémoire<br /> * 46 serveurs (Xeon 5420 bi-pro quadri-coeurs) avec 16 GO de mémoire<br /> * 11 serveur (Xeon X5650 bi-pro hexa-coeurs) avec 48 GO de mémire<br /> soit 645 noeuds de calcul. Les noeuds de calcul sont installés en SL5-64 bits avec les librairies compatibles. <br /> <br /> &lt;b&gt;L'espace de stockage est un serveur DPM&lt;/b&gt;, séparé en 10 serveurs :<br /> * marsedpm : Maitre DPM.<br /> * marjoe : Baie de disques avec des espaces communs, de groupe et réservés. L'espace utile total pour la grille est de l'ordre de 30 TO. Le serveur frontal est connecté au réseau local en mode &quot;trunk&quot; de 2x1Gbps.<br /> * marjack : Deux baies de 15 disques de 1TO brut chacune, soit 30 TO bruts. Le serveur frontal est connecté au réseau local en 10 Gbps<br /> * marbill : Connecté à un NETAPP capacité de 50 TO net. <br /> * 6 serveurs avec chacun 12 disques de 2 TO, connecté en 10 Gbps au réseau local.<br /> <br /> &lt;b&gt;Le site dispose également &lt;/b&gt;:<br /> * un WMS : marwms.in2p3.fr associé à une machine LB : marlb.in2p3.fr<br /> * un serveur VOMS (pour la VO CPPM) : marvoms.in2p3.fr<br /> * une interface utilisateur : marui.in2p3.fr<br /> <br /> &lt;b&gt;Réseau&lt;/b&gt; : Coeur de réseau 10 Gbit/s, double attachement 10 Gbps/s entre les switchs, 1 Gbit/s vers Renater<br /> <br /> Site information system: ldap://marbdii.in2p3.fr:2170/mds-vo-name=IN2P3-CPPM,o=grid<br /> &lt;br&gt;&lt;b&gt;Administrator contact&lt;/b&gt; : [mailto:gridadmin@cppm.in2p3.fr gridadmin@cppm.in2p3.fr]<br /> <br /> &lt;hr&gt;<br /> *LCG Grid Operations Centre's entry for this site: [https://goc.gridops.org/site/list?id=143 IN2P3-CPPM] ''(access granted by LCG user certificate)''<br /> *Supported LHC VOs: Atlas,LHCb<br /> *Supported non LHC VOs : Hone (H1), Biomed, Egeode, Esr, Dteam<br /> *LCG Information System Monitor for this site: [http://goc.grid.sinica.edu.tw/gstat/IN2P3-CPPM/ IN2P3-CPPM]</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Tier_2:CPPM&diff=5883 2010-09-17T14:35:01Z

<p>Edith Knoops: </p> <hr /> <div>[[image:CPPM.gif]]<br /> *Responsable scientifique : François Touchard<br /> *Responsable technique : Edith Knoops<br /> *Autres personnes: Carlos Carranza, Thierry Mouthuy, Michel Ricard<br /> <br /> Le CPPM a installé en ses murs un noeud de calcul Tier-2 intégré à LCG pour permettre à ses physiciens de pouvoir participer efficacement aux analyses futures.<br /> <br /> Un projet de grille de campus (LuminyGrid) est en cours d'étude. Il vise à mettre en ligne environ 6000 coeurs de calcul et un espace de stockage de l'ordre de 3PO.<br /> <br /> &lt;b&gt;Pour le moment le site est équipé &lt;/b&gt;de :<br /> * 8 serveurs bi-processeurs (Opteron 2.4 GHz) avec 4 GO de mémoire <br /> * 15 serveurs bi-processeurs bi-coeur (Opteron 2.2 GHz) avec 6 GO de mémoire (4 coeurs activés) <br /> * 10 serveurs (Opteron 2218 bi-processeurs bi-coeur) avec 8 GO de mémoire<br /> * 45 serveurs (Xeon 5420 bi-pro quadri-coeurs) avec 16 GO de mémoire<br /> soit 476 noeuds de calcul. Les noeuds de calcul sont installés en SL5-64 bits avec les librairies compatibles. <br /> <br /> &lt;b&gt;L'espace de stockage est un serveur DPM&lt;/b&gt;, séparé en 3 serveurs :<br /> * marsedpm : Maitre DPM.<br /> * marjoe : Baie de disques avec des espaces communs, de groupe et réservés. L'espace utile total pour la grille est de l'ordre de 30 TO. Le serveur frontal est connecté au réseau local en mode &quot;trunk&quot; de 2x1Gbps.<br /> * marjack : Deux baies de 15 disques de 1TO brut chacune, soit 30 TO bruts. Le serveur frontal est connecté au réseau local en mode &quot;trunk&quot; de 2x1Gbps<br /> <br /> &lt;b&gt;Le site dispose également &lt;/b&gt;:<br /> * un WMS : marwms.in2p3.fr associé à une machine LB : marlb.in2p3.fr<br /> * un serveur VOMS (pour la VO CPPM) : marvoms.in2p3.fr<br /> * une interface utilisateur : marui.in2p3.fr<br /> <br /> &lt;b&gt;Réseau&lt;/b&gt; : 1 Gbit/s entre les éléments du site, 1 Gbit/s vers Renater<br /> <br /> Site information system: ldap://marce01.in2p3.fr:2170/mds-vo-name=IN2P3-CPPM,o=grid<br /> &lt;br&gt;&lt;b&gt;Administrator contact&lt;/b&gt; : [mailto:gridadmin@cppm.in2p3.fr gridadmin@cppm.in2p3.fr]<br /> <br /> &lt;hr&gt;<br /> *LCG Grid Operations Centre's entry for this site: [https://goc.gridops.org/site/list?id=143 IN2P3-CPPM] ''(access granted by LCG user certificate)''<br /> *Supported LHC VOs: Atlas,LHCb<br /> *Supported non LHC VOs : Hone (H1), Biomed, Egeode, Esr, Dteam<br /> *LCG Information System Monitor for this site: [http://goc.grid.sinica.edu.tw/gstat/IN2P3-CPPM/ IN2P3-CPPM]</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=French_Sites&diff=5876 2010-09-17T13:38:26Z

<p>Edith Knoops: /* Tiers 2 :CPPM (Marseille) - GRIF (Ile de France) - IPHC (Strasbourg) - LAPP (Annecy)&lt;br&gt;LPC (Clermont-Ferrand) - Subatech (Nantes) */</p> <hr /> <div>__NOTOC__<br /> == ''Welcome to the LCG-France sites page'' ==<br /> ===== Tier 1 : [[Tier_1:CCIN2P3| CC IN2P3 (Lyon)]] =====<br /> ===== Tiers 2 : [[Tier_2:CPPM|CPPM (Marseille)]] - [[Tier_2:GRIF|GRIF (Ile de France)]] - [[Tier_2:IPHC|IPHC (Strasbourg)]] - [[Tier_2:LAPP|LAPP (Annecy)]]&lt;br&gt;[[Tier_2:LPC|LPC (Clermont-Ferrand)]] - [[Tier_2:Subatech|Subatech (Nantes)]] =====<br /> <br /> ===== Tiers 3 : [[Tier_3:IPNL|IPNL (Lyon)]] - [[Tier_3:LPSC|LPSC (Grenoble)]]=====<br /> [[Image:2010-09-LCGFrance-sites-small.PNG]]<br /> &lt;br&gt;<br /> ''Septembre 2010''</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=French_Sites&diff=5875 2010-09-17T13:36:34Z

<p>Edith Knoops: /* Tiers 2 : CPPM (Marseille) -GRIF (Ile de France) - IPHC (Strasbourg) - LAPP (Annecy)&lt;br&gt;LPC (Clermont-Ferrand) - Subatech (Nantes) */</p> <hr /> <div>__NOTOC__<br /> == ''Welcome to the LCG-France sites page'' ==<br /> ===== Tier 1 : [[Tier_1:CCIN2P3| CC IN2P3 (Lyon)]] =====<br /> ===== Tiers 2 :[[Tier_2:CPPM|CPPM (Marseille)]] - [[Tier_2:GRIF|GRIF (Ile de France)]] - [[Tier_2:IPHC|IPHC (Strasbourg)]] - [[Tier_2:LAPP|LAPP (Annecy)]]&lt;br&gt;[[Tier_2:LPC|LPC (Clermont-Ferrand)]] - [[Tier_2:Subatech|Subatech (Nantes)]] =====<br /> <br /> ===== Tiers 3 : [[Tier_3:IPNL|IPNL (Lyon)]] - [[Tier_3:LPSC|LPSC (Grenoble)]]=====<br /> [[Image:2010-09-LCGFrance-sites-small.PNG]]<br /> &lt;br&gt;<br /> ''Septembre 2010''</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=French_Sites&diff=5874 2010-09-17T13:33:02Z

<p>Edith Knoops: /* Tiers 2 : GRIF (Ile de France) - IPHC (Strasbourg) - LAPP (Annecy)&lt;br&gt;LPC (Clermont-Ferrand) - Subatech (Nantes) */</p> <hr /> <div>__NOTOC__<br /> == ''Welcome to the LCG-France sites page'' ==<br /> ===== Tier 1 : [[Tier_1:CCIN2P3| CC IN2P3 (Lyon)]] =====<br /> ===== Tiers 2 : [[Tier_2:CPPM|CPPM (Marseille)]] -[[Tier_2:GRIF|GRIF (Ile de France)]] - [[Tier_2:IPHC|IPHC (Strasbourg)]] - [[Tier_2:LAPP|LAPP (Annecy)]]&lt;br&gt;[[Tier_2:LPC|LPC (Clermont-Ferrand)]] - [[Tier_2:Subatech|Subatech (Nantes)]] =====<br /> <br /> ===== Tiers 3 : [[Tier_3:IPNL|IPNL (Lyon)]] - [[Tier_3:LPSC|LPSC (Grenoble)]]=====<br /> [[Image:2010-09-LCGFrance-sites-small.PNG]]<br /> &lt;br&gt;<br /> ''Septembre 2010''</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=French_Sites&diff=5873 2010-09-17T13:32:30Z

<p>Edith Knoops: /* Tiers 3 : CPPM (Marseille) - IPNL (Lyon) - LPSC (Grenoble) */</p> <hr /> <div>__NOTOC__<br /> == ''Welcome to the LCG-France sites page'' ==<br /> ===== Tier 1 : [[Tier_1:CCIN2P3| CC IN2P3 (Lyon)]] =====<br /> ===== Tiers 2 : [[Tier_2:GRIF|GRIF (Ile de France)]] - [[Tier_2:IPHC|IPHC (Strasbourg)]] - [[Tier_2:LAPP|LAPP (Annecy)]]&lt;br&gt;[[Tier_2:LPC|LPC (Clermont-Ferrand)]] - [[Tier_2:Subatech|Subatech (Nantes)]] =====<br /> <br /> ===== Tiers 3 : [[Tier_3:IPNL|IPNL (Lyon)]] - [[Tier_3:LPSC|LPSC (Grenoble)]]=====<br /> [[Image:2010-09-LCGFrance-sites-small.PNG]]<br /> &lt;br&gt;<br /> ''Septembre 2010''</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=CPU-Benches&diff=5400 2009-10-02T07:25:58Z

<p>Edith Knoops: /* Résultats des benchs effectués par les sites */</p> <hr /> <div>'''Transition vers les nouvelles unités specs HEP-SPEC06'''<br /> --MàJ --[[User:Chollet|Chollet]] 09:37, 11 septembre 2009 (CEST)--<br /> <br /> === Page HEPiX de référence === <br /> * https://hepix.caspur.it/benchmarks<br /> <br /> === Stratégie LCG ===<br /> * LCG Overview Board - Change of CPU accounting unit (I.Bird):<br /> ''The working group on benchmarking has now concluded, both on the new benchmark and on the transition process from SI2K. A new benchmark, based on the SPEC 2006 suite has been agreed upon. This uses a combination of the SPEC2006 FP and INT benchmarks, and has been shown to scale well with the experiments’ applications. This benchmark, labelled HEP-SPEC06, will be used in future to specify requirements and resources. '''There is an agreement to use a simple conversion factor of 4 representing the benchmarks ratio HEP-SPEC06/kSI2K'''. Sites will be requested to benchmark their existing resources, and the results will be published on a web site. Future procurements should require the vendor to run the benchmark – provided as a simple script. Planning for changing the reporting in the accounting system is under way. The new unit will be used in the April RRB.''<br /> <br /> * LCG Management Board : [https://twiki.cern.ch/twiki/pub/LCG/MbMeetingsMinutes/LCG_Management_Board_2009_01_27.htm Décision du MB du 27 janvier 2009] s'appuyant sur la [http://indico.cern.ch/materialDisplay.py?contribId=3&amp;sessionId=0&amp;materialId=0&amp;confId=49388 proposition du groupe technique (G.Merino)] <br /> * Pledges WLCG en HEP-SPEC06 : http://lcg.web.cern.ch/LCG/resources.htm<br /> <br /> === HEP-SPEC06 Benchmark ===<br /> *Le script dispo à https://twiki.cern.ch/twiki/bin/view/FIOgroup/TsiBenchHEPSPEC (Voir les attachements en bas de page tar.gz)<br /> <br /> * La distribution de la suite SPEC CPU2006 version 1.1 est disponible (sous AFS au CC).<br /> Pour plus d'infos contacter F.Chollet ou Pierre Larrieu<br /> <br /> === Conversion des kSI2k ===<br /> * Facteur de conversion HEP-SPEC06/kSI2k : 4<br /> * 1 kSI2k = 4 HEP-SPEC06<br /> <br /> === Publication des capacités CPU ===<br /> * Document de référence pour la publication dans le contexte actuel (Glue schema 1.3): <br /> https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/WLCG_GlueSchemaUsage-1.8.pdf &lt;br&gt;<br /> <br /> Tentative de synthèse --[[User:Chollet|Chollet]] 09:46, 11 septembre 2009 (CEST)<br /> ** PhysicalCPUs = processeurs c.a.d chipset<br /> Un subcluster de 113 machines bi processeurs quadricoeurs = 226 CPUs physiques<br /> ** LogicalCPUs = processeurs logiques ou vus de l'OS correspond au nombre de cœurs pour <br /> autant que l'hyperthreading ne soit pas activé<br /> Un subcluster de 113 machines bi processeurs quadricoeurs = 904 CPUs logiques<br /> Le nombre de cœurs par CPU physique (par chipset) étant de 4 <br /> ** A noter : Un SubCluster est a priori défini comme un ensemble homogène de workers mais <br /> il est &quot;admis que dans la pratique&quot; cela ne soit pas le cas. Dans ce cas, les sites sont<br /> sensés publier des spécifications moyennes pour certains attributs.<br /> <br /> * Consignes pour les sites / Advices for sites (Juin 2009):<br /> [http://indico.cern.ch/getFile.py/access?sessionId=2&amp;resId=1&amp;materialId=0&amp;confId=63028 Présentation J.Gordon]<br /> <br /> Tentative de synthèse --[[User:Chollet|Chollet]] 17:50, 10 septembre 2009 (CEST)<br /> - Effectuer la mesure de la '''capacité CPU de la machine''' à partir du benchmark HEP-SPEC06<br /> en utilisant le script mis à disposition ci-dessous. '''ATTENTION''' le bench fournit <br /> un score par machine et la publication se fait par cœur<br /> - Publier la '''capacité par cœur''' en HEP-SPEC06 via <br /> ''GlueHostProcessorOtherDescription: Benchmark=&lt;value&gt;-HEP-SPEC06''<br /> Cet attribut est également utilisé pour publier le nombre moyen de cœurs par processeur<br /> (ou chipset)<br /> ''GlueHostProcessorOtherDescription: Cores=&lt;typical number of cores per CPU&gt;,Benchmark=<br /> &lt;value&gt;-HEP-SPEC06'' <br /> - Convertir la capacité CPU par coeur en SI2K en mulipliant par 250<br /> - Mettre à jour l'attribut ''GlueHostBenchmarkSI00'' <br /> En cas de clusteur ou sous-clusteur hétérogène, GlueHostBenchmarkSI00 étant défini comme &quot;Average SpecInt2000 rating per logical CPU&quot; c.a.d par coeur pourvu que l'hyperthreading soit désactivé, vous êtes invités à effectuer à publier une valeur moyenne.<br /> <br /> -----<br /> <br /> === Résultats des benchs effectués par les sites ===<br /> SPEC CPU2000 <br /> Des tests de puissance des CPU ont été réalisés au LAPP (Eric Fede) et à Subatech (Jean-Michel Barbet) avecla suite SPEC CPU2000 suivant la méthodologie recommandée : http://hepix.caspur.it/processors/<br /> Ajout des tests au CPPM (Edith Knoops)<br /> <br /> HEP-SPEC06<br /> Des mesures avec le benchmark suite HEP-SPEC06 sont également disponibles ( fond bleu des tableaux)<br /> <br /> Tests réalisés par Jean-Michel :<br /> <br /> Scientific-Linux V4.3 i386, gcc v3.4.5<br /> <br /> Les autres conditions de test sont disponibles sur demande. A noter que les tests ont été réalisés sur des machines en configuration opérationnelles pour la grille (avec tous les daemons).<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [4]''' <br /> |-<br /> | Dell PE1955 || Woodcrest 5160 3.00GHz || 4 || 8Go || 1409 || 1830 || 2113 || bgcolor=&quot;#0066FF&quot; | 39.48 || bgcolor=&quot;#0066FF&quot; | -<br /> |-<br /> | Dell P21950 || Clovertown E5420 2.50GHz || 8 || 16Go || - || - || - || bgcolor=&quot;#0066FF&quot; | 63.18 || bgcolor=&quot;#0066FF&quot; | 57.63<br /> |-<br /> | IBM || Clovertown 2.33GHz || 8 || 16Go || 979 || 1875 || 1468 || bgcolor=&quot;#0066FF&quot; | 53.12 || bgcolor=&quot;#0066FF&quot; | -<br /> |-<br /> | Dell Optiplex || Pentium4 3.20GHz || 1 || 2Go || 872 || 1128 || 1308 || bgcolor=&quot;#0066FF&quot; | - || bgcolor=&quot;#0066FF&quot; | -<br /> |-<br /> |}<br /> <br /> Dell PowerEdge 1955 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060626-06298.html<br /> <br /> Dell PowerEdge 1950 Clovertown E5420 : <br /> <br /> IBM 3550 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060623-06219.html<br /> <br /> IBM 3350 Clovertown E5345 : http://www.spec.org/osg/cpu2000/results/res2006q4/cpu2000-20061113-07918.html<br /> <br /> ----<br /> <br /> Tests réalisés au LAPP (eric) :<br /> <br /> Scientific-Linux V3.08 i386, gcc v3.4.3<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3]!! CERN SI2K/core corrigé [2] <br /> |-<br /> | HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1367 || 1665 || 2050 <br /> |-<br /> |}<br /> <br /> <br /> Scientific-Linux V4.5 x86_64, gcc v3.4<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés. Un tuning &quot;simple&quot; au niveau du bios donne des disparités dans les résultats des bench qui depassent les 10 %.<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3]!! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits [4] per machin''' !! '''HEP-SPEC06 64bits [4] per machin''' <br /> |-<br /> | HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1485 || 1592 || 2227 || bgcolor=&quot;#0066FF&quot; | 36.58 || bgcolor=&quot;#0066FF&quot; | 34.6 <br /> |-<br /> | HP BL 460c || Clovertown 2.33GHz || 8 || 16Go || 1225 || x || 1837 || bgcolor=&quot;#0066FF&quot; | 56.04 || bgcolor=&quot;#0066FF&quot; | 51.18<br /> |-<br /> | DELL 1950 || Intel 5335 2GHz || 8 || 8Go || 1060 || 1139 || 1590 || bgcolor=&quot;#0066FF&quot; | x || bgcolor=&quot;#0066FF&quot; | x<br /> |-<br /> | HP BL 460c || Harpertown 3GHz || 8 || 16Go || 1620 || 1715 || 2430 || bgcolor=&quot;#0066FF&quot; | 70.83 || bgcolor=&quot;#0066FF&quot; | 63.99<br /> |-<br /> | DELL M600 || Harpertown 2.66GHz || 8 || 32Go || 1481 || 1588 || 2221 || bgcolor=&quot;#0066FF&quot; | x || bgcolor=&quot;#0066FF&quot; | x<br /> |}<br /> <br /> <br /> [1] : Moyenne de 3 exécutions successives avec les optimisations CERN, chaque exécution démarrant un benchmark CPU2000 par CPU core. <br /> <br /> [2] : Correction : La valeur moyenne ci-dessus + 50%. C'est la valeur à publier via le système d'information de la grille.<br /> <br /> [3] : Une exécution unique avec les optimisations FZK à titre indicatif.<br /> <br /> [4] : Benchmark suite HEP SPEC, en suivant les recommandations : https://twiki.cern.ch/twiki/bin/view/FIOgroup//TsiBenchHEPSPEC <br /> ----<br /> <br /> Tests réalisés au CPPM (Edith) :<br /> <br /> Scientific-Linux 4.6 x86_64, gcc v3.4.6<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN32 SI2K/core || CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [4] per machin''' <br /> |-<br /> | HP DL145 || Opteron 250 2.4Ghz || 2 || 4Go || 1149 || 1278 || 972 || 1725 || bgcolor=&quot;#0066FF&quot; | 15.14 <br /> |-<br /> | SUN || Opteron 250 2.4Ghz || 2 || 4Go || 1173 || 1298 || 988 || 1760<br /> |-<br /> | HP DL145G2 || Opteron 275 2.2 Ghz || 4 ||6Go || 981 || 1087 || 857 || 1471 || bgcolor=&quot;#0066FF&quot; | 26.52<br /> |-<br /> | DELL || Opteron 2218 2.6 Ghz || 4 || 8Go || 1199 || 1073 ||1045 || 1798 || bgcolor=&quot;#0066FF&quot; | 32.24<br /> |-<br /> | DELL || Xeon E5420 2.5Ghz || 8 || 16 Go || 1418 ||1528 || x ||2128 || bgcolor=&quot;#0066FF&quot; | 63.12<br /> <br /> |}<br /> <br /> ----<br /> <br /> Tests réalisés à l'IPHC (Jérôme) :<br /> <br /> Scientific-Linux 4.6 x86_64, gcc v3.4.6<br /> <br /> Pour la réalisation de ces tests, seuls les services indispensables étaient activés.<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [1] per machin'''<br /> |-<br /> | DELL M600 || Xeon E5410 2.33Ghz || 8 || 16Go || N/A || N/A || N/A || bgcolor=&quot;#0066FF&quot; | 61.05<br /> |}<br /> <br /> [1] Moyenne des résultats obtenus sur quatre tests.<br /> <br /> <br /> ----<br /> <br /> Tests réalisés au LPC (Jean-Claude) :<br /> <br /> Scientific-Linux 4.6 x86_64, gcc v3.4.6<br /> <br /> Pour la réalisation de ces tests, seuls les services indispensables étaient activés.<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [1] per machin'''<br /> |-<br /> | IBM Blade || Xeon E5345 2.33Ghz || 8 || 16Go || N/A || N/A || N/A || bgcolor=&quot;#0066FF&quot; | 57.41<br /> |}<br /> <br /> [1] Moyenne des résultats obtenus sur trois tests.<br /> <br /> <br /> Scientific-Linux 5.3 x86_64, gcc v4.1.2<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [2] per machin'''<br /> |-<br /> | IBM Blade || Xeon E5430 2.66Ghz || 8 || 12Go || N/A || N/A || N/A || bgcolor=&quot;#0066FF&quot; | 70.64<br /> |}<br /> <br /> [2] Moyenne des résultats obtenus sur quatre tests.<br /> <br /> <br /> ----<br /> <br /> Tests réalisés au LLR (pascale):<br /> Scientific-Linux 5.3 x86_64, gcc v4.1.2<br /> <br /> les machines ont ete installees comme les WN standard de la grille<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! Virtual CPU enabled !! '''HEP-SPEC06 32bits per machin''' !! HEP-SPEC06 64bits [1] per machin''' <br /> |-<br /> | DELL R410 || E 5520 || 16[1] || 24Go || YES || 118.57 || 143.44<br /> |-<br /> | || E 5540 || 16[1] || 24Go || YES || 128.38 || 151.03<br /> |-<br /> | DELL R410 || E 5520 || 8 || 24Go || NO || 96.51 || 113.35<br /> |-<br /> | || E 5540 || 8 || 24Go || NO || 103.41|| 121.47<br /> |-<br /> | DELL R410 || E 5520 || 16[1] || 16Go || YES || Pas fait || Pas fait<br /> |-<br /> | || E 5540 || 16[1] || 16Go || YES || Pas fait || 148.64<br /> |-<br /> | DELL R410 || E 5520 || 8 || 16Go || NO || 94.97 || 109.42<br /> |-<br /> | || E 5540 || 8 || 16Go || NO || 102.41|| 117.5<br /> <br /> <br /> <br /> |}<br /> <br /> <br /> [1] Sur les serveurs il y a réellement 8 cores en tout. A cause de l'activation du &quot;Virtual CPU&quot; , le systeme d'exploitation pense qu'il y a 16 procs : la commande /proc/cpuinfo donne 16 coeurs. D'après les tests il est interessant d'activer le &quot;Virtual CPU&quot;. Mais, combien de jobs faut-il activer en parallele? Et comment allons-nous les déclarer dans la grille?<br /> Voici les résultats des tests avec 8, 10, 12, 14 et 16 jobs lancés en parallèle pour la <br /> configuration suivante : R410, 16g ram, Virtual CPU activé.<br /> <br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Nb jobs !! HEP-SPEC06 64bits [1] per machin''' <br /> |-<br /> | 8 jobs || 115.66 <br /> |-<br /> | 10 jobs || 130.66 <br /> |-<br /> | 12 jobs || 139.29 <br /> |-<br /> | 14 jobs || 144.38 <br /> |-<br /> | 16 jobs || 148.64<br /> <br /> |}<br /> <br /> ----</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4977 2009-02-23T09:56:42Z

<p>Edith Knoops: /* Virtual disks */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> CPPM : <br /> On a essayé 1 virtual disque par baie avec ou sans hot spare<br /> <br /> On est en train d'essayer un seul virtual disk pour les 2 baies ( 24 To) avec RAID6 et 1 hot spare.<br /> C'est pas trop 27 disques dans un raid group ? C'est juste un test..<br /> Finalement on reste dans cette config. 1 seul RAID6 sur les 2 baies et 1 disque hot spare.<br /> <br /> On a fait 4 filesystems ext3 de 6 To (le dernier a 5.8 To).<br /> Le premier a été mis en prod pour atlas ce 22/02/2009.<br /> <br /> === Filesystems ===<br /> <br /> Test avec xfs et ext3:<br /> <br /> parted /dev/sdc mklabel gpt<br /> parted /dev/sdc mkpart primary xfs 0 5720000<br /> parted /dev/sdc mkpart primary ext3 5720001 11440128<br /> <br /> Pour couper en Deux automatiquement:<br /> export X=$((-(`parted /dev/sdc print| grep 'trie'| awk '{ print $6 }'| awk -F '-' '{ print $2 }'| \<br /> awk -F ',' '{ print $1 }'|sed -e 's/\.//g'`)/2))<br /> <br /> mkfs -t xfs -f /dev/sdc1<br /> mkfs -t ext3 /dev/sdc2<br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> Test a l'IRFU<br /> <br /> wget http://ovh.dl.sourceforge.net/sourceforge/lmbench/lmbench-3.0-a5.tgz<br /> tar zxvf lmbench-3.0-a5.tgz<br /> cd lmbench-3.0-a5<br /> make<br /> <br /> <br /> <br /> <br /> || ext3 ||RAID 5 || RAID 6 || RAID 50 ||<br /> <br /> || Ecriture || 324.8031 MB/sec || 380.2232 MB/sec ||404.0307 MB/sec ||<br /> <br /> || Lecture || 244.1971 MB/sec || 129.6664 MB/sec || 179.0090 MB/sec ||<br /> <br /> <br /> <br /> <br /> <br /> || xfs ||RAID 5 || RAID 6 || RAID 50 ||<br /> <br /> || Ecriture ||533.5398 MB/sec || 446.1268 MB/sec || 547.4776 MB/sec ||<br /> <br /> || Lecture || 255.4343 MB/sec || 134.1572 MB/sec ||184.3938 MB/sec ||<br /> <br /> <br /> <br /> <br /> Pour le RAID 5; les tests ont été fait avec une seule baie attachée au serveur, les resultats ne sont donc peut être pas comparables..<br /> <br /> <br /> Exemple de commande:<br /> <br /> <br /> <br /> [root@node35 lmbench-3.0-a5]# bin/x86_64-linux-gnu/lmdd if=internal of=/fs3/out2 bs=1M count=32000 fsync=1<br /> 32000.0000 MB in 58.4499 secs, 547.4776 MB/sec<br /> [root@node35 lmbench-3.0-a5]# bin/x86_64-linux-gnu/lmdd of=internal if=/fs3/out2 bs=1M count=32000 fsync=1<br /> 32000.0000 MB in 173.5417 secs, 184.3938 MB/sec<br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> *Installation par quattor (JM)<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> voir:<br /> https://trac.lal.in2p3.fr/LCGQWG/browser/templates/trunk/sites/example/drivers/dell_openmanage.tpl<br /> <br /> *Pour configurer les RAIDs ca semble possible avec ce genre de CLI (non testé Christine):<br /> # omconfig storage vdisk -?<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> *Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> omconfig storage controller action=clearforeignconfig controller=0<br /> <br /> <br /> <br /> *Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> <br /> .................................................<br /> <br /> *Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver:<br /> modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> wget http://ftp.us.dell.com/SAS-RAID/megaraid_sas-v00.00.03.21-4-R193772.tar.gz<br /> tar zxvf megaraid_sas-v00.00.03.21-4-R193772.tar.gz<br /> -extraire et lire le fichier d'instruction.<br /> <br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> wget http://quattorsrv.lal.in2p3.fr/packages/os/sl460-x86_64/base/SL/RPMS/kernel-largesmp-devel-2.6.9-67.0.4.EL.x86_64.rpm<br /> rpm -ivh kernel-largesmp-devel-2.6.9-67.0.4.EL.x86_64.rpm <br /> -rajouter dkms (se trouve avec openipmi dans le soft de Dell OpenManage Server Administrator Managed Node:<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306)<br /> <br /> -compiler/installer le module:<br /> dkms build -m megaraid_sas -v v00.00.03.21 -k 2.6.9-67.0.4.ELlargesmp<br /> dkms install -m megaraid_sas -v v00.00.03.21 -k 2.6.9-67.0.4.ELlargesmp<br /> <br /> <br /> -si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> modinfo megaraid_sas<br /> dkms status</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4942 2009-02-06T15:49:20Z

<p>Edith Knoops: /* Virtual disks */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> CPPM : <br /> On a essayé 1 virtual disque par baie avec ou sans hot spare<br /> <br /> On est en train d'essayer un seul virtual disk pour les 2 baies ( 24 To) avec RAID6 et 1 hot spare.<br /> C'est pas trop 27 disques dans un raid group ? C'est juste un test..<br /> <br /> === Filesystems ===<br /> <br /> <br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> <br /> <br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> JM:<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> &gt;omconfig storage controller action=clearforeignconfig controller=0<br /> <br /> ........................................................................................................<br /> <br /> Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> <br /> .................................................<br /> <br /> Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver<br /> &gt;modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> -extraire et lire le fichier d'instruction.<br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> &gt;rpm -Uvh kernel-largesmp-devel-2.6.9-78.0.1.EL.x86_64.rpm<br /> -rajouter dkms si besoin<br /> si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> &gt;modinfo megaraid_sas<br /> <br /> ..........................................................</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4941 2009-02-06T15:43:02Z

<p>Edith Knoops: /* Quelques commandes utilisées au CPPM */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> <br /> === Filesystems ===<br /> <br /> <br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> <br /> <br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> JM:<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> &gt;omconfig storage controller action=clearforeignconfig controller=0<br /> <br /> ........................................................................................................<br /> <br /> Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> <br /> .................................................<br /> <br /> Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver<br /> &gt;modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> -extraire et lire le fichier d'instruction.<br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> &gt;rpm -Uvh kernel-largesmp-devel-2.6.9-78.0.1.EL.x86_64.rpm<br /> -rajouter dkms si besoin<br /> si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> &gt;modinfo megaraid_sas<br /> <br /> ..........................................................</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4940 2009-02-06T15:42:35Z

<p>Edith Knoops: /* Quelques commandes utilisées au CPPM */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> <br /> === Filesystems ===<br /> <br /> <br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> <br /> <br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> JM:<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> &gt;omconfig storage controller action=clearforeignconfig controller=0<br /> <br /> ........................................................................................................<br /> <br /> Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> <br /> .................................................<br /> <br /> Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver<br /> &gt;modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> -extraire et lire le fichier d'instruction.<br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> &gt;rpm -Uvh kernel-largesmp-devel-2.6.9-78.0.1.EL.x86_64.rpm<br /> -rajouter dkms si besoin<br /> si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> &gt;modinfo megaraid_sas<br /> <br /> ..........................................................</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4939 2009-02-06T15:42:02Z

<p>Edith Knoops: /* Quelques commandes utilisées au CPPM */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> <br /> === Filesystems ===<br /> <br /> <br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> <br /> <br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> JM:<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> 1. Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> &gt;omconfig storage controller action=clearforeignconfig controller=0<br /> <br /> ........................................................................................................<br /> <br /> Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> <br /> .................................................<br /> <br /> Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver<br /> &gt;modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> -extraire et lire le fichier d'instruction.<br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> &gt;rpm -Uvh kernel-largesmp-devel-2.6.9-78.0.1.EL.x86_64.rpm<br /> -rajouter dkms si besoin<br /> si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> &gt;modinfo megaraid_sas<br /> <br /> ..........................................................</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Infrastructure_Stockage&diff=4938 2009-02-06T15:40:38Z

<p>Edith Knoops: /* Dell Serveur PE2950 et Baies MD1000 */</p> <hr /> <div>Notes techniques concernant la configuration des serveurs de fichiers (RAID, partitions, filesystems)<br /> <br /> == Dell Serveur PE2950 et Baies MD1000 ==<br /> <br /> === Généralités ===<br /> '''Les serveurs sont équipés''' <br /> *Une carte Controleur Raid Perc 6/i pour les disques internes (RAID 1 sur 2 disques)<br /> http://accessories.euro.dell.com/sna/products/Contr%C3%B4leurs/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=403-10298<br /> <br /> *Deux carte controleurs Perc 6/e pour 2 baies externes:<br /> http://accessories.euro.dell.com/sna/products/Mat%C3%A9riel_pour_entreprise/productdetail.aspx?c=fr&amp;l=fr&amp;cs=frdhs1&amp;sku=405-10775#Overview<br /> <br /> '''2) La Baie MD1000''' <br /> <br /> http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/root/fr/product_support_central?~ck=ln&amp;c=fr&amp;l=fr&amp;lnki=0&amp;s=gen&amp;SystemID=PWV_MD1000<br /> <br /> === Choix du RAID ===<br /> <br /> http://www.hardwaresecrets.com/article/314/3<br /> <br /> === Virtual disks ===<br /> <br /> <br /> === Filesystems ===<br /> <br /> <br /> <br /> === Performances ===<br /> http://www.delltechcenter.com/page/PERC6+with+MD1000+and+MD1120+Performance+Analysis+Report<br /> http://www.dell.com/downloads/global/products/pvaul/en/PERC6_PerfWP_WMD1120.pdf<br /> <br /> <br /> <br /> <br /> === Installation de Dell OpenManage ===<br /> http://support.euro.dell.com/support/downloads/download.aspx?c=fr&amp;l=fr&amp;s=gen&amp;releaseid=R198963&amp;SystemID=PWV_MD1000&amp;servicetag=&amp;os=LIN4&amp;osl=fr&amp;deviceid=2331&amp;devlib=0&amp;typecnt=0&amp;vercnt=4&amp;catid=-1&amp;impid=-1&amp;formatcnt=2&amp;libid=36&amp;fileid=275306<br /> <br /> JM:<br /> On peut installer à partir du CD bien sûr mais (si on est sûr que le système est supporté)<br /> il semble qu'on puisse installer la suite Dell Openmanage via Quattor en intégrant les<br /> RPMS dans un repository et ajoutant quelques librairies i386 nécessaires.<br /> <br /> ===Quelques commandes utilisées au CPPM ===<br /> <br /> 1. Se debarasser d'une configuration &quot;foreign&quot; dans le cas ou un disque a ete enleve brutalement et reintroduit<br /> Dans OMSA (OpenManager? Server Administration) installe sur le serveur utilise une commande ligne<br /> <br /> &gt;omconfig storage controller action=clearforeignconfig controller=0<br /> ..............................................................................................................<br /> Mise a jour du firmware de la baie<br /> Aller chercher le fichier d'update chez DELL (support.dell.com)<br /> le fichier est un shell executable de la forme RAIDxxxxxx.BIN<br /> lire la partie instruction(how to) par sh RAIDxxxxxx.BIN --version<br /> puis l'executer en prenant les precautions pour qu'il n'y ait aucune activite sur la baie<br /> sh RAIDxxxxxx.BIN<br /> .................................................<br /> Mise a jour du driver pour le controlleur Megaraid_SAS<br /> - verification de la version du driver<br /> &gt;modinfo megaraid_sas<br /> -recuperation du driver chez Dell sous forme d'une archive .tgz<br /> -extraire et lire le fichier d'instruction.<br /> -Il faut recompiler avec le noyau donc si souces du noyau absentes les rajouter<br /> &gt;rpm -Uvh kernel-largesmp-devel-2.6.9-78.0.1.EL.x86_64.rpm<br /> -rajouter dkms si besoin<br /> si ca se finit sans erreur verifier la version du driver qui doit etre 00.00.03.21<br /> &gt;modinfo megaraid_sas<br /> <br /> ..........................................................</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Atlas:Analysis_ST_2009_Errors&diff=4908 2009-01-30T11:20:33Z

<p>Edith Knoops: /* Comments and Errors follow-up */</p> <hr /> <div>30.01.09<br /> <br /> == Comments and Errors follow-up ==<br /> *http://gangarobot.cern.ch/st/test_124/<br /> *http://gangarobot.cern.ch/st/test_125/<br /> '''Note that ATLAS Production was ON on the FR-Cloud on January 29'''<br /> <br /> * IN2P3-LPC_MCDISK: f(w) - Errors due to the load induced by MC production running at that time. Then ST tests jobs (2 x 50 jobs added)were aborted with Logged Reason by wms &lt;br&gt;<br /> - Got a job held event, reason: Unspecified gridmanager error &lt;br&gt;<br /> - Job got an error while in the CondorG queue.&lt;br&gt;<br /> The submission to the batch system has failed because the '''maximum number of jobs accepted in queue by the site was reached ''' &lt;br&gt;<br /> - queue atlas max_queuable = 200 in the batch system, Attributes 'GlueCEPolicyMaxTotalJobs' on the queue<br /> Jan 29 23:54:46 clrlcgce03 gridinfo: [25608-30993] Job 1233269583:<br /> lcgpbs:internal_ FAILED during submission to batch system lcgpbs<br /> 01/29/2009 23:55:07;0080;PBS_Server;Req;req_reject;Reject reply code=15046(Maximum<br /> number of jobs already in queue), aux=0..<br /> <br /> *IN2P3-CPPM_MCDISK: The same problem has in previous test. Jobs running forever with error .&quot;send2dpm: DP000 - disk pool manager not running on marwn04.in2p3.fr &quot;. This arrive for 13 jobs, all starts running nearly at the same time Thu Jan 29 22:37:53 and run in error around Jan 30 00:21. I have put two of this stdout, stderr there <br /> http://marwww.in2p3.fr/~knoops/752629.marce01.in2p3.fr/<br /> http://marwww.in2p3.fr/~knoops/752631.marce01.in2p3.fr/<br /> <br /> The load of the local DPM server was around 9 at that time.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=Atlas:Analysis_ST_2009_Errors&diff=4907 2009-01-30T11:18:22Z

<p>Edith Knoops: /* Comments and Errors follow-up */</p> <hr /> <div>30.01.09<br /> <br /> == Comments and Errors follow-up ==<br /> *http://gangarobot.cern.ch/st/test_124/<br /> *http://gangarobot.cern.ch/st/test_125/<br /> '''Note that ATLAS Production was ON on the FR-Cloud on January 29'''<br /> <br /> * IN2P3-LPC_MCDISK: f(w) - Errors due to the load induced by MC production running at that time. Then ST tests jobs (2 x 50 jobs added)were aborted with Logged Reason by wms &lt;br&gt;<br /> - Got a job held event, reason: Unspecified gridmanager error &lt;br&gt;<br /> - Job got an error while in the CondorG queue.&lt;br&gt;<br /> The submission to the batch system has failed because the '''maximum number of jobs accepted in queue by the site was reached ''' &lt;br&gt;<br /> - queue atlas max_queuable = 200 in the batch system, Attributes 'GlueCEPolicyMaxTotalJobs' on the queue<br /> Jan 29 23:54:46 clrlcgce03 gridinfo: [25608-30993] Job 1233269583:<br /> lcgpbs:internal_ FAILED during submission to batch system lcgpbs<br /> 01/29/2009 23:55:07;0080;PBS_Server;Req;req_reject;Reject reply code=15046(Maximum<br /> number of jobs already in queue), aux=0..<br /> <br /> *IN2P3-CPPM_MCDISK: The same problem has in previous test. Job running forever with error .&quot;send2dpm: DP000 - disk pool manager not running on marwn04.in2p3.fr &quot;. This arrive for 13 jobs, all starts running nearly at the same time Thu Jan 29 22:37:53 and run in error around Jan 30 00:21. I have put two of this stdout, stderr there <br /> http://marwww.in2p3.fr/~knoops/752629.marce01.in2p3.fr/<br /> http://marwww.in2p3.fr/~knoops/752631.marce01.in2p3.fr/<br /> <br /> The load of the local DPM server was around 9 at that time.</div>

Edith Knoops https://lcg.in2p3.fr/index.php?title=CPU-Benches&diff=4207 2008-09-16T13:19:11Z

<p>Edith Knoops: </p> <hr /> <div>Les sites français peuvent avoir accès à la suite Spec2000 (license disponible pour le projet). <br /> <br /> Des tests de puissance des CPU ont été réalisés au LAPP (Eric Fede) et à Subatech (Jean-Michel Barbet) avec<br /> la suite SPEC CPU2000 suivant la méthodologie recommandée : http://hepix.caspur.it/processors/<br /> Ajout des tests au CPPM (Edith Knoops)<br /> <br /> ----<br /> <br /> Tests réalisés par Jean-Michel :<br /> <br /> Scientific-Linux V4.3 i386, gcc v3.4.5<br /> <br /> Les autres conditions de test sont disponibles sur demande. A noter que les tests ont été réalisés sur des machines en configuration opérationnelles pour la grille (avec tous les daemons).<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN KSI2K/core [1] !! FZK KSI2K/core [3] !! CERN KSI2K/core corrigé [2] <br /> |-<br /> | Dell 5160 || Woodcrest 3.00GHz || 4 || 8Go || 1409 || 1830 || 2113<br /> |-<br /> | IBM || Clovertown 2.33GHz || 8 || 16Go || 979 || 1875 || 1468<br /> |-<br /> | Dell Optiplex || Pentium4 3.20GHz || 1 || 2Go || 872 || 1128 || 1308 <br /> |-<br /> |}<br /> <br /> Dell PowerEdge 1955 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060626-06298.html<br /> <br /> IBM 3550 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060623-06219.html<br /> <br /> IBM 3350 Clovertown E5345 : http://www.spec.org/osg/cpu2000/results/res2006q4/cpu2000-20061113-07918.html<br /> <br /> ----<br /> <br /> Tests réalisés au LAPP (eric) :<br /> <br /> Scientific-Linux V3.08 i386, gcc v3.4.3<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN KSI2K/core [1] !! FZK KSI2K/core [3]!! CERN KSI2K/core corrigé [2] <br /> |-<br /> | HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1367 || 1665 || 2050 <br /> |-<br /> |}<br /> <br /> <br /> Scientific-Linux V4.5 x86_64, gcc v3.4<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés. Un tuning &quot;simple&quot; au niveau du bios donne des disparités dans les résultats des bench qui depassent les 10 %.<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN KSI2K/core [1] !! FZK KSI2K/core [3]!! CERN KSI2K/core corrigé [2]<br /> |-<br /> | HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1485 || 1592 || 2227 <br /> |-<br /> | HP BL 460c || Clovertown 2.33GHz || 8 || 16Go || 1225 || x || 1837 <br /> |-<br /> | DELL 1950 || Intel 5335 2GHz || 8 || 8Go || 1060 || 1139 || 1590<br /> |-<br /> |}<br /> <br /> <br /> <br /> [1] : Moyenne de 3 exécutions successives avec les optimisations CERN, chaque exécution démarrant un benchmark CPU2000 par CPU core. <br /> <br /> [2] : Correction : La valeur moyenne ci-dessus + 50%. C'est la valeur à publier via le système d'information de la grille.<br /> <br /> [3] : Une exécution unique avec les optimisations FZK à titre indicatif.<br /> ----<br /> <br /> Tests réalisés au CPPM (Edith) :<br /> <br /> Scientific-Linux 4.6 x86_64, gcc v3.4.6<br /> <br /> A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align:center&quot; border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |+<br /> |-<br /> ! style=&quot;background:#efefef;&quot; | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN KSI2K/core !! FZK KSI2K/core !! CERN32 KSI2K/core || CERN KSI2K/core corrigé <br /> |-<br /> | HP DL145 || Opteron 250 2.4Ghz || 2 || 4Go || 1149 || 1278 || 972 || 1725 <br /> |-<br /> | SUN || Opteron 250 2.4Ghz || 2 || 4Go || 1173 || 1298 || 988 || 1760<br /> |-<br /> | HP DL145G2 || Opteron 275 2.2 Ghz || 4 ||6Go || 981 || 1087 || 857 || 1471<br /> |-<br /> | DELL || Opteron 2218 2.6 Ghz || 4 || 8Go || 1199 || 1073 ||1045 || 1798<br /> |-<br /> | DELL || Xeon E5420 2.5Ghz || 8 || 16 Go || 1418 ||1528 || x ||2128<br /> <br /> |}</div>

Edith Knoops