Configuration CBF Ingres 2006 sous AIX 5.1
Fermé
Nourzerarga
-
1 déc. 2007 à 17:51
jpzuate Messages postés 56 Date d'inscription dimanche 4 mars 2007 Statut Contributeur Dernière intervention 9 juin 2008 - 9 juin 2008 à 16:20
jpzuate Messages postés 56 Date d'inscription dimanche 4 mars 2007 Statut Contributeur Dernière intervention 9 juin 2008 - 9 juin 2008 à 16:20
A voir également:
- Configuration CBF Ingres 2006 sous AIX 5.1
- Ethernet n'a pas de configuration ip valide - Guide
- Configuration chromecast - Guide
- Panneau de configuration - Guide
- Retablir configuration usine chromecast - Guide
- Connaitre configuration pc - Guide
2 réponses
jpzuate
Messages postés
56
Date d'inscription
dimanche 4 mars 2007
Statut
Contributeur
Dernière intervention
9 juin 2008
51
Modifié par jipicy le 15/09/2010 à 08:59
Modifié par jipicy le 15/09/2010 à 08:59
Bonjour,
"quelle est la bonne configuration Ingres/OS" "pb de performance" "pb de saturation" ... hum hum, c'est un peu vague tout ça.
Il n'y a pas de "bonne" configuration Ingres/OS dans l'absolu, cela dépend tellement de votre activité. D'ailleurs chez l'éditeur on vous rappelle que le "tunning" est un "on going process" (process qui ne s'arrête pas).
En clair, il faut surveiller sans cesse votre SGBD (ce qui reste vrai pour toute sorte de technologie d'ailleurs).
Un problème de saturation c'est quoi au juste ? Peut être qu'il s'agit d'un manque de cache de données (résolution par du paramétrage) ou de transactions bizarrement écrites (manque de COMMIT, dans ce cas il faut toucher le code) ou que les tables sont désorganisées, ou pas assez bien organisées (manque d'index), ou pas de statistiques (optimizedbà ) ou au contraire les statistiques pourrissent les perfs, bref, dire "c'est lent" ou "ça sature" ça donne une idée mais c'est tout.
A noter tout de même quelques "recettes" :
Augmenter :
- qef_qep_mem (taille mémoire allouée pour les QEP)
- qef_sort_mem (taille mémoire réservée aux tris)
- qsf_memory (mémoire dédiée aux QEP compilés)
- dmf_cache_size, dmf_group_size et dmf_group_count. A noter que depuis Ingres R3 il existe au niveau du cache un paramètre "cache_guideline" qui doit être qualibré fonction de la charge
- archiver_interval et cp_interval doivent être à 1
- La taille du log file, son type aussi (sur Unix il peut être "normal" ou "raw device") peut jouer sur les perfs
Bien entendu il y a moult autres paramètres, qui ne peuvent être décrits tels quels. Faites bien attention car une modification qui amène un mieux d'un coté peut dégénérer les perfs de tout le reste ... ces paramètres sont donc à TESTER avec PRUDENCE sur une machine de RECETTE bien avant de mettre ça en production ... et si possible (mais je sais que par définition c'est assez difficile) faire des tests de montée en charge qui représentent bien la réalité.
J'ai trop vu de modifications de paramètres qui, lors de tests unitaires, donnaient un bon résultat, et qui provoquent l'arrêt intempestif du serveur quand il y a trop d'utilisateurs ou de requêtes ...
A noter qu'il y a maintenant tout un tas de webcast fort intéressantes (en anglais uniquement) disponibles ici : https://www.actian.com/data-management/actian-x-hybrid-rdbms/
Pour avoir longtemps travaillé chez l'éditeur je peux vous certifier que les conseils données là dedans sont ceux que les consultants de l'éditeur donnaient jadis. Un énorme effort de documentation a été fait ces dernières années par l'éditeur, et maintenant il fournit aussi un gros effort marketting, rendons lui en grâce ...
Bon courage ...
Jean-Pierre Zuate
"quelle est la bonne configuration Ingres/OS" "pb de performance" "pb de saturation" ... hum hum, c'est un peu vague tout ça.
Il n'y a pas de "bonne" configuration Ingres/OS dans l'absolu, cela dépend tellement de votre activité. D'ailleurs chez l'éditeur on vous rappelle que le "tunning" est un "on going process" (process qui ne s'arrête pas).
En clair, il faut surveiller sans cesse votre SGBD (ce qui reste vrai pour toute sorte de technologie d'ailleurs).
Un problème de saturation c'est quoi au juste ? Peut être qu'il s'agit d'un manque de cache de données (résolution par du paramétrage) ou de transactions bizarrement écrites (manque de COMMIT, dans ce cas il faut toucher le code) ou que les tables sont désorganisées, ou pas assez bien organisées (manque d'index), ou pas de statistiques (optimizedbà ) ou au contraire les statistiques pourrissent les perfs, bref, dire "c'est lent" ou "ça sature" ça donne une idée mais c'est tout.
A noter tout de même quelques "recettes" :
Augmenter :
- qef_qep_mem (taille mémoire allouée pour les QEP)
- qef_sort_mem (taille mémoire réservée aux tris)
- qsf_memory (mémoire dédiée aux QEP compilés)
- dmf_cache_size, dmf_group_size et dmf_group_count. A noter que depuis Ingres R3 il existe au niveau du cache un paramètre "cache_guideline" qui doit être qualibré fonction de la charge
- archiver_interval et cp_interval doivent être à 1
- La taille du log file, son type aussi (sur Unix il peut être "normal" ou "raw device") peut jouer sur les perfs
Bien entendu il y a moult autres paramètres, qui ne peuvent être décrits tels quels. Faites bien attention car une modification qui amène un mieux d'un coté peut dégénérer les perfs de tout le reste ... ces paramètres sont donc à TESTER avec PRUDENCE sur une machine de RECETTE bien avant de mettre ça en production ... et si possible (mais je sais que par définition c'est assez difficile) faire des tests de montée en charge qui représentent bien la réalité.
J'ai trop vu de modifications de paramètres qui, lors de tests unitaires, donnaient un bon résultat, et qui provoquent l'arrêt intempestif du serveur quand il y a trop d'utilisateurs ou de requêtes ...
A noter qu'il y a maintenant tout un tas de webcast fort intéressantes (en anglais uniquement) disponibles ici : https://www.actian.com/data-management/actian-x-hybrid-rdbms/
Pour avoir longtemps travaillé chez l'éditeur je peux vous certifier que les conseils données là dedans sont ceux que les consultants de l'éditeur donnaient jadis. Un énorme effort de documentation a été fait ces dernières années par l'éditeur, et maintenant il fournit aussi un gros effort marketting, rendons lui en grâce ...
Bon courage ...
Jean-Pierre Zuate
