Configurer des optimisations supplémentaires pour les grappes Stretched FMW
Bien que tous ne soient pas obligatoires pour cette topologie, ils améliorent les performances et le comportement de certaines fonctionnalités et scénarios.
Configurer les temporisations dans Oracle WebLogic Server (WLS)
Des limites de temporisation sont spécifiées pour les transactions de la base de données, pour les branches de transaction, les appels de méthode Enterprise JavaBean (EJB), les services Web, etc. Les déploiements de grappe étendus d'Oracle Fusion Middleware sont particulièrement sensibles aux paramètres de temporisation, car plusieurs opérations doivent accéder à la base de données à un autre emplacement. Configurez les temporisations de la manière suivante :
- Ils prennent en compte la latence dans le système.
Vous devrez peut-être augmenter les délais d'attente dans ces types de système en raison des latences impliquées. Dans le modèle de cluster étendu, les paramètres de domaine sont partagés pour les deux sites. Par conséquent, il est nécessaire d'utiliser des temporisations qui prennent en compte le scénario le plus défavorable.
- Ils expirent correctement dans la chaîne des appels à travers différentes couches.
Les temporisations doivent être configurées dans les différentes couches du système afin que les niveaux d'intégration appropriés se comportent correctement. Par exemple, si la temporisation de la base de données est réglée à une valeur inférieure à la temporisation WLS globale, un ID transaction peut être "supprimé" de la base de données avant la fin du travail sur les autres branches.
Voici les principaux paramètres de temporisation dans les différentes couches :
- Temporisation de transaction globale
La temporisation de transaction globale Oracle WebLogic Server détermine la durée maximale (en secondes) pendant laquelle une transaction distribuée (une transaction globale) est autorisée à rester active avant d'être automatiquement annulée par Oracle WebLogic Server. Configurez la temporisation de transaction globale dans la console distante WebLogicen sélectionnant JTA (Java Transaction API) dans la section Services de l'arbre de modification et en spécifiant Délai d'attente en secondes.
- Temporisation de transaction XA
La temporisation de transaction XA dans les sources de données XA est utilisée dans Oracle WebLogic Server pour définir une temporisation de branche de transaction pour les sources de données. Par défaut, cette valeur est réglée à 0 (zéro), elle utilise donc la temporisation de transaction globale WebLogic. Toutefois, vous pouvez le définir si vous avez des transactions de longue durée qui dépassent la valeur de temporisation par défaut de la ressource XA. Cette valeur est configurée pour chaque source de données XA, dans l'onglet Transaction.
- Temporisation de verrouillage réparti
La temporisation de verrouillage distribué dans la base de données indique la durée (en secondes) pendant laquelle les transactions distribuées attendent les ressources verrouillées. Vous pouvez modifier le paramètre (
distributed_lock_timeout) avec les énoncésSQL ALTERappropriés.
Définissez la temporisation de verrouillage distribué de la base de données suffisamment longue pour la transaction la plus lente, en tenant compte des retards de réseau entre les sites. Ensuite, réglez les valeurs XA Data Source et Global Transaction Timeouts à des valeurs inférieures à l'aide de la règle suivante :
distributed_lock_timeout >= XA DS Timeout >= Global Transaction TimeoutLes applications peuvent utiliser des paramètres de temporisation supplémentaires. Par exemple, Oracle SOA et BPEL ont les paramètres de temporisation supplémentaires suivants que vous devez prendre en compte :
- syncMaxWaitTime
syncMaxWaitTime est le temps maximal pendant lequel un client synchrone attend une réponse. Ce paramètre définit la durée d'une opération de demande et de réponse avant sa temporisation. Si le processus BPEL n'obtient pas de réponse dans ce délai, l'activité échoue. Pour modifier cette valeur dans Oracle Enterprise Manager Fusion Middleware Control :
- Cliquez avec le bouton droit de la souris sur SOA-infra, puis sélectionnez Administration SOA.
- Sélectionnez Propriétés BPEL.
- Sélectionnez Autres propriétés de configuration BPEL.
- Mettez à jour la valeur syncMaxWaitTime (en secondes).
- Temporisations pour les composants EJB
Lorsque les méthodes BPEL EJB sont impliquées, cela indique la temporisation de transaction en secondes (la valeur par défaut est 300 pour tous les EJB BPEL). Modifiez la temporisation comme suit :
- Dans l'arborescence de surveillance de la console distante WebLogic, sélectionnez Déploiements, puis Gestion d'applications.
- Développez l'application soa_infra, puis développez Configuration et Sous-déploiement.
- Développez le module et sélectionnez le composant EJB BPEL spécifique.
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - Temporisations des clients de services Web
Le client des services Web doit être configuré avec une temporisation suffisamment permissive avec la pire latence. Par exemple, si un appel prend 3 secondes à travers le site 1 mais prend 10 secondes à travers le site 2, la temporisation doit être réglée à au moins 10 secondes pour gérer le site plus lent.
- Temporisations des processus BPEL
Si le processus BPEL utilise des temporisations de réponse (synchrones) et de réception (asynchrones) spécifiques, vous devez les définir en fonction du pire scénario : lorsque l'appel est envoyé au site avec la latence de base de données la plus élevée. Ces paramètres de temporisation sont définis dans le processus BPEL et ne peuvent pas être définis différemment pour chaque site. Pour plus d'informations sur la configuration des événements et des temporisations dans les processus BPEL, reportez-vous au manuel Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. Voir la section Explorer plus.
Configurer la réplication de session
Certaines applications (applications Web, consoles telles que le compositeur Oracle SOA, le compositeur BPM, l'espace de travail BPM, etc.) utilisent intensivement les objets de session HTTP.
L'un des avantages du déploiement étendu du cluster Oracle Fusion Middleware (FMW) est la possibilité de fournir un basculement transparent entre les sites. Toutefois, la réplication de session entre les régions peut entraîner une dégradation des performances dans le système. Oracle recommande de définir deux groupes de réplication différents (un pour chaque région) afin de réduire la réplication sur les deux sites.
Pour configurer des groupes de réplication de session,
- Dans l'arbre de modification de la console distante WebLogic, sélectionnez Environnement, puis Serveurs.
- Sélectionnez Nom du serveur, puis sélectionnez l'onglet Grappe.
- Pour chaque serveur de la région 1, entrez le même nom de groupe de réplication (par exemple, Region1RepGroup).
- Répétez les étapes pour les serveurs de la région 2, en utilisant un nom commun pour tous, mais différent de celui utilisé dans la région 1 (par exemple, Region2RepGroup).
Notez que l'utilisation de groupes de réplication est un meilleur effort pour répliquer l'état uniquement sur des serveurs du même site, mais n'est pas une méthode déterministe. Si un seul serveur est disponible dans un site et que d'autres sont disponibles dans l'autre, la réplication aura lieu dans toutes les régions et se poursuivra pendant cette session même si les serveurs sont de nouveau en ligne dans le même site.
Configurer le redémarrage sur place pour JMS
Les espaces de stockage persistants sont essentiels au bon fonctionnement des serveurs Oracle WebLogic Server (WLS). Avec le redémarrage sur place, si le stockage persistant rencontre une erreur, le service JMS tentera de redémarrer sur le même serveur avant de tenter de migrer vers un autre serveur. Cette méthode est plus rapide que la migration de l'ensemble du service JMS vers un autre serveur et peut souvent résoudre les problèmes rapidement.
Pour configurer le redémarrage sur place des espaces de stockage persistants JMS, le serveur JMS associé et l'espace de stockage persistant doivent être ciblés vers une cible migrable. Cette cible migrable doit utiliser Redémarrer en cas d'échec, qui n'est pas activé par défaut. Pour configurer cette propriété, procédez comme suit :
- Se connecter à la console distante WebLogic
- Dans l'arborescence Modifier, sélectionnez Environnement, puis Cibles migrables.
- Sélectionnez une cible migrable et activez Redémarrer en cas d'échec.
- Sélectionnez Enregistrer et validez les modifications.
Configurer l'adaptateur JMS Oracle FMW SOA Suite
Oracle recommande d'utiliser la syntaxe de la grappe (par exemple : cluster:t3s://cluster_name) pour simplifier la configuration. Cette approche simplifie la configuration en permettant à l'adaptateur d'extraire dynamiquement la liste actuelle des serveurs actifs au sein du cluster, ce qui garantit une extraction efficace du contexte JNDI.
Si le système utilise l'adaptateur JMS de manière intensive et avec des données utiles volumineuses, il est recommandé de configurer l'URL JNDI de manière à inclure uniquement les serveurs locaux de chaque région. Il s'agit de spécifier les serveurs de la région 1 pour les configurations de la région 1 et les serveurs de la région 2 pour les configurations de la région 2. Cette configuration assure l'affinité avec le contexte du site, optimise la performance et réduit la latence.
Configurer l'adaptateur de fichiers SOA Suite Oracle FMW
Ce mécanisme garantit que le même fichier n'est traité que par un serveur à la fois et que deux instances d'adaptateur n'écrivent pas simultanément dans le même fichier.
Dans la topologie de grappe étendue Oracle Fusion Middleware (FMW), chaque site fonctionne de manière indépendante, en traitant les fichiers à l'aide de son propre stockage partagé dédié. Toutefois, par défaut, les deux sites utilisent la même source de données, le même schéma et les mêmes tables pour le verrouillage des fichiers et les mécanismes mutex.
Dans les opérations sortantes, l'utilisation d'une table de base de données partagée est appropriée car une séquence unique est utilisée en tant que mutex pour empêcher les opérations d'écriture simultanées de remplacer des fichiers.
Toutefois, des scénarios "en cours de traitement" peuvent survenir pour les opérations entrantes. Les instances d'adaptateur de fichiers de chaque site peuvent marquer un fichier comme "bloqué". Si le même nom de fichier existe dans les deux sites, ce mécanisme peut bloquer son traitement dans les deux emplacements, mais le fichier ne sera consommé que dans l'un d'entre eux. Pour éviter ces situations, il existe plusieurs alternatives :
- Mettez en oeuvre les conventions d'attribution de nom de fichier propres au site. Utilisez des identificateurs uniques dans des noms de fichier basés sur le site, réduisant ainsi la probabilité de collisions de noms et de blocage ultérieur.
- Configurer des schémas distincts pour chaque région pour le verrouillage de l'adaptateur de fichiers et les tables mutex, afin de garantir que le verrouillage des fichiers et les mécanismes mutex fonctionnent de manière indépendante, empêchant le blocage entre les sites.
- Utilisez une base de données distincte pour le verrouillage de l'adaptateur de fichiers et les tables mutex afin de vous assurer que les métadonnées de traitement de fichiers sont gérées séparément.
Pour configurer l'adaptateur de fichiers de manière à utiliser différentes bases de données ou schémas distincts dans chaque région, vous devez créer le propriétaire et les tables de schéma appropriés et établir une nouvelle source de données. Les serveurs de la région 1 continueront d'utiliser la source de données initiale, seul le plan de déploiement de la région 2 sera modifié pour utiliser la nouvelle source de données.
Les serveurs de la région 1 utiliseront la source de données d'origine tandis que les serveurs de la région 2 utiliseront la nouvelle.
Configurer Oracle Fusion Middleware Oracle SOA Suite In-Memory SOA
Cela améliore les performances et l'évolutivité de ces processus métier, car des opérations de lecture et d'écriture sont effectuées à partir du cache.
Les informations d'état BPEL sont stockées dans le cache Oracle Coherence et extraites de celui-ci. L'état du processus n'est écrit dans la base de données qu'en cas d'erreur ou à intervalles réguliers à l'aide d'un thread en attente d'écriture.
L'architecture SOA en mémoire n'est pas prise en charge dans la topologie de grappe étendue d'Oracle Fusion Middleware, où l'utilisation du cache de cohérence doit être minimale, car elle est très sensible aux retards.
Configurer le réglage du crédit-bail pour la base de données WebLogic
La location de base de données est un mécanisme de base utilisé pour prendre en charge la migration automatique de services, en particulier pour les services singleton clusterisés tels que les serveurs JMS ou le service de récupération de transactions JTA. Il est utilisé pour gérer et coordonner la propriété de ces services singleton sur plusieurs serveurs d'un cluster. Ce mécanisme utilise une base de données comme point central pour suivre et contrôler de manière fiable quel serveur d'un cluster " possède " ou gère un service singleton spécifique à un moment donné. Pour ce faire, vous stockez un enregistrement de version dans la base de données, qui est mis à jour périodiquement (renouvelé) par le serveur propriétaire. Voir Location pour les services migrables dans Administration des grappes pour Oracle WebLogic Server.
La configuration des sources de données GridLink fournie précédemment dans ce guide garantit les reconnections automatiques lorsqu'un basculement de base de données ou une permutation a lieu. Toutefois, tous les serveurs configurés avec une location de base de données ou des espaces de stockage persistants JDBC peuvent s'arrêter lors d'une panne, d'une permutation ou d'un basculement de base de données. Lorsqu'un sous-système critique (comme le service JTA) échoue, le serveur prend l'état FAILED et il est automatiquement redémarré par le gestionnaire de noeuds.
Le temps nécessaire pour passer à l'état FAILED est variable; cela dépend du moment où les vérifications pertinentes sont déclenchées et cela peut se produire pour diverses raisons :
- Si le serveur ne peut pas mettre à jour la table de location après le nombre total de nouvelles tentatives.
- Si le serveur ne peut pas accéder à l'espace de stockage persistant JDBC JTA après plusieurs tentatives et redémarrages sur place.
Une permutation de base de données peut prendre quelques minutes. Le redémarrage automatique des serveurs WLS en raison de la perte d'accès à l'espace de stockage persistant JDBC JTA prend environ 8 à 9 minutes, il n'est donc pas déclenché lors d'une permutation ou d'un basculement type de la base de données. Mais un serveur peut passer à l'état FAILED en raison de la perte d'un bail en moins de 2 minutes avec la configuration de location par défaut. Par conséquent, un redémarrage d'Oracle WebLogic Server peut être déclenché automatiquement lors d'une permutation ou d'un basculement Oracle Data Guard si ce serveur WebLogic utilise la location de base de données.
Il existe deux paramètres pour améliorer la résilience aux pannes de base de données pour les serveurs utilisant le leasing de base de données. Ces paramètres sont database-leasing-basis-connection-retry-count (1 nouvelle tentative par défaut) et database-leasing-basis-connection-retry-delay (1 seconde par défaut). L'augmentation de ces paramètres prolonge le temps avant qu'une erreur de location perdue ne se produise. Cela permet aux serveurs WebLogic de tolérer des pannes de base de données plus longues sans redémarrage automatique; ils se reconnectent simplement à la base de données une fois qu'elle sera de nouveau disponible. Bien que les tentatives de connexion échouent pendant l'arrêt de la base de données, les serveurs WebLogic ne sont pas redémarrés.
Par conséquent, dans une grappe étirée, il est recommandé d'incrémenter les valeurs du nombre de tentatives de connexion de location de base de données et de la temporisation pour rendre le serveur WebLogic plus résilient aux pannes de base de données. Pour modifier ces propriétés, utilisez les commandes WLST. Par exemple :
$ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic','password','t3s://ADMINVHN:9002')
edit()
startEdit()
cd('/Clusters/' + 'My_Cluster')
cmo.setDatabaseLeasingBasisConnectionRetryCount(10)
cmo.setDatabaseLeasingBasisConnectionRetryDelay(10000L)
save()
activate()
disconnect()
exit()Conseil :
Lorsqu'un serveur passe à l'état FAILED, le gestionnaire de noeuds tente deux redémarrages pour le serveur par défaut. Si le serveur ne peut pas démarrer correctement, il est marqué comme FAILED_NOT_RESTARTABLE. Vous pouvez régler le nombre de redémarrages dans l'onglet État du serveur. Utilisez le paramètre Max Restarts Within Interval (Redémarrages max dans l'intervalle) pour définir le nombre de fois où le gestionnaire de noeuds peut redémarrer le serveur dans l'intervalle spécifié dans Restart Interval (Intervalle de redémarrage).Configurer la cohérence
Par exemple, Oracle SOA Suite utilise Oracle Coherence pour propager les déploiements composites et les mises à jour de métadonnées (MDS) dans une grappe.
Oracle Coherence prend en charge la communication multicast et unicast pour la détection des membres de grappe et la messagerie. Unicast est particulièrement adapté aux environnements où le multidiffusion n'est pas disponible ou n'est pas pris en charge, par exemple dans plusieurs centres de données ou régions en nuage. Grâce à la fonctionnalité WKA (Adresses connues), les membres du cluster peuvent détecter et rejoindre le cluster sans recourir à la multidiffusion. Lorsque WKA est configuré, toutes les communications multicast sont désactivées. Par défaut, les produits Oracle Fusion Middleware utilisent le mode Unicast avec une liste WKA prédéfinie pour Coherence.
Oracle Coherence est sensible aux retards lors de la formation des grappes et lors de la réponse aux pulsations des membres des grappes. Cependant, les versions récentes ont amélioré la tolérance aux retards de communication grâce à des fonctionnalités telles que allowable variance. allowable variance définit les variations de synchronisation autorisées dans les communications réseau au sein d'une grappe Coherence. Ce paramètre configurable (maximum-time-variance), qui prend par défaut la valeur 16 ms, définit la latence maximale autorisée pour les communications UDP de temps aller-retour (RTT). Coherence ajuste dynamiquement cette valeur en réponse aux latences ou incohérences observées du réseau, en maintenant la stabilité et la performance de la grappe en tenant compte de plus grands écarts dans la synchronisation attendue. Le message Increasing allowable variance to XX indique un tel ajustement. Voir Éléments de configuration opérationnelle dans Développement d'applications avec Oracle Coherence.
Grâce à cette amélioration d'Oracle Coherence, aucune erreur n'est signalée lors de la formation de la grappe si la latence reste dans les limites recommandées pour la topologie de grappe étendue FMW (<10 ms RTT). Cependant, de longs retards sur les battements de coeur des grappes peuvent entraîner des contentions dans les déploiements et des temps de réaction négatifs aux pannes.
Si vous rencontrez des erreurs dans la formation ou les opérations du cluster Coherence, vous pouvez ajuster les paramètres de temporisation du réseau Coherence suivants :
<multicast-listener><join-timeout-milliseconds>. Bien qu'il ait été conçu à l'origine pour les configurations de multidiffusion, la temporisation de jointure a également un impact en unicast. Il détermine combien de temps le noeud initial prendra pour former un cluster, et ensuite combien de temps chaque noeud va passer à rechercher le cluster avant d'essayer de former le leur (s'ils sont sur la liste WKA). La valeur par défaut est 3000, sur un réseau peu fiable, vous devrez peut-être augmenter cette valeur, pour essayer de trouver une grappe plus longtemps avant d'en démarrer une nouvelle.<packet-publisher><packet-delivery><resend-milliseconds>. L'intervalle de renvoi de paquet spécifie la durée minimale, en millisecondes, pendant laquelle l'éditeur de paquet attend un paquet ACK correspondant avant de renvoyer un paquet. Cela devrait être quelques multiples du RTT, 10x devrait être correct. La valeur par défaut est 200.<packet-publisher><packet-delivery><timeout-milliseconds>. Pour les paquets qui nécessitent une confirmation, spécifie la durée maximale, en millisecondes, pendant laquelle un paquet est renvoyé. Après l'expiration de cette temporisation, Coherence détermine si le destinataire doit être considéré comme étant terminé. La valeur par défaut de 5 minutes doit être suffisante, mais vous pouvez l'augmenter pour éviter les temporisations lors de la connexion au cluster.<packet-publisher><packet-delivery><heartbeat-milliseconds>Ce paramètre est l'intervalle de pulsation pour la détection de décès par anneau TCP. La valeur de pulsation par défaut est de 1 seconde. Vous pouvez augmenter la valeur pour réduire le trafic réseau, mais cela prolonge également la détection des membres défaillants.<tcp-ring-listener><ip-timeout>et<ip-attempts>. Il s'agit de la durée et des tentatives avant de déterminer qu'un ordinateur hébergeant des membres du cluster est devenu inaccessible. La temporisation Ip doit se trouver dans la zone 10x du RTT ou supérieur, avec un minimum de 5s.<cluster-config><tcp-ring-listener><enabled>. Vous pouvez même désactiver la détection de la mort tcp-ring pour réduire le trafic réseau, mais cela rend également la détection des membres défaillants plus longue. Pour désactiver la détection de décès, réglez-la à Faux. Si cette option est désactivée, un membre du cluster utilise l'intervalle de temporisation de renvoi de l'éditeur de paquets pour déterminer qu'un autre membre a cessé de répondre aux paquets UDP (par défaut, réglé à 5 minutes).
Pour modifier les paramètres de configuration par défaut, utilisez un fichier de remplacement Coherence. Créez un fichier nommé custom-coherence-override-<name>.xml et assurez-vous qu'il est cohérent et accessible à tous les serveurs de la grappe. Spécifiez ce fichier dans la propriété java tangosol.coherence.override. Vous pouvez la définir dans la propriété java EXTRA_JAVA_PROPERTIES du fichier setUserOverrides.sh. Par exemple :
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"Exemple de fichier de remplacement de cohérence pour régler les paramètres :
<?xml version='1.0'?>
<!--
This is a custom operational configuration override
-->
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd"
>
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds>5000</join-timeout-milliseconds>
</multicast-listener>
<tcp-ring-listener>
<ip-timeout>20s</ip-timeout>
<ip-attempts>3</ip-attempts>
</tcp-ring-listener>
<packet-publisher>
<packet-delivery>
<resend-milliseconds>200</resend-milliseconds>
<timeout-milliseconds>650000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>
Exemple de fichier de remplacement de cohérence pour régler l'intervalle tcp-ring :
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<heartbeat-milliseconds>5000</heartbeat-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>Exemple de fichier de remplacement de cohérence pour désactiver la détection de décès par anneau TCP :
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<enabled>false</enabled>
</tcp-ring-listener>
</cluster-config>
</coherence>
Configurer la performance du service net
Certaines configurations par défaut du système d'exploitation peuvent ne pas être optimisées, et il devient très important d'ajuster certains paramètres pour rendre le transfert de données plus efficace. Ces ajustements deviennent particulièrement importants en cas de latence élevée entre les clients JDBC et les serveurs. Les serveurs présentant la latence la plus élevée pour l'accès à la base de données doivent guider la configuration des mémoires tampons de réseau et des paramètres Oracle Net Services pour optimiser la performance.
L'une des mesures clés pour déterminer la configuration optimale est le produit de retard de bande passante (BDP). Il représente la quantité maximale de données qui peuvent être en transit dans un réseau à un moment donné. Il est calculé en multipliant la capacité (bande passante) d'une liaison réseau par son temps de retard aller-retour (latence) :
BDP = Bandwidth × Round-Trip Time (RTT)- RTT : Dans OCI, vous pouvez obtenir la RTT moyenne entre les régions à partir de la page Lamence inter-région de la console OCI. Vous pouvez également déterminer le temps aller-retour (RTT) avec des commandes telles que la commande ping d'un hôte à un autre pendant quelques minutes et utiliser les temps de réponse retournés.
- Bande passante : Il n'y a pas de bande passante garantie entre les régions OCI et OCI n'offre pas d'outil de mesure de bande passante OCI spécifique. Pour des mesures précises de la bande passante, vous pouvez utiliser des outils tels que iPerf pour effectuer des tests. La bande passante testée entre Francfort et Amsterdam est d'environ 2 à 2,5 Gbit/s.
Les paramètres de mémoire tampon du connecteur logiciel TCP contrôlent le nombre de paquets envoyés simultanément sur le réseau. Pour obtenir un débit optimal, il est recommandé de régler la taille de la mémoire tampon du socket à au moins le BDP. Dans de nombreux cas, le réglage de la taille du tampon à deux fois le BDP peut améliorer davantage les performances, en particulier dans les réseaux à haute latence. Toutefois, des tampons trop volumineux peuvent entraîner une utilisation accrue de la mémoire. Par conséquent, il est conseillé de régler la taille du tampon dans la plage du BDP à trois fois le BDP :
BDP ≤ Socket Buffer Size ≤ 3 × BDPConfigurer la taille des tampons d'E/S dans la base de données
SEND_BUF_SIZE côté serveur.
Si le serveur de base de données reçoit des demandes volumineuses, définissez également le paramètre RECV_BUF_SIZE. Il est recommandé de les régler au niveau Oracle Net Services dans la base de données plutôt qu'au niveau du système d'exploitation, de sorte que les sessions TCP normales telles que SSH, etc. n'utilisent pas de mémoire supplémentaire.
Pour configurer ces paramètres pour le serveur de base de données, définissez la taille de l'espace tampon dans les fichiers listener.ora ou sqlnet.ora.
-
Dans le fichier
listener.ora, spécifiez les paramètres d'espace tampon pour une adresse de protocole particulière ou pour une description. Voici un exemple des paramètres d'une configuration de module d'écoute Oracle RAC standard dans un système de base de données de base dans Oracle Cloud Infrastructure (OCI) :LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2)))) LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3)))) (…) LISTENER=(DESCRIPTION=(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) -
Si les paramètres sont définis dans
sqlnet.ora, ils s'appliquent globalement à tous les modules d'écoute. Voici un exemple des paramètres du fichiersqlnet.ora:RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
Configurer les tailles de mémoire tampon d'E/S dans les noeuds du niveau intermédiaire
Le système d'exploitation Linux utilise le réglage automatique pour la mémoire tampon de réception et la mémoire tampon de l'expéditeur.
Pour la mémoire tampon de réception, le réglage automatique est déterminé par le paramètre /proc/sys/net/ipv4/tcp_moderate_rcvbuf. Si la valeur du paramètre est 1, le réglage automatique est activé. Avec le réglage automatique, la taille de la mémoire tampon du récepteur (et la taille de la fenêtre TCP) est mise à jour dynamiquement pour chaque connexion, avec une taille de mémoire tampon maximale de 4 Mo.
Pour la mémoire tampon de l'expéditeur, le réglage automatique est également activé par défaut. Bien que le réglage automatique de la mémoire tampon de réception puisse être contrôlé au moyen du paramètre tcp_moderate_rcvbuf, le réglage automatique de la mémoire tampon d'envoi ne comporte pas de basculement direct. Le simple fait de définir des tailles de mémoire tampon fixes désactive le réglage automatique de la mémoire tampon d'envoi.
Ces processus de réglage automatique sont régis par plusieurs paramètres du noyau qui gèrent l'allocation de mémoire pour l'envoi et la réception de données :
- Par taille de mémoire tampon de connexion
L'allocation de mémoire pour chaque connexion TCP est définie par deux paramètres :
/proc/sys/net/ipv4/tcp_rmem, qui spécifie la mémoire réservée pour les mémoires tampons de réception TCP./proc/sys/net/ipv4/tcp_wmem, qui spécifie la mémoire réservée pour les mémoires tampons d'envoi TCP.
Les deux paramètres acceptent trois valeurs :
- Taille minimale du tampon : la plus petite taille de tampon allouée pour un socket TCP.
- Taille de tampon par défaut : taille de tampon initiale affectée à un connecteur logiciel TCP lors de sa création.
- Taille maximale de la mémoire tampon : taille de mémoire tampon la plus importante pouvant être affectée automatiquement à un connecteur logiciel TCP.
Ces paramètres établissent les limites des mécanismes de réglage automatique et permettent d'équilibrer l'utilisation de la mémoire, en particulier pendant les périodes de contraintes de mémoire.
- Tailles de tampon par application
Les applications peuvent demander des tailles de mémoire tampon spécifiques, mais ces demandes sont soumises à des limites définies par les paramètres suivants :
/proc/sys/net/core/rmem_maxest la fenêtre de réception maximale, qui définit la limite supérieure de la taille de mémoire tampon de réception que les applications peuvent demander./proc/sys/net/core/wmem_maxest la fenêtre d'envoi maximale, qui définit la limite supérieure de la taille de la mémoire tampon d'envoi que les applications peuvent demander.
Pour ajuster la taille des tampons d'E/S :
Le réglage automatique TCP reste activé avec des limites dimensionnées pour le produit de retard de bande passante de votre réseau, améliorant ainsi le débit sans surdimensionner l'utilisation de la mémoire système.
Configurer la taille de l'unité de données de session
Oracle Net Services attend que ces unités soient remplies avant de les envoyer sur le réseau. Chacune de ces mémoires tampons est une unité de données de session (SDU). L'ajustement de la taille de l'unité SDU à la quantité de données fournies à Oracle Net Services peut améliorer la performance, l'utilisation du réseau et la consommation de mémoire dans une grappe étendue d'Oracle Fusion Middleware avec des latences supérieures à 5 ms RTT.
La taille SDU peut être réglée de 512 octets à 2 Mo. Dans Oracle Database 23ai, la taille de l'unité SDU par défaut est de 64 Ko (65 536 octets). Les versions antérieures de la base de données ont réglé leur taille d'unité SDU par défaut à 8 Ko.
La taille réelle de SDU utilisée est négociée entre le client et le serveur lors de la connexion et est la plus petite des deux valeurs. La configuration d'une taille d'unité SDU différente de celle par défaut nécessite la configuration de l'unité SDU sur les ordinateurs client et serveur. Oracle recommande de régler l'UDD à la valeur maximale possible (64k).
Les clients et les serveurs négocient l'unité SDU au moment de la connexion; la configuration des deux côtés garantit l'utilisation de l'unité SDU prévue.