mardi juin 24, 2008

Performance de Solaris versus Microsoft Windows Server 2003 avec SAP

Nous avons publié un benchmark SAP sur la nouvelle lame X8440 équipée des processeurs Opteron Quad Core à 2.3Ghz.

Ce benchmark a été exécuté avec Solaris 10 X64 , MaxDB comme base de données sur l'application SAP ERP 6.0 Unicode.
(Benchmark SD standard SAP: http://www.sap.com/solutions/benchmark/sd2tier.epx)

\* Le résultat est : 17850SAPS, soit 4463SAPS par socket.

La concurrence a aussi éffectué ce méme benchmark sur des serveurs 4 sockets équipés du méme processeur.

Ces benchmarks ont tous été exécuté avec Windows Server 2003, SQLserver 2005 ou DB2 comme base de données sur l'application SAP ERP 6.0 Non-Unicode.

les résultats sont :

\* HP : 17650SAPS, soit 4412SAPS par socket
\* IBM : 17720SAPS soit 4430SAPS par socket
\* Fuji : 16250SAPS soit 4062SAPS par socket

Donc les résultats sont quasi identique pour les 4 constructeurs en puissance cpu mais .....

il y a une différence majeur entre notre benchmark et ceux des concurrents qui est :

\* nous avons exécuter ce benchmark en version Unicode (obligation Solaris 10 x64)
\* la concurrence en version Non-Unicode
\* La version Unicode consomme 15% de plus de ressource CPU que la version Non-Unicode

donc il est possible de conclure que Solaris 10 est au moins 15% plus performant que WS2003 sur des serveurs 4 sockets QC !

Benoit

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.

mercredi avr. 23, 2008

Comment rendre une salle de formation plus confortable

De plus en plus de salles de formation sont équipées d'un poste de travail par étudiant, ces postes de travail sont principalement des PCs utilisés pour afficher l'IHM de l'application via Windows XP.

Le confort de ces salles de formation dépend bien sûr de la décoration et du mobilier mais deux facteurs importants doivent être pris en compte : le bruit et la chaleur !

Pour le bruit , si on considère une salle équipée de 16 postes ( 15 étudiants et 1 professeur) nous arrivons à un niveau de bruit ambiant généré par ces postes à l'équivalent d'une conversation animée soit environ 55db.
Un PC génère environ un bruit de 43db donc pour 16 , une élévation du bruit de 12db(16= 2\^4, 12db = 3db x 4).
C'est à dire que pendant toute la journée , le professeur doit élevé la voix suffisamment pour être compréhensible par ces élèves donc élévation du niveau de sa fatigue. Les élèves doivent se concentrer pour l'entendre au lieu de se concentrer sur la compréhension du discours.

Pour la chaleur, il suffit de faire un bilan des dégagements de puissance de chaque élément :
- un Ecran =~ 35Watts
- un PCs =~ 130Watts (80 en idle, 180 à pleine puissance)
- un Homme =~ 190Watts (75 en sommeil, 120 éveillé, 700 lors de gros travaux)

Donc pour réduire bruit et chaleur dans une salle de formation, il suffit d'éliminer le seul élément non-indispensable dans la salle de cours : le PC (unité central).
L'homme et l'écran doivent y rester :)

Comment faire ?

1er solution : déplacer les PCs dans des salles machines mais il faut prévoir en plus le cout(non négligeable,+centaines d'euro) des déports écran et de la climatisation de la salle machine.

2éme solution : remplacer les PCs par des terminaux légers alimentés par des serveurs en salle machine.

Je vais vous présenter la 2ème solution.

\* Utilisation de client Ultra léger Sunray de chez Sun Microsystems
- Consommation 4W , soit pour une salle de cours réduction de 35% du dégagement de chaleur diminuant ou supprimant la climatisation locale.
- Bruit inaudible car il n'y a ni ventilateur, ni disque, ni aucune autre pièce en mouvement donc, si les élèves sont sages, le professeur peut parler normalement.

\* Utilisation de serveur de flux pour ces clients légers de type CMT ( T2000 ou T5000 de chez Sun Microsystems) qui ont le meilleur rendement performance/consommation du marché(1 serveur =~ 180watts pour 100 Sunray)

\* Utilisation de serveur x64 avec Vmware pour héberger les instances Windows XP des utilisateurs.
- Optimisation du nombre total de cpu (16 cores pour 80 session XP)
- Optimisation de volume de mémoire (64Go pour 80 session XP)
- Optimisation du dégagement de chaleur (1600Watts pour 80 session XP)

\* Utilisation d'une baie de stockage pour héberger les volumes des sessions XP soit environ 1600Watt.

\* Utilisation des logiciels SunRay et VDI de Sun Microsystems pour la gestion de cette configuration et des flux.

Donc le bilan énergétique est le suivant :

5 Salles de cours traditionnelles avec 16 postes PC = 13200Watts
5 Salles de cours avec 16 postes légers plus les serveurs = 7500Watts

Le bilan global est :

- Division par 2 de la consommation électrique
- Réduction, suppression ou non-installation de la climatisation des salles de cours
- Réduction de la fatigue auditive des professeurs et étudiants

Cette solution a été adopté par SAP AG pour ses nouvelles salles de Formation aux Pays Bas.

C'est un exemple avec des salles de formations, mais il faut absolument étudier la solution client ultra léger chaque fois que vous avez des bureaux ouverts contenant plusieurs dizaines de PCs.

A votre disposition.

lundi avr. 07, 2008

Vous avez une très vieille version de SAP R/3 ........

et vous voulez upgrader en ERP 6.0.

Votre version de SAP R/3 utilise un kernel 3.1i, 4.0B ou 4.5B, ces kernel sont supportés jusqu'à Solaris 9.
Le kernel 7.0 de ERP 6 n'est supporté que sur Solaris 9 et 10 .

Votre SAP est installé sur des anciens serveurs ne supportant pas forcément Solaris 9 ou 10.

La seule solution jusqu'à maintenant était de passer par une machine intermédiaire installée en Solaris 9, le probléme est qu'il n'existe plus de serveur à la liste de prix Sun supportant cette version de Solaris !!!!

Heureusement une solution récente existe : les zones Solaris 9 sur un Solaris 10.

C'est nouveau et ça marche !

Vous installez un serveur nouvel génération en Solaris 10 , vous créez une zone Solaris 9 , vous transférez votre SAP original sur cette zone.

Maintenant vous pouvez upgrader vers ERP 6.0 .

Une fois l'upgrade réalisé, il suffit de créer sur ce mème serveur une zone Solaris 10 pour accueillir ERP6.0 et le transférer.

Je n'ai jamais mis en oeuvre ce scénario mais il me parait simple et facilement réalisable.

J'attends un candidat pour le proposer et le dérouler .

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