mardi avr. 29, 2008

SAP et T5000 : Retour d'expérience 3

Juste une information rapide sur un test sur T5220 8cores 1.2Ghz:

- Lancement du batch SGEN en mode non-parallélisé

- Durée du batch 15% plus long sur sur un V440 équipé d'un USIII à 1Ghz

Sur les taches monothreads de SAP ( transactions ABAP, Batch) le T2 à 1.2Ghz délivre les mêmes performances qu'un USIII à 850Mhz.

Conclusion :

Il possible de remplacer les serveurs Sun équipés de processeurs Sparc à 900Mhz et 1050Mhz par des serveurs T5000 équipé de processeurs T2 à 1.4Ghz pour les applications SAP. Les performances obtenues seront quasi identiques.

Benoit

Note : remerciement au client m'ayant remonté les résultats de ce test.

mardi avr. 01, 2008

La genèse des processeurs CMT : historique des processeurs

Je vais essayer, en déroulant l'histoire des processeurs, de justifier l'évolution vers le CMT.

1) les premiers processeurs exécutaient des instructions complexes (CISC) qui demandaient chacune plusieurs cycle d'horloge. Cela venait directement des logiques à portes NAND/OR/... et des logiques à relais.
Les compilateurs étaient très simples à programmer.

2) Première évolution : la technologie des compilateurs évoluant très rapidement, les processeurs RISC ont été développé avec pour objectif de d'éxécuter des instructions simples en un seul cycle d'horloge. Le design des processeurs devenait plus simple donc il était possible d'augmenter la fréquence d'horloge de façon importante.

3) Deuxième évolution : la fréquence des processeurs augmentant, le temps d'accés à l a mémoire RAM devient un frein à l'éxécution des instructions. Le processeur attend (NOP) les instructions et données. Pour résoudre ce probléme, un étage de mémoire cache a été ajouté, plus rapide, plus chére, plus petite.

4) Troisième évolution : Le prix de la mémoire cache diminuant, ses performances augmentant et son intégration sur le méme silicium que la CPU devenant possible, il est possible d'éxécuter plusieurs instructions en paralléle au sein d'un méme processeur. C'est l'apparition des processeurs Superscalaire : Un pipeline multiétage pour préparer les instructions et les données , plusieurs unité de traitement (x ALU, FPU) pour les exécuter.

5) Quatrième évolution : les instructions sont éxecutées dans l'ordre de présence dans le pipeline, souvent elles sont interdépendantes et s'attendent entre elles avant éxecution.
L'implémentation du principe de "Out of Order" permet de faire les calculs dans l'ordre où ils se présentent et suivant les dépendances d'exploiter le résultat ou de refaire le calcul.
L'implémentation de cette fonctionalité est complexe mais permet un réel gain de performance.

6) Cinquiéme évolution : les technos de gravure du silicium évoluant, il est possible sur une surface identique d'implanter plusieurs CPU partageant le méme cache (ou pas). De plus, la fréquence des processeurs peut augmenter significativement.

7) Sixième évolution : avec la montée en fréquence des processeurs, la mémoire cache devient le frein à l'alimentation en instruction et données des CPU.
Pour résoudre ce probléme, l'idée est de mettre plusieurs pipelines en paralléle pour alimenter les unitées de traitement. Chaque pipeline est vu comme un processeur virtuel. Naissance de Chip MultiThreading CPU.

L'implémentation du CMT peut se faire de plusieurs façons, la limitation est de nouveau les technologies de gravure du silicium :
- 2 Threads par unité de traitement en conservant celles ci complexes et performantes ( Ex: Sparc64VII, Power 6)
- 4 Treads par unité de traitement mais en utilisant des unités de traitement plus simple ( non superscalaire) moins performantes mais en multipliant leur nombre sur un méme silicium ( Ex: UltraSparcT1, T2)

Globalement la puissance des CMT développés suivant la deuxiéme régle est plus élevée que suivant la première. Mais leur performance unitaire (mono-thread) est inférieur.

8) Septiéme évolution : gràce à l'évolution des techno de gravures, il sera possible dans un futur proche de trouver l'équilibre entre l'alimentation en instructions et données via des multiples pipelines et la compléxité des unités de traitement permettant un traitement rapide.

9) Le Futur : remplacement de "l'electricité" par "la lumière" .............

En conclusion, il est toujours possible de trouver une nouvelle technologie ou une nouvelle impémentation des fonctions des processeurs pour augmenter leur performance.
Mais, à mon avis, la véritable évolution responsable à venir, c'est de pouvoir implémenter non plus un processeur mais tout un "ordinateur" sur un seul silicium avec des performances de nos serveurs actuels afin de répondre au seul véritable enjeu :

Réduire la consomation électrique !!!!

Benoit

mardi janv. 15, 2008

SAP et T2000 : Retour d'expérience 2

Un client français a remplacé ses V440 à 1280Mhz par des T2000 1.2Ghz pour les applications serveurs et par des T2000 1Ghz pour le cluster DB/CI pour son application SAP SRM 5.0.

La perte de performance(allongement du temps de réponse) constatée sur les transactions est compris entre 23 et 50% en Production.

La majorité des transactions qu'il utilise sont légéres (<500ms) et très peu de batchs lourds sont exécutés.

L'accés à son application SRM se faisant à travers le WEB en HTTP, c'est le temps "réseau" qui est le plus contributeur au temps de réponse global donc les utilisateurs n'ont pas remonté d'alerte de performance sauf les rares utilisateurs de transactions lourdes.

L'utilisation de son SRM n'est pas régulière dans le temps, il a constaté que pendant les périodes d'utilisation intensives les temps de réponses restaient quasi-constants contrairement à son anciennes configurations.
Donc les T2000 délivrent bien les SAPS constatés en benchmark et ils sont capables d'absorber des pics d'activités sans dégradation.

Un test de montée de version de SRM (2.0 --> 5.0) a été fait en paralléle sur un V880 ( 4 CPU USIII à 900Mhz) et un T2000 à 1Ghz. La durée a été supérieur de 50% sur le T2000 ( 15heures versus 10heures ).

En conclusion , il est possible d'utiliser des Tx000 pour des applications SAP à condition que :
- l'accés aux transactions se fassent à travers le WEB (HTTP)
- peu ou pas de batch lourd soit exécuté
dans ces conditions les Tx000 permettent de supporter une charge importante d'utilisateurs simultanés correspondant bien à leurs puissances SAPS élevées (5000 pour un T2000, 10000 pour un T5000).

Le client a donc décidé de remplacer ces V440 par des T2000 et T5000 car cela lui permettait de réduire le nombre de serveur d'application.
(Le V440 délivre environ 1500SAPS)

Une utilisation type des Tx000 est le service WEB ESS/MSS de l'application SAP RH.

mardi déc. 11, 2007

SAP et T2000 : Retour d'expérience 1

J'ai eu l'occasion de charger l'application XI de SAP en version netweaver 2004s
sur un serveur X4200(2 x opt DC 2.4Ghz, 16Go de mémoire) et sur un serveur T2000 (1 x T1 8cores 1.2Ghz, 16Go de mémoire).

Les 2 serveurs étaient équipés de 4 disques internes de 73Go, 3 étaient configurés
en Raidz (ZFS) pour accueillir une zone et et l'installation de XI.

Aucune optimisation n'a été faite ni sur le T2000(garbage collector) ni sur le X4200.
Le chargement de la base Oracle a été parallèlisé( 3 process sur le X4200, 8 process sur le T2000)

Résultat :

- Temps de chargement de la base : 45minutes sur les 2 serveurs
- Temps de chargement global : 5 heures sur le X4200, 20 heures sur le T2000

Le T2000 passe énormément de temps pour le chargement de toute la partie Java de XI avec très peu d'activité CPU.

Performances transationnelles :

Ces systémes XI ont été paramétré par SAP pour un POC chez un client.
Un scénario comprenait :
- Entrée dans R/3 d'une requéte d'accés à des données externes
- Transfert vers l'application externe via XI
- Retour de l'information vers R/3 via XI

La durée de la transation totale unitaire a été de 2,5secondes sur le X4200 et de 10secondes sur le T2000.
On retrouve le rapport de temps du chargement, x4, et l'estimation de la performance monothread du T2000 équivalente à un processeur 600Mhz (2.4Ghz/4).

Montée en charge :

Seul le T2000 a été testé dans des conditions de pleine charge avec ce paramétrage XI.
Durant la montée en charge, le temps de réponse est resté quasi constant jusqu'à 100% de cpu.

Conclusion sur ce test :

Le T2000 a bien des performances monothread équivalentes à un processeur à 600Mhz.
SAP, grace à son architecture multiprocess, exploite bien tous les threads du T2000.
Dans le cadre de XI, le T2000 est parfaitement adapté pour gérer des requètes asynchrone entre 2 systémes.

About

Benoit Boitier

Search

Categories
Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today