Discussion :

[elendilm]

Bonjour à tous & toutes.

Je me permet de poster ici en raison d'un petit souci avec un AS400 .

Modele:

I5 - 9405-520
RAID 5 - 4 axes
V5R3
2 AS400 avec une réplication (vision) sont utilisés.

entre 80 et 120 utilisateurs simultanés (avec chacun entre 1 et 4 session 5250 ouvertes)


Nous n'avons pas de besoins énormes au niveau calcul (vue notre activité ) nos besoins sont surtout sensibles au niveau des E/S .

Mon problème arrive ici: j'ai régulièrement des temps d'accès qui peuvent être catastrophiques . Exemple, pendant un de ces "freeze" : le wrkactjob met 30 à 40 secondes à s'afficher (anecdote)

Les utilisateurs sont connectés via un VPN (agences dans toute la france),mais les problèmes rencontrés n'ont pas à priori de rapport direct avec un problème réseau: 2 raisons à ça:
1: quand un problème arrive, je suis également concerné, bien qu'étant en LAN avec l'as400.
2: une analyse de performance effectuée par IBM (j'attends le rapport "officiel" aujourd'hui) m'indique un problème de congestion au niveau des axes.


La proposition faite par notre prestaire s'oriente surtout vers le changement de l'as400 , en mettant une version plus "récente" et performante (donc 2 as à changer . L'as400 n'ayant "que" 4 ans , ca me chagrine un peu !!!!


Bien, ma question (il en faut une!!) est simple:
Est il cohérent d'envisager de ne pas changer les AS400 mais de trouver une solution à ces problèmes en jouant au niveau des axes:

• Passer de RAID 5 à RAID 0+1 pourrait améliorer sensiblement les perf? (je suis conscient des "risques" de perte de données)
• Envisager un SAN avec un RAID 0+1 en FC?
• rajouter des axes? (passage de 4 à 8 disques) ?
  -> Mon éditeur ne me le conseille pas particulièrement, pour le paraphraser:

"Je considère le système comme un triangle équilatéral entre les axes, le processeur et la mémoire: modifier l'un des cotés implique le changement des autres "

Vos avis , conseils seront les bienvenus !

[lva30]

Bonjour.

Juste en passant, je suppose que le taillage de vos pools mémoire à correctement été revu ? Aux heures de pointe, vous n'avez pas de travaux soumis en masse par vos utilisateurs dans un pool batch mal taillé en mémoire donc générant de grandes quantités de transactions IO ?
Je suis aussi d'avis que l'on ne peut envisager une modification d'un serveur Iseries sans prendre en compte tous les paramètres.
L'audit de performance pourra en dire plus. Reste à voir ce qu'elle recommandera...

[elendilm]

Rebonjour,

Merci pour cette réponse rapide, dense et à analyser:

Voila déjà les réponses à une partie des questions posées (et quelques "reflexions" )

Juste pour parler précisément, on emploie le terme de disque ou de bras à la place du terme axe
Et pour les systèmes, il semble que tu ais au moins un System i et non pas un AS/400 du moins pour ton système de prod, c'est certain.

Mea culpa ... Mauvais reflexe sémantique d'un admin unix-like ayant la charge de multiples systèmes (dont 2 I5 !!) ... Promis jl'fraiplus!

Attendons le rapport d'analyse de performances d'IBM

J'ai demandé cette analyse à IBM (ils se goinfrent les goulus !!!), le rapport écrit arrive en début d'après midi (normalement), mais j'ai eu un bref rapport Oral (on évite les mauvais jeux de mots laids pour gens bêtes!! ). J'essaierai de donner les conclusions ici (ce que je peux en fonction des restrictions de confidentialité)


Je vais déjà répondre aux questions "simples" avant de fournir les réponses aux autres questions:

Merci Iseries Navigator

Prod:
Disques : 4326-074 (x4)
Mémoire: 8 cartes mémoire 512 Mo
Modèle exact: 9405-520 1X8951
Controleur unité magnétiques: 5709-001

Backup:
Disques : 4326-078 (x3)
Mémoire: 8 cartes mémoire 256 Mo
Modèle exact: 9405-520 1X8950
Controleur unité magnétiques: 5709-001

Toute la question est de savoir quel est le pic d'I/O de ton serveur.
En fonction de cela on pourra avancer sur le sujet.

A venir sur le rapport d'IBM

- Quel type d'application est-ce ? (Java, SQL, I/O native ...)

Sans certitude, car développé par un éditeur. JAVA: NON sur et certain.

Le contrôleur 5709 peut supporter un maximum de 350 I/O par seconde, les disques 15 Krpm sont prévus pour atteindre un maximum de 100 I/O par seconde. L'augmentation du nombre de bras de changera par grand chose dans ce cas car c'est le contrôleur qui fait goulot d'étranglement.

MERCI !!! Donc à priori, suivant les I/O monitorées, plutôt s'orienter vers le controleur , puis les disques.

Contrairement à ce que l'on croit, le RAID-5 n'est pas la panacé en termes de protection et surtout en termes de performances.

Merci pour les infos sur le RAID et les I5, j'ignorais (comme beaucoup de choses).
Performances et RAID5: ca par contre, je le savais

Rectification,Il n'existe pas de RAID 0+1 sur environnement i5/OS (IBM i).
Les seules options disques sont :
- RAID-0 (pas de protection)
- RAID-5 (protection par parity stripe)
- RAID-6 (protection par double parity stripe)
- i5/OS disk mirroring (officieusement appelé RAID-10+) (protection miroir)
Contrairement à ce que l'on croit, le RAID-5 n'est pas la panacé en termes de protection et surtout en termes de performances.
Le must, c'est le miroir, surtout avec de la HA car à chaque écriture, il n'y a que 2 I/O contre 4 I/O et un calcul pour le RAID-5.
Pour le SAN, ton serveur ne supporte que les ESS800, DS6800, DS8100 et DS8300. Aucune autre baie n'est supportée sur ce modèle.

Ok. et au niveau du rapport cout/performance, que valent les différents SAN?

"Aucune autre baie n'est supportée sur ce modèle."
Ca a le mérite d'être simple, clair et concis !! (et accessoirement, ca m'évitera de perdre du temps à regarder les autres modèles!)

Juste en passant, je suppose que le taillage de vos pools mémoire à correctement été revu ? Aux heures de pointe, vous n'avez pas de travaux soumis en masse par vos utilisateurs dans un pool batch

Bonjour et merci pour la réponse.
Un certain nombre de travaux sont bien sur lancés dans QBATCH (limité à 4 job simultanés). Bien sur, quand un perte de perf. apparait, les JOB sont mis en attente. Mais je n'ai pas constaté de régularité dans les pertes de performances.








Un oubli de ma part lors du 1er post:

N'ayant pas d'autre solution (je suis preneur d'ailleurs pour des propositions - même commerciales . Je suis déjà en relation pour ça avec traders, mais bon, rajouter une réplication hétérogène à une réplication native ne me parait pas des plus logiques!! )
Donc:
j'extrais régulièrement des données depuis un serveur linux via une connexion ODBC. Ca a été la 1ere piste de recherche des problèmes bien évidemment: les SQL ont été modifiés et optimisés pour attaquer sur les bon logiques plutôt que physique et j'ai secoué vigoureusement le cocotier pour optimiser ces programmes, éviter les grosses jointures , éviter les clauses violentes et favoriser l'extraction logiques des données et analyse par le programme [...], et l'analyse de perf a été faite en modifiant les cron de lancement de ces programmes (lancements moins réguliers) . Ces programmes sont essentiels pour notre activité, afin d'alimenter nos bases de données à destination de nos clients. Je ne peux donc me passer de ce lien ODBC, à moins de le remplacer par une autre solution.

[jump400]

Bonjour,

les SQL ont été modifiés et optimisés pour attaquer sur les bon logiques plutôt que physique

C'est le piège dans lequel tombe la majorité des développeurs System i !
Il ne faut surtout pas faire ça, il faut mettre les Physiques (tables) dans la clause FROM pour bénéficier de perfs optimales.
En effet, il y a 2 moteurs de requêtes sur system i :
- le CQE (Classical Query Engine) : "ancêtre" datant des débuts de cette plateforme, bien av ant que SQL ne soit supporté. SQL a été logiquement greffé dessus mais il n'est pas optimisé pour SQL.
- le SQE (SQL Query Engine) : moteur de requête créé de toute pièce pour SQL et bien plus performant que le CQE.

Grosso modo, en indiquant des Logiques dans le FROM, la requête est traitée par le CQE , alors qu'en indiquant les tables, elle est traitée par le SQE.

Charge à l'optimiseur SQL de trouver les bons index... s'ils existent. Il y a des outils (Visual explain notament, mais aussi simplement STRDBG) qui permettent de connaitre les index nécessaire pour améliorer les perfs d'une requête.
De même, un Logique (LF créé par des DDS) est moins performant qu'un vrai index (CREATE INDEX) pour une utilisation en tant qu'index par SQL. Cela vient d'une histoire de taille de page d'index différente.


Quelques interrogations de ma part ...

entre 80 et 120 utilisateurs simultanés (avec chacun entre 1 et 4 session 5250 ouvertes)

Mémoire: 8 cartes mémoire 512 Mo

4 Go de Ram pour autant d'utilisateurs simultanés, est-ce bien suffisant ??? (Mais si cela n'a pas choqué Fabrice, grand spécialiste de la question, ce ne doit pas être important. )

Il y a d'autres éléments qui sont importants : quel est le taux d'occupation des disques ??? Au delà de 80 % les perfs peuvent se dégrader très vite.

Quel est le nombre de travaux connus du système ? (quelques screenshots de DSPJOBTBL, WRKDSKSTS et DSPSYSSTS ASTLVL(*INTERMED) pourraient nous éclaircir)
Il faut bien sur attendre le rapport IBM pour y voir + clair sur ces points.

[K2R400]

Et il faut surtout mettre les receveurs dans un ASP séparé (disques séparés), la plupart des problèmes I/O disks sont dus aux receveurs stockés dans le même ASP que les données.

[Mercure]

J'appuie à 100 % la remarque de jump400 en ce qui concerne l'utilisation des tables ou fichiers dans les requêtes SQL. Ne jamais en effet mettre un LF sur une requête mais toujours le PF ou la table.
C'est dommage que vous ne puissiez pas upgrader en V5R4 pour pouvoir profiter de l'Index Advisor de iSeries Navigator qui vous indiquerait les index et autres MTI que SQL a été amené à créer lors de l'exécution de vos applications. A défaut, lancez un STRDBG UPDPROD(*YES) tel quel dans le programme de démarrage de chacune de vos applications puis analysez la log de chaque passage. Elle vous indiquera les index créés par SQL au cours du traitement. A partir de cette info, vous devrez créer les index indiqués avec CREATE INDEX (plutôt que CRTLF) et éviterez ainsi que SQL ait à le faire à chaque traitement, d'où un gain appréciable en matière de perf.

[elendilm]

Bonjour,

Désolé de ne pas avoir répondu plus tôt (vous savez surement ce que c'est .... 4 jours avant les vacances, 2 projets en cours .... )

Bien:

Vu le nombre de commentaire (pour lesquels je vous remercie):

Le rapport d'IBM n'est toujours pas arrivé (problèmes personnels de l'ingénieure en charge ... bref )

Envoyé par K2R400
Et il faut surtout mettre les receveurs dans un ASP séparé (disques séparés), la plupart des problèmes I/O disks sont dus aux receveurs stockés dans le même ASP que les données.

j'ai posé la question à l'inge IBM qui m'a répondu que c'était un problème effectivement, mais uniquement avec les anciens systèmes.. Alors soit j'ai rien compris, soit elle a rien compris (mode deconne OFF)

Les 1ers élements du rapport (toujours oral )
Problème d'entrée sortie , en grande partie du aux nombreuses requetes ODBC : problème: ces requetes font des extraction de données pour nos clients, je ne peux pas les supprimer
Problème interactif : Le rapport indique également des dépassements ponctuels de la capacité interactive.
actuellement, 80 à 120 utilisateurs, et un des projets en cours implique l'ajout de pistolets à flasher ( ~ 40 à 50 , qui chacun ouvre une session sur l'AS) , donc le "problème ponctuel" interactif devient une catastrophe interactive ....


Principal source d'ennui: le I520 , comme le dis Fabrice: "on ne peux pas réaliser de MES vers un autre système."

Bilan actuel:
Je ne peux pas me permettre, malheureseument, de ne pas envisager de changer compléter mes I5 ....

Au vu de ce que vous me dites, on pourrait envisager de rajouter un controleur disque et multiplier le nombre de bras (passer d'un RAID5 4 disques à 1 RAID5 8 disques , tout en gonflant les capacités du controleur, ce qui pourrait résoudre mon problème d'IO , mais pas l'interactif.


Au niveau coûts:

On exclu les ESS800 (trop vieilles), et les DS8x00 (trop chères), la seule baie envisageable sur ton serveur est la DS6800, mais à un cout de plusieurs dizaine de K€

Autant dans ce cas là envisager l'achat de 2 I5, j'en ai parlé à la SSII, on commence à discuter d'un système 6000 CPW pour supporter la montée en charge .

[elendilm]

Bonjour,

Désolé de ne pas avoir répondu plus tôt (vous savez surement ce que c'est .... 4 jours avant les vacances, 2 projets en cours .... )

Bien:

Vu le nombre de commentaire (pour lesquels je vous remercie):

Le rapport d'IBM n'est toujours pas arrivé (problèmes personnels de l'ingénieure en charge ... bref )



j'ai posé la question à l'inge IBM qui m'a répondu que c'était un problème effectivement, mais uniquement avec les anciens systèmes.. Alors soit j'ai rien compris, soit elle a rien compris (mode deconne OFF)

Les 1ers élements du rapport (toujours oral )
Problème d'entrée sortie , en grande partie du aux nombreuses requetes ODBC : problème: ces requetes font des extraction de données pour nos clients, je ne peux pas les supprimer
Problème interactif : Le rapport indique également des dépassements ponctuels de la capacité interactive.
actuellement, 80 à 120 utilisateurs, et un des projets en cours implique l'ajout de pistolets à flasher ( ~ 40 à 50 , qui chacun ouvre une session sur l'AS) , donc le "problème ponctuel" interactif devient une catastrophe interactive ....


Principal source d'ennui: le I520 , comme le dis Fabrice: "on ne peux pas réaliser de MES vers un autre système."

Bilan actuel:
Je ne peux pas me permettre, malheureseument, de ne pas envisager de changer compléter mes I5 ....

Au vu de ce que vous me dites, on pourrait envisager de rajouter un controleur disque et multiplier le nombre de bras (passer d'un RAID5 4 disques à 1 RAID5 8 disques , tout en gonflant les capacités du controleur, ce qui pourrait résoudre mon problème d'IO , mais pas l'interactif.


Au niveau coûts:


Autant dans ce cas là envisager l'achat de 2 I5, j'en ai parlé à la SSII, on commence à discuter d'un système 6000 CPW pour supporter la montée en charge .

Edit :

8h53 - 30 pages de rapport arrivés par mail. Je potasse et vous tiens au courant.

[elendilm]

A.M.B ?

oui

La capacité interactive de ta prod est limitée à 6% de la puissance de ta capacité de traitement, qui elle même est peu élevée (43% de la capacité du processeur car je rappelle que ce modèle est bridé).

J'ai vu. et effectivement, on est (lors des horaires de travail) en quasi permanence au voisinage des 6% ..

Tes systèmes étant peu évolutifs et peu performants, il est clair qu'une évolution vers des serveurs récents semble une solution pérenne pour l'avenir au vu de tes besoins, mais attention à ne pas commettre une erreur de sizing.
Car personnellement, lorsque je vois que tu as de la réplication sur tes environnements (c'est très bien), et que je vois les systèmes configurés, je me pose des questions quant aux conseils qui t'ont initialement été prodigués.

Pas à moi à l'époque (même si j'aurai fait exactement la même erreur .. j'était numéro 2 à l'époque) .. oui , ne pas prendre trop gros, mais pas trop petit non plus. Mais c'est vrai que les conseils auraient du prendre en compte une marge conséquente d'erreur et d'évolutivité.

Réflechissons maintenant à un système correct ...... même s'il aurait pu être calibré dès le bon moment...

L'interactif n'est plus un problème sur les serveurs d'entrée de gamme (90% des ventes), il n'y a plus de bridage de ce côté, la facturation se faisant désormais sur le nombre d'utilisateurs qui peuvent potentiellement se connecter.

C'est con pour nous ...... D'avoir un des modèles bridés ..

Vers quel système veulent t-ils te migrer ?

Il n'existe plus de système 6000 CPW commercialisé. Le dernier était le System i 525, mais les POWER5+ ne sont plus au catalogue.

Les seuls systèmes commercialisés sont les POWER6 et les POWER6+.
Or le monocoeur POWER6 fait 4300 CPW et 8300 en bicoeur alors qu'en POWER6+ on est à environ 5000 CPW en monocoeur et à 9500 en bicoeur.
Cela concerne les Power 520.
Les puissances des lames JSxx ne correspond également pas au 6000 CPW dont tu parles.

J'espère qu'ils ne t'orientent pas vers un 525 POWER5+ d'occasion ?

on verra.... J'attends la propal , mais je garde maintenant un SACRE ESPRIT CRITIQUE !

Qu'entends tu par là ?
Tu veux parler de Quick EDD par hasard ?

[/QUOTE]
voui .

[hmimo]

quel est le lien entre le choix d'une ou deux machines et EDD ?