Performances de la base de données (DB2)
La base de données est généralement l'une des zones potentielles de goulot d'étranglement, ce type d'incident rendant impossible l'exécution et la mise à niveau de WebSphere Commerce. Il est donc crucial que la base de données soit paramétrée pour votre implémentation.
Considérations relatives à l'environnement physique
Ces considérations concernent le mode de répartition des données sur les disques et le mode de gestion de la mémoire pour les bases de données.
Agencement sur le disque
La lecture d'une base de données et la réécriture sur cette base (E-S sur disque) peuvent provoquer un goulot d'étranglement pour toute application accédant à la base de données. Un agencement de base de données adapté peut réduire les risques de goulot d'étranglement. Il n'est pas facile de modifier l'agencement physique d'une base de données une fois qu'il est créé. Il est donc important de prévoir une planification initiale.
La première chose à faire est de vérifier que les journaux de transaction DB2 résident sur leur propre disque physique. Chaque mise à jour effectuée sur la base de données est consignée dans les journaux (en outre d'une mise à jour en mémoire). Il y a donc un grand nombre d'E-S sur disque à l'emplacement où résident les journaux de transactions DB2. Il est conseillé de vérifier que toutes les activités d'écriture/lecture sur disque sont uniquement liées aux journaux de transaction, cela éliminant tout conflit d'E-S avec d'autres processus pouvant accéder au disque.
Pour définir l'emplacement des journaux de transactions DB2, lancez la commande suivante :
db2 update db cfg for dbalias using NEWLOGPATH path
Avant que les journaux ne soient stockés à l'emplacement indiqué, déconnectez toutes les sessions ou désactivez la base de données à l'aide de l'instruction db2 deactivate.
La seconde chose à faire concernant l'agencement du disque est de déterminer comment gérer efficacement les espaces table. Il existe une règle de base en matière de performances concernant la gestion des systèmes de gestion de bases de données (RDBM) : la séparation des données de la table de base de données et des données de l'index de la base de données en les plaçant sur deux disques différents. Cette séparation permet d'améliorer les performances des requêtes car les balayages d'index peuvent s'exécuter en parallèle avec les opérations d'extraction de données étant donné qu'ils sont sur des disques différents.
Dans DB2, les espaces de table de stockage automatiques sont utilisés par défaut. Autrement dit, les types d'espace de table System Managed Storage (SMS) et Database Managed Storage (DMS) sont dépréciés pour les espaces de table permanents définis par l'utilisateur et peuvent être supprimés dans une version ultérieure.
- Vous avez de grandes tables ou de tables qui sont susceptibles de croître rapidement
- Vous ne voulez pas avoir à prendre des décisions régulières sur la façon de gérer la croissance des conteneurs.
- Vous voulez être en mesure de stocker différents types d'objets connexes (par exemple, tables, LOB, index) dans différents espaces de table pour améliorer les performances.
Pour plus d'informations, voir Comparison of automatic storage, SMS, and DMS table spaces.
Mémoire
DB2 associe de la mémoire à la base de données via des objets de pool de mémoire tampon. Un pool de mémoire tampon possède un format de page associé et est lié à un ou plusieurs espaces table. Par conséquent, si des espaces table de formats de page différents sont créés, des pools de mémoire tampon correspondant aux différents formats de page sont nécessaires.
Même si vous pouvez créer plusieurs pools de mémoire tampon possédant le même format de page, il est recommandé de n'avoir qu'un seul pool de mémoire tampon par format de page créé afin d'obtenir une utilisation plus efficace de la mémoire sur le serveur de la base de données.
La question qui se pose est toujours la suivante : quelle quantité de mémoire affecter aux pools de mémoire tampon ? Pour les implémentations DB2 32 bits, il existe une limite de mémoire disponible pour les pools de mémoire tampon, basée sur le système d'exploitation.
Prenons l'exemple d'un serveur de base de données dédié. Allouez une large proportion de la mémoire disponible sur le serveur (environ 75 % à 80 %), mais sans dépasser les limites propres à la plateforme.
Notez que pour les implémentations 64 bits de DB2, les limites sont supérieures. Dans ce cas, le taux de réussite en pool de mémoire tampon doit être contrôlé pour déterminer le paramètre maximal correspondant aux pools de mémoire tampon. Vous pouvez aussi contrôler le taux de réussite pour les implémentations 32 bits en utilisant les instantanés de base de données via la commande suivante :
db2 get snapshot for database on <dbalias>
La sortie générée contient certaines statistiques sur les lectures physiques et logiques du pool de mémoire tampon :
Buffer pool data physical reads = DPR
...
Buffer pool index logical reads = ILR
Buffer pool index physical reads = IPR
Dans cette sortie, DLR, DPR, ILR et IPR ont des valeurs réelles. Le taux de réussite peut être calculé via la formule suivante :
(1 - (( DPR + IPR) / (DLR + ILR))) * 100%
La taille du pool de mémoire tampon peut être modifiée via l'instruction ALTER BUFFERPOOL ou le paramètre BUFFPAGE si cette taille a pour valeur -1.
Autres paramètres d'ajustement et de configuration de base de données
Il existe de nombreux paramètres à prendre en compte dans le domaine des performances. Cette section décrit un certain nombre de paramètres considérés comme importants dans les implémentations HCL Commerce. Pour définir la valeur de ces paramètres, vous devez utiliser la commande suivante :
db2 update db cfg for <dbalias> using <paramname> <paramvalue>
Paramètres liés à la mémoire
Le segment de mémoire de la base de données (DBHEAP) contient des informations de bloc de contrôle pour les objets de base de données (tables, index et pools de mémoire tampon), ainsi que le pool de mémoire à partir duquel sont allouées la taille de la mémoire tampon de journalisation (LOGBUFSZ) et la taille de la cache des catalogues (CATALOGCACHE_SZ). Sa configuration dépend du nombre d'objets dans la base de données et de la taille des deux paramètres mentionnés.
Généralement, on peut utiliser la formule suivante pour estimer la taille du segment de mémoire de la base de données :
DBHEAP=LOGBUFSZ + CATALOGCACHE_SZ + (SUM(# PAGES in each bufferpool) * 3%)
La mémoire tampon de journalisation est allouée à partir du segment de mémoire de la base de données et est utilisée pour mettre en mémoire tampon les écritures en journal des transactions, afin d'améliorer l'efficacité des E-S. La taille par défaut de ce paramètre est de 128 4K pages. Comme point de départ pour LOGBUFSZ dans une implémentation HCL Commerce une valeur de 256.
Paramètres liés aux journaux des transactions
Concernant les valeurs de la taille du journal des transactions (LOGFILSIZ) et le nombre de journaux principaux (LOGPRIMARY) et secondaires (LOGSECOND), il est possible d'appliquer certaines généralisations relatives aux applications OLTP. On rencontre fréquemment un grand nombre de transactions courtes dans les systèmes OLTP. La taille du fichier journal doit donc être plus importante, sinon, les temps de gestion des fichiers journaux sont plus importants que les temps d'écriture dans les journaux de transactions. Dans le cadre des implémentations HCL Commerce, 1000 est un bon point de départ pour la taille du fichier journal.
Les fichiers journaux principaux sont alloués lors de l'activation de la base de données ou lors de la première connexion. Si une transaction longue remplit tous les fichiers journaux principaux, les fichiers journaux secondaires sont alloués en fonction des besoins jusqu'à ce que la limite LOGSECOND soit atteinte. L'allocation d'un fichier journal secondaire affecte fortement les performances et doit être réduite au minimum si elle ne peut être évitée.
Pour déterminer les valeurs adéquates pour ces paramètres, vous devez contrôler la base de données et voir si des fichiers journaux secondaires sont alloués. Si tel est le cas, vous devez augmenter le nombre de fichiers journaux principaux. Vous pouvez effectuer ce contrôle en réalisant un instantané de la base de données et en recherchant les deux lignes suivantes :
Maximum secondary log space used (Bytes) = 0
Secondary logs allocated currently = 0Pour le nombre de fichiers journaux principaux (LOGPRIMARY), un bon point de départ est compris entre 6 et 10.
Paramètres liés aux E-S sur disque
Outre l'agencement du disque physique, plusieurs paramètres d'ajustement peuvent être modifiés pour ajuster les E-S sur disque. Les deux paramètres principaux sont NUM_IOSERVERS et NUM_IOCLEANERS.
NUM_IOSERVERS définit le nombre de processus lancés pour préextraire des données du disque vers les pages du pool de mémoire tampon. Pour qu'il soit possible de maximiser les lectures en parallèle, la valeur de ce paramètre doit être définie par le nombre de disques physiques utilisés par la base de données, afin de permettre une lecture de chaque disque en parallèle.
NUM_IOCLEANERS définit le nombre de processus lancés pour vider les pages de pool de mémoire tampon incorrectes à destination du disque. Pour qu'il soit possible de maximiser l'utilisation des ressources système, la valeur de ce paramètre doit être définie par le nombre d'unités centrales du système.
La fréquence de vidage sur disque des pages de pool de mémoire tampon incorrectes peut être influencée par le paramètre CHNGPGS_THRESH. Sa valeur représente le pourcentage maximal de données incorrectes pouvant être contenues dans une page de pool de mémoire tampon avant que le vidage sur disque ne soit forcé. Concernant les applications OLTP, on recommande une valeur plus faible. Concernant les implémentions HCL Commerce, cette valeur doit être de 40.
Le dernier paramètre à prendre en compte est MAXFILOP. Il représente le nombre maximum de fichiers DB2 pouvant être ouverts à tout moment. Si cette valeur est trop basse, de précieuses ressources processeur sont utilisées simplement pour ouvrir et fermer les fichiers. Ce paramètre doit être contrôlé afin que la valeur définie soit la bonne mais on peut considérer une valeur de départ de 128 comme acceptable. Vous pouvez effectuer ce contrôle en réalisant un instantané de la base de données et en recherchant la ligne suivante :
Database files closed = 0
Si la valeur relevée est supérieure à zéro, la valeur de ce paramètre devra être augmentée.
Paramètres liées aux conflits d'accès
La réduction des conflits d'accès est très importante pour les performances. Il existe plusieurs paramètres qui ont une influence sur les conflits d'accès. La quantité totale de mémoire disponible pour la base de données pour les verrouillages est définie par le paramètre LOCKLIST. Le paramètre MAXLOCKS définit quant à lui la quantité maximale de mémoire disponible pour chaque connexion à la base de données. Il est représenté par un pourcentage de LOCKLIST.
La taille de ces deux paramètres doit être ajustée afin d'éviter les escalades de verrous. Il se produit une escalade de verrous lorsque toute la mémoire disponible pour une connexion est utilisée et que plusieurs verrouillages de ligne d'une table sont échangés pour un simple verrouillage de table. La quantité de mémoire utilisée pour le premier verrou d'un objet est de 72 octets et chaque verrou supplémentaire du même objet est de 36 octets.
On peut arriver à estimer la valeur de départ adéquate pour LOCKLIST en estimant qu'une connexion nécessite environ 512 verrous à tout moment. On peut alors utiliser la formule suivante :
LOCKLIST = (512 locks/conn * 72 bytes/lock * # of database connections) / 4096 bytes/page
La valeur de MAXLOCKS peut être comprise entre 10 et 20 pour commencer. Un contrôle supplémentaire est nécessaire pour affiner ces deux valeurs. Dans la sortie de l'instantané de la base de données, recherchez les lignes suivantes :
Lock list memory in use (Bytes) = 432 Lock escalations = 0 Exclusive lock escalations = 0
Si des escalades de verrous (lock escalations) se produisent (valeur supérieure à 0), augmentez la valeur du paramètre locklist pour réduire les escalades et augmentez la valeur de MAXLOCKS pour augmenter la limite d'utilisation de LOCKLIST par une connexion.
Meilleures pratiques
Voici quelques pratiques recommandées dans le cadre de toute implémentation IBM DB2 UDB.
Réorganisation des données dans les espaces table
Lorsqu'un grand nombre d'insertions, de mises à jour ou de suppressions est effectué sur une table de la base de données, il peut arriver que l'emplacement physique des lignes et des index associés ne soit pas optimal. DB2 comprend un utilitaire permettant de réorganiser les données d'une table :
db2 REORG TABLE <tabschema>.<tabname>;
DB2 comprend également un utilitaire permettant de vérifier si une table ou un index doit être réorganisé. Après vous être connecté à la base de données, lancez la commande suivante :
db2 REORGCHK
Cette commande permet de contrôler toutes les tables de la base de données et de générer un listing, tout d'abord par table puis par index. La présence d'un astérisque (*) dans l'une des trois dernières colonnes implique que la table ou l'index nécessite une réorganisation.
Collecte de statistiques
Chaque instruction SQL soumise à la base de données est analysée et optimisée, puis un plan d'accès aux instructions est créé pour l'exécution. L'optimiseur crée ce plan d'accès à partir des statistiques de table et d'index. Pour que l'optimiseur génère le meilleur plan d'accès, il faut disposer de statistiques à jour. La collecte fréquente de statistiques (ou au moins en cas de modification d'un grand nombre de données) est donc une pratique recommandée.
Pour collecter des statistiques sur une table, lancez la commande suivante :
db2 RUNSTATS ON table <tabschema>.<tabname> WITH DISTRIBUTION AND DETAILED INDEXES ALL; Il faut également collecter des statistiques sur les tables du catalogue.