Configura ottimizzazioni aggiuntive per cluster estesi FMW
Sebbene non tutti siano obbligatori per questa topologia, migliorano le prestazioni e il comportamento di determinate funzioni e scenari.
Configurare i timeout in Oracle WebLogic Server (WLS)
Sono stati specificati limiti di timeout per le transazioni nel database, per le filiali delle transazioni, i richiami del metodo Enterprise JavaBean (EJB), i servizi Web e così via. Le distribuzioni cluster estese di Oracle Fusion Middleware sono particolarmente sensibili alle impostazioni di timeout perché più operazioni devono accedere al database in una posizione diversa. Configurare i timeout come indicato di seguito.
- Esse tengono conto della latenza nel sistema.
Potrebbe essere necessario aumentare i timeout in questi tipi di sistemi a causa delle latenze coinvolte. Nel modello cluster esteso, le impostazioni del dominio vengono condivise per entrambi i siti; pertanto, è necessario utilizzare i timeout che tengono conto dello scenario peggiore.
- Scadono correttamente nella catena di invocazioni su diversi livelli.
I timeout devono essere configurati nei diversi livelli del sistema in modo che i livelli di abbinamento appropriati si comportino correttamente. Ad esempio, se il timeout del database è impostato su un valore inferiore al timeout WLS globale, è possibile che un ID transazione venga "rimosso" dal database prima del completamento del lavoro su altri rami.
Questi sono i principali parametri di timeout in diversi livelli:
- Timeout della transazione globale
Il timeout della transazione globale di Oracle WebLogic Server determina la durata massima (in secondi) durante la quale una transazione distribuita (una transazione globale) può rimanere attiva prima del rollback automatico da parte di Oracle WebLogic Server. Configurare il timeout della transazione globale nella WebLogic Remote Console selezionando JTA (Java Transaction API) nella sezione Servizi della struttura di modifica e specificando Secondi timeout.
- Timeout per transazioni XA
Il timeout della transazione XA nelle origini dati XA viene utilizzato in Oracle WebLogic Server per impostare un timeout della diramazione della transazione per le origini dati. Per impostazione predefinita, questo valore è impostato su 0 (zero) , quindi utilizza il timeout della transazione globale WebLogic. In caso di transazioni a esecuzione prolungata che superano l'impostazione predefinita per la risorsa XA, è tuttavia possibile impostare il timeout. Questo valore è configurato per ogni origine dati XA, nella scheda Transazione.
- Timeout blocco distribuito
Il timeout del lock distribuito nel database specifica il periodo di tempo (in secondi) durante il quale le transazioni distribuite devono attendere le risorse bloccate. È possibile modificare il parametro (
distributed_lock_timeout) con le istruzioniSQL ALTERappropriate.
Imposta il timeout di blocco distribuito del database abbastanza a lungo per la transazione più lenta, considerando eventuali ritardi di rete tra i siti. Successivamente, impostare l'origine dati XA e i timeout delle transazioni globali su valori inferiori utilizzando la regola seguente:
distributed_lock_timeout >= XA DS Timeout >= Global Transaction TimeoutLe applicazioni possono utilizzare parametri di timeout aggiuntivi. Ad esempio, Oracle SOA e BPEL dispongono dei parametri di timeout aggiuntivi riportati di seguito.
- syncMaxWaitTime
Il valore syncMaxWaitTime indica il tempo massimo durante il quale un client sincrono attende una risposta. Questa impostazione definisce la durata di un'operazione di richiesta e risposta prima del timeout. Se il processo BPEL non riceve una risposta entro questo periodo di tempo, l'attività non riesce. Per modificare questo valore in Oracle Enterprise Manager Fusion Middleware Control, procedere come segue.
- Fare clic con il pulsante destro del mouse su SOA-infra, quindi selezionare Amministrazione SOA.
- Selezionare Proprietà BPEL.
- Selezionare Altre proprietà di configurazione BPEL.
- Aggiornare il valore syncMaxWaitTime (in secondi).
- Timeout per EJB
Quando vengono coinvolti i metodi EJB BPEL, questo specifica il timeout della transazione in secondi (il valore predefinito è 300 per tutti gli EJB BPEL). Modificare il timeout come indicato di seguito.
- Nella struttura di monitoraggio di WebLogic Remote Console selezionare Distribuzioni, quindi selezionare Gestione applicazioni.
- Espandere l'applicazione soa_infra, quindi espandere Configurazione e Distribuzione secondaria.
- Espandere il modulo e selezionare l'EJB BPEL specifico.
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - Timeout client Web Services
Il client dei servizi Web deve essere configurato con un timeout sufficientemente permissivo con la latenza peggiore. Ad esempio, se una chiamata richiede da 3 secondi al sito 1 ma richiede da 10 secondi al sito 2, il timeout deve essere impostato su almeno 10 secondi per gestire il sito più lento.
- Timeout dei processi BPEL
Se il processo BPEL utilizza specifici timeout di risposta alla richiesta (sincroni) e di ricezione (asincroni) solo, è necessario definirli in base allo scenario peggiore: quando la chiamata va al sito con la latenza di database più elevata. Queste impostazioni di timeout sono definite nel processo BPEL e non possono essere impostate in modo diverso per ogni sito. Per ulteriori informazioni sulla configurazione di eventi e timeout nei processi BPEL, consultare il manuale Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. Vedere la sezione Esplora altro.
Configura replica sessione
Alcune applicazioni (applicazioni Web, console come il composer di Oracle SOA, il composer BPM, l'area di lavoro BPM e così via) utilizzano a uso intensivo gli oggetti di sessione HTTP.
Uno dei vantaggi dell'implementazione del cluster esteso di Oracle Fusion Middleware (FMW) è la possibilità di fornire un failover trasparente tra i siti. Tuttavia, la replica delle sessioni tra più aree può causare un peggioramento delle prestazioni nel sistema. Oracle consiglia di definire due gruppi di replica diversi (uno per ogni area) per ridurre al minimo la replica tra i due siti.
Per configurare i gruppi di replica della sessione, effettuare le operazioni riportate di seguito.
- Nella struttura di modifica della WebLogic Console remota, selezionare Ambiente, quindi Server.
- Selezionare Nome server, quindi selezionare la scheda Cluster.
- Per ogni server nell'area 1, immettere lo stesso nome del gruppo di replica, ad esempio Region1RepGroup.
- Ripetere la procedura per i server nell'area 2, utilizzando un nome comune per tutti i server, ma diverso da quello utilizzato nell'area 1 (ad esempio, Region2RepGroup).
Si noti che l'utilizzo dei gruppi di replica è uno sforzo ottimale per replicare lo stato solo ai server nello stesso sito, ma non è un metodo deterministico. Se un singolo server è disponibile in un sito e altri sono disponibili nell'altro, la replica si verificherà in tutte le aree e continuerà per tale sessione anche se i server torneranno online nello stesso sito.
Configura riavvio in loco per JMS
Le aree di memorizzazione persistenti sono fondamentali per il corretto funzionamento dei server Oracle WebLogic Server (WLS). Con il riavvio in loco, se l'area di memorizzazione persistente rileva un errore, il servizio JMS tenterà di riavviarsi sullo stesso server prima di tentare la migrazione a un altro server. Questo metodo è più rapido della migrazione dell'intero servizio JMS a un altro server e spesso può risolvere rapidamente i problemi.
Per configurare il riavvio in loco per le aree di memorizzazione persistenti JMS, il server JMS correlato e l'area di memorizzazione persistente devono essere indirizzati a una destinazione migrabile. Questa destinazione migrabile deve utilizzare Riavvia in caso di errore, che non è abilitata per impostazione predefinita. Per configurare questa proprietà, effettuare le operazioni riportate di seguito.
- Connettersi alla WebLogic Remote Console
- Nella struttura di modifica, selezionare Ambiente, quindi Obiettivi migrabili.
- Selezionare una destinazione migrabile e abilitare Riavvia in caso di errore.
- Selezionare Salva ed eseguire il commit delle modifiche.
Configurare l'adattatore JMS Oracle FMW SOA Suite
Oracle consiglia di utilizzare la sintassi del cluster (ad esempio: cluster:t3s://cluster_name) per semplificare la configurazione. Questo approccio semplifica la configurazione consentendo all'adattatore di recuperare in modo dinamico la lista corrente di server attivi all'interno del cluster, garantendo un recupero efficiente del contesto JNDI.
Se il sistema utilizza l'adattatore JMS in modo intensivo e con payload di grandi dimensioni, si consiglia di configurare l'URL JNDI in modo che includa solo i server locali all'interno di ogni area. Ciò significa specificare i server nell'area 1 per le configurazioni nell'area 1 e i server nell'area 2 per le configurazioni nell'area 2. Questa impostazione garantisce l'affinità del contesto del sito, ottimizzando le prestazioni e riducendo la latenza.
Configurare l'adattatore file Oracle FMW SOA Suite
Questo meccanismo garantisce che lo stesso file venga elaborato da un solo server alla volta e che due istanze della scheda di rete non scrivano contemporaneamente nello stesso file.
Nella topologia cluster estesa di Oracle Fusion Middleware (FMW), ogni sito opera in modo indipendente, elaborando i file utilizzando la propria memoria condivisa dedicata. Per impostazione predefinita, tuttavia, entrambi i siti utilizzano la stessa origine dati, lo stesso schema e le stesse tabelle per i meccanismi di blocco dei file e mutex.
Nelle operazioni in uscita, l'utilizzo di una tabella di database condivisa è appropriato perché una sequenza univoca viene utilizzata come mutex per impedire alle operazioni di scrittura concorrenti di sovrascrivere i file.
Tuttavia, possono verificarsi scenari "in fase di elaborazione" per le operazioni in entrata. Le istanze dell'adattatore di file in entrambi i siti possono contrassegnare un file come "bloccato". Se lo stesso nome di file esiste in entrambi i siti, questo meccanismo può bloccare la sua elaborazione in entrambe le posizioni, ma il file verrà consumato solo in uno di essi. Per evitare queste situazioni, esistono diverse alternative:
- Implementare convenzioni di denominazione dei file specifiche del sito. Utilizzare identificatori univoci nei nomi dei file in base al sito, riducendo la probabilità di collisioni di nomi e successivo blocco.
- Configurare schemi separati per ogni area per il blocco dell'adattatore di file e le tabelle mutex, per garantire che i meccanismi di blocco dei file e mutex funzionino in modo indipendente, impedendo il blocco tra siti.
- Utilizzare un database separato per le tabelle di lock e mutex dell'adattatore di file per garantire che i metadati di elaborazione dei file vengano gestiti separatamente.
Per configurare l'adattatore di file in modo che utilizzi database o schemi separati diversi in ogni area, è necessario creare il proprietario e le tabelle dello schema appropriati e stabilire una nuova origine dati. I server nell'area 1 continueranno a utilizzare l'origine dati originale, solo il piano di distribuzione nell'area 2 verrà modificato per utilizzare la nuova origine dati.
I server nell'area 1 utilizzeranno l'origine dati originale mentre i server nell'area 2 utilizzeranno la nuova.
Configurare Oracle Fusion Middleware Oracle SOA Suite SOA in memoria
Ciò migliora le prestazioni e la scalabilità per questi processi aziendali poiché le operazioni di lettura e scrittura vengono eseguite dalla cache.
Le informazioni sullo stato BPEL vengono memorizzate e estratte dalla cache di Oracle Coherence. Lo stato del processo viene scritto nel database solo in caso di errore o a intervalli regolari utilizzando un thread write-behind.
SOA in-memory non è supportato nella topologia cluster estesa di Oracle Fusion Middleware, in cui l'uso della cache Coherence deve essere minimo, in quanto è molto sensibile ai ritardi.
Configurare Tuning WebLogic Database Leasing
Il leasing del database è un meccanismo di base utilizzato per supportare la migrazione automatica dei servizi, in particolare per i servizi singleton in cluster come i server JMS o il servizio di recupero delle transazioni JTA. Viene utilizzato per gestire e coordinare la proprietà di questi servizi singleton su più server in un cluster. Questo meccanismo utilizza un database come punto centrale per tenere traccia e controllare in modo affidabile quale server in un cluster "possiede" o gestisce un servizio singleton specifico in un determinato momento. A tale scopo, viene memorizzato un record di rilascio nel database, che viene aggiornato periodicamente (rinnovo) dal server proprietario. Vedere Leasing for Migratable Services in Amministrazione di cluster per Oracle WebLogic Server.
La configurazione per le origini dati GridLink fornita in precedenza in questa guida garantisce riconnessioni automatiche quando si verifica un failover del database o uno switchover. Tuttavia, tutti i server configurati con il leasing del database o con le aree di memorizzazione persistenti JDBC possono essere arrestati durante un'interruzione, uno switchover o un failover del database. Quando un sottosistema critico (come il servizio JTA) non riesce, il server viene impostato sullo stato FAILED e viene riavviato automaticamente dal Node Manager.
Il tempo necessario per passare allo stato NON RIUSCITO è variabile; dipende da quando vengono attivati i controlli pertinenti e può verificarsi per vari motivi:
- Se il server non è in grado di aggiornare la tabella di leasing dopo il numero totale di tentativi.
- Se il server non riesce ad accedere all'area di memorizzazione persistente JDBC JTA dopo vari tentativi e riavvii in loco.
Lo switchover di un database può richiedere alcuni minuti. Il riavvio automatico dei server WLS a causa della perdita dell'accesso all'area di memorizzazione persistente JDBC JTA richiede più tempo, circa 8-9 minuti, quindi non viene attivato durante uno switchover o un failover tipico del database. Tuttavia, un server può passare allo stato NON RIUSCITO a causa della perdita di un leasing in meno di 2 minuti con la configurazione di leasing predefinita. Pertanto, un riavvio di Oracle WebLogic Server può essere attivato automaticamente durante uno switchover o un failover di Oracle Data Guard se tale server WebLogic utilizza il leasing del database.
Esistono due parametri per migliorare la resilienza alle indisponibilità del database per i server che utilizzano il leasing del database. Questi parametri sono database-leasing-basis-connection-retry-count (1 nuovo tentativo per impostazione predefinita) e database-leasing-basis-connection-retry-delay (1 secondo per impostazione predefinita). L'aumento di questi parametri prolunga il tempo prima che si verifichi un errore di leasing perso. Ciò consente ai server WebLogic di tollerare interruzioni del database più lunghe senza riavviare automaticamente; si ricollegano semplicemente al database una volta che diventa di nuovo disponibile. Sebbene i tentativi di connessione non riescano mentre il database è inattivo, i server WebLogic non verranno riavviati.
Pertanto, in un cluster esteso, si consiglia di aumentare i valori del conteggio e del timeout dei nuovi tentativi di connessione di leasing del database per rendere il server WebLogic più resiliente alle indisponibilità del database. Per modificare queste proprietà, utilizzare i comandi WLST. Ad esempio:
$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()Suggerimento
Quando un server passa allo stato NON RIUSCITO, Node Manager tenta due riavvii per il server per impostazione predefinita. Se il server non può essere avviato correttamente, viene contrassegnato come FAILED_NOT_RESTARTABLE. È possibile ottimizzare il numero di riavvii nella scheda Stato del server. Utilizzare il parametro Numero massimo di riavvii nell'intervallo per definire il numero di volte in cui Node Manager può riavviare il server nell'intervallo specificato in Intervallo di riavvio.Configurare Coherence
Ad esempio, Oracle SOA Suite utilizza Oracle Coherence per la propagazione delle distribuzioni composte e degli aggiornamenti dei metadati (MDS) in un cluster.
Oracle Coherence supporta la comunicazione multicast e unicast per la ricerca automatica e la messaggistica dei membri del cluster. Unicast è particolarmente adatto in ambienti in cui il multicast non è disponibile o non è supportato, ad esempio in più data center o aree cloud. Utilizzando la funzione ben nota indirizzi (WKA), i membri del cluster possono scoprire e unirsi al cluster senza fare affidamento sul multicast. Quando WKA è configurato, tutte le comunicazioni multicast sono disabilitate. Per impostazione predefinita, i prodotti Oracle Fusion Middleware utilizzano unicast con un elenco WKA predefinito per Coherence.
Oracle Coherence è sensibile ai ritardi durante la formazione dei cluster e alla risposta agli heartbeat dei membri del cluster. Tuttavia, le versioni recenti hanno migliorato la tolleranza ai ritardi nella comunicazione attraverso funzioni come allowable variance. Il allowable variance definisce le variazioni di tempistica consentite nelle comunicazioni di rete all'interno di un cluster Coherence. Questo parametro configurabile (maximum-time-variance), impostato per impostazione predefinita su 16 ms, imposta la latenza massima consentita per le comunicazioni UDP con tempo di andata e ritorno (RTT). Coherence regola dinamicamente questo valore in risposta alle latenze o alle incongruenze di rete osservate, mantenendo la stabilità e le prestazioni del cluster tenendo conto di maggiori deviazioni nella tempistica prevista. Il messaggio Increasing allowable variance to XX indica una rettifica di questo tipo. Vedere Elementi di configurazione operativa in Sviluppo di applicazioni con Oracle Coherence.
Con questo miglioramento di Oracle Coherence, non vengono segnalati errori nella formazione dei cluster se la latenza rimane entro i limiti consigliati per la topologia dei cluster estesa FMW (<10ms RTT). Tuttavia, lunghi ritardi negli heartbeat del cluster possono causare conflitti nelle distribuzioni e tempi di reazione errati alle interruzioni.
Se si verificano errori nella formazione o nelle operazioni del cluster Coherence, è possibile modificare i seguenti parametri di timeout della rete Coherence:
<multicast-listener><join-timeout-milliseconds>. Nonostante sia stato originariamente progettato per le configurazioni multicast, l'impatto del timeout di join anche in unicast. Determina il tempo necessario al nodo iniziale per formare un cluster e, dopo di che, quanto tempo ogni nodo spenderà per cercare il cluster prima di provare a formarne uno proprio (se sono nella lista WKA). Il valore predefinito è 3000, su una rete inaffidabile potrebbe essere necessario aumentare questo valore, per provare per un periodo di tempo più lungo a trovare un cluster prima di avviarne uno nuovo.<packet-publisher><packet-delivery><resend-milliseconds>. L'intervallo di reinvio del pacchetto specifica il periodo di tempo minimo, in millisecondi, durante il quale il publisher del pacchetto attende un pacchetto ACK corrispondente prima di inviare di nuovo un pacchetto. Questo dovrebbe essere un paio di multipli del RTT, 10x dovrebbe essere bene. Il valore predefinito è 200.<packet-publisher><packet-delivery><timeout-milliseconds>. Per i pacchetti che richiedono conferma, specifica la quantità massima di tempo, in millisecondi, in cui un pacchetto viene inviato nuovamente. Dopo la scadenza di questo timeout, Coherence determina se il destinatario deve essere considerato terminato. Il valore predefinito di 5 minuti dovrebbe essere sufficiente, ma è possibile aumentarlo per evitare timeout durante l'adesione al cluster.<packet-publisher><packet-delivery><heartbeat-milliseconds>Questo parametro è l'intervallo di heartbeat per il rilevamento del decesso dell'anello tcp. Il valore di heartbeat predefinito è 1 secondo. È possibile aumentare il valore per alleviare il traffico di rete, ma questo prolunga anche il rilevamento dei membri non riusciti.<tcp-ring-listener><ip-timeout>e<ip-attempts>. Questi sono il tempo e i tentativi prima di determinare che un computer che ospita i membri del cluster è diventato irraggiungibile. Ip-timeout dovrebbe essere nell'area di 10x il RTT o superiore, con un minimo di 5s.<cluster-config><tcp-ring-listener><enabled>. È anche possibile disabilitare il rilevamento della morte di tcp-ring per alleviare il traffico di rete, ma rende anche il rilevamento dei membri non riusciti richiede più tempo. Per disabilitare il rilevamento della morte, impostarlo su falso. Se disabilitato, un membro del cluster utilizza l'intervallo di timeout di reinvio del publisher del pacchetto per determinare che un altro membro ha smesso di rispondere ai pacchetti UDP (per impostazione predefinita, impostato su 5 minuti).
Per modificare le impostazioni di configurazione predefinite, utilizzare un file di sostituzione Coherence. Creare un file denominato custom-coherence-override-<name>.xml e assicurarsi che sia coerente e accessibile a tutti i server all'interno del cluster. Specificare questo file nella proprietà java tangosol.coherence.override. È possibile impostarlo nella proprietà java EXTRA_JAVA_PROPERTIES nel file setUserOverrides.sh. Ad esempio:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"Esempio di file di override della coerenza per ottimizzare i parametri:
<?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>
Esempio di file di override della coerenza per ottimizzare l'intervallo 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>Esempio di file di override della coerenza per disabilitare il rilevamento della morte dell'anello 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>
Configura prestazioni servizio di rete
Alcune configurazioni predefinite del sistema operativo potrebbero non essere ottimizzate e diventa molto importante regolare alcuni parametri per rendere il trasferimento dei dati più efficiente. Questi adeguamenti diventano particolarmente significativi quando esiste un'elevata latenza tra i client e i server JDBC. I server con la latenza più elevata nell'accesso al database devono guidare la configurazione dei buffer di rete e delle impostazioni di Oracle Net Services per ottimizzare le prestazioni.
Una delle metriche chiave per determinare la configurazione ottimale è il prodotto di ritardo della larghezza di banda (BDP). Rappresenta la quantità massima di dati che possono essere in transito in una rete in qualsiasi momento. Viene calcolato moltiplicando la capacità (larghezza di banda) di un collegamento di rete per il tempo di ritardo di andata e ritorno (latenza):
BDP = Bandwidth × Round-Trip Time (RTT)- RTT: In OCI, puoi ottenere il RTT medio tra le aree dalla pagina Latenza tra più aree nella console OCI. In alternativa, è possibile determinare il tempo di andata e ritorno (RTT) con comandi quali il ping da un host all'altro nell'arco di alcuni minuti e utilizzare i tempi di risposta restituiti.
- Larghezza di banda: non c'è una larghezza di banda garantita tra le region OCI e OCI non offre uno strumento specifico di misurazione della larghezza di banda OCI. Per misurazioni precise della larghezza di banda, è possibile utilizzare strumenti come iPerf per eseguire test. La larghezza di banda testata tra Francoforte e Amsterdam è di circa 2-2,5 Gbps.
Le impostazioni del buffer del socket TCP controllano il numero di pacchetti inviati contemporaneamente in rete. Per ottenere un throughput ottimale, si consiglia di impostare la dimensione del buffer del socket su almeno il BDP. In molti casi, l'impostazione della dimensione del buffer su due volte il BDP può migliorare ulteriormente le prestazioni, soprattutto nelle reti ad alta latenza. Tuttavia, buffer eccessivamente grandi possono portare ad un maggiore utilizzo della memoria. Pertanto, è consigliabile impostare la dimensione del buffer entro l'intervallo del BDP su tre volte il BDP:
BDP ≤ Socket Buffer Size ≤ 3 × BDPConfigurare le dimensioni del buffer di I/O nel database
SEND_BUF_SIZE sul lato server è in genere sufficiente.
Se il database server riceve richieste di grandi dimensioni, impostare anche il parametro RECV_BUF_SIZE. Si consiglia di eseguire il tuning a livello di Oracle Net Services nel database anziché a livello di sistema operativo, in modo che le sessioni TCP normali come SSH e così via non utilizzino memoria aggiuntiva.
Per configurare questi parametri per il database server, impostare la dimensione dello spazio del buffer nei file listener.ora o sqlnet.ora.
-
Nel file
listener.ora, specificare i parametri dello spazio buffer per un determinato indirizzo di protocollo o per una descrizione. Di seguito è riportato un esempio delle impostazioni per una configurazione di listener Oracle RAC tipica in un sistema di Base Database in 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)))) -
Se i parametri sono impostati nel file
sqlnet.ora, vengono applicati a livello globale a tutti i listener. Di seguito è riportato un esempio di impostazioni nel filesqlnet.ora.RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
Configurare le dimensioni del buffer di I/O nei nodi del livello intermedio
Il sistema operativo Linux utilizza il tuning automatico sia per la ricezione che per il buffer del mittente.
Per il buffer di ricezione, il tuning automatico è determinato dal parametro /proc/sys/net/ipv4/tcp_moderate_rcvbuf. Se il valore del parametro è 1, il tuning automatico è abilitato. Con il tuning automatico, la dimensione del buffer del ricevitore (e la dimensione della finestra TCP) viene aggiornata dinamicamente per ogni connessione, con una dimensione massima del buffer di 4 MB.
Per il buffer del mittente, anche il tuning automatico è abilitato per impostazione predefinita. Mentre il tuning automatico del buffer di ricezione può essere controllato tramite il parametro tcp_moderate_rcvbuf, il tuning automatico del buffer di invio non ha un toggle diretto. L'impostazione di dimensioni buffer fisse disabilita il tuning automatico del buffer di invio.
Questi processi di tuning automatico sono regolati da diversi parametri del kernel che gestiscono l'allocazione della memoria per l'invio e la ricezione dei dati:
- Per dimensioni buffer di connessione
L'allocazione di memoria per ogni connessione TCP è definita da due parametri:
/proc/sys/net/ipv4/tcp_rmem, che specifica la memoria riservata ai buffer di ricezione TCP./proc/sys/net/ipv4/tcp_wmem, che specifica la memoria riservata ai buffer di invio TCP.
Entrambi i parametri accettano tre valori:
- Dimensione buffer minima: la dimensione buffer più piccola allocata per un socket TCP.
- Dimensione buffer predefinita: la dimensione buffer iniziale assegnata a un socket TCP al momento della creazione.
- Dimensione massima del buffer: la dimensione del buffer più grande che può essere allocata automaticamente per un socket TCP.
Queste impostazioni stabiliscono i limiti per i meccanismi di tuning automatico e aiutano a bilanciare l'uso della memoria, soprattutto durante i periodi di stress della memoria.
- Dimensioni buffer per applicazione
Le applicazioni possono richiedere dimensioni buffer specifiche, ma queste richieste sono soggette a limiti definiti dai seguenti parametri:
/proc/sys/net/core/rmem_max, è la finestra di ricezione massima, che imposta il limite superiore per la dimensione del buffer di ricezione che le applicazioni possono richiedere./proc/sys/net/core/wmem_max, è la finestra di invio massima, che imposta il limite superiore per la dimensione del buffer di invio che le applicazioni possono richiedere.
Per regolare le dimensioni del buffer di I/O:
Il tuning automatico TCP rimane abilitato con limiti dimensionati per il prodotto di ritardo della larghezza di banda della rete, migliorando il throughput senza ridimensionare eccessivamente l'uso della memoria di sistema.
Configura dimensione unità dati sessione
Oracle Net Services attende che queste unità vengano riempite prima di inviarle attraverso la rete. Ciascuno di questi buffer è un'unità di dati di sessione (SDU). L'adeguamento della dimensione dell'SDU alla quantità di dati forniti a Oracle Net Services può migliorare le prestazioni, l'utilizzo della rete e il consumo di memoria in un cluster esteso di Oracle Fusion Middleware con latenze superiori a 5 msec RTT.
La dimensione dell'SDU può essere impostata da 512 byte a 2 MB. In Oracle Database 23ai, la dimensione SDU predefinita è di 64 KB (65.536 byte). Le release precedenti del database hanno impostato la dimensione SDU predefinita su 8 KB.
La dimensione SDU effettiva utilizzata viene negoziata tra il client e il server al momento della connessione ed è la più piccola dei due valori. La configurazione di una dimensione SDU diversa da quella predefinita richiede la configurazione dell'SDU su entrambi i computer client e server. Oracle consiglia di impostare l'SDU sul valore massimo possibile (64k).
I client e i server negoziano l'SDU al momento della connessione; la configurazione di entrambi i lati garantisce l'utilizzo dell'SDU previsto.