Risoluzione dei problemi relativi alle prestazioni
Scenario: si stanno verificando problemi relativi alle prestazioni,
come ad esempio:
Tempi di riposta scadenti nel workbench quando
si sviluppano flussi di messaggi
Tempo di risposta scadente in fase di distribuzione
Singoli messaggi che impiegano molto tempo per l'elaborazione
Prestazioni generali scadenti o prestazioni che non si adattano bene
Soluzione: le possibili soluzioni sono:
Rendere più veloce la messaggistica persistente di WebSphere MQ
ottimizzando l'I/O (Input/Output)
Rendere più veloce l'accesso ottimizzando l'I/O
Aumentare la memoria di sistema
Utilizzare istanze aggiuntive o più gruppi di esecuzione
Ottimizzare le istruzioni ESQL per ottenere il massimo delle prestazioni
Una fonte di informazioni valida per quanto riguarda le prestazioni è rappresentata dalla serie di prospetti
in WebSphere MQ Family Category 2 (freeware)
SupportPacs, disponibile per lo scaricamento dalla pagina Web dei SupportPac di
WebSphere MQ.
Spiegazione: quando un processo termina in modo anomalo, viene inserita una voce
nella registrazione
errori locale e potrebbe venire scritto un file di dati dump
nella directory della registrazione errori o
z/OS. Questa directory non ha limiti e se non vengono eliminati,
al suo interno, i file obsoleti, si potrebbe scoprire che le prestazioni del sistema diminuiscono a causa
della notevole quantità di spazio utilizzata da vecchi file di fine anomala.
Soluzione: su Windows,
all'utente è consigliato di utilizzare il parametro -w del comando mqsicreatebroker
per creare la directory degli errori in una partizione del disco fisso che non contenga WebSphere Message Broker or Windows stesso.
Si verificano problemi di configurazione con un gran numero di componenti
Scenario: si verificano problemi di configurazione con
un gran numero di componenti.
Spiegazione: se si esegue WebSphere Message Broker con
un gran numero di componenti configurati, il footprint della memoria dei processi del
broker (specialmente DataFlowEngine) potrebbe superare i limiti della memoria.
In particolare, potrebbe essere superato il limite dei processi utente oppure si potrebbe raggiungere
il limite dello spazio indirizzi. Si possono verificare problemi, come ad esempio il messaggio di errore
BIP2106E, quando si esegue un broker con:
Un gran numero di flussi di messaggi
Più databases
Messaggi di input o output di dimensioni molto grandi
Soluzione: utilizzare strumenti specifici per il sistema operativo
per controllare la dimensione massima del processo in errore, quindi verificare eventuali
limiti utente (se applicabili) o limiti del computer sulla dimensione del processo.
Utilizzare il comando ulimit per verificare i limiti
utente su sistemi Linux o UNIX
ed aumentarne il valore se necessario.
Esiste un limite rigido in ogni sistema operativo
per quanto riguarda la dimensione massima dei processi, superato il quale l'errore è inevitabile:
Sistema operativo
Dimensione massima del processo
Windows
2 GB
Solaris
Circa 3.75 GB
HP-UX
Circa 3 GB, varia in base alle impostazioni del kernel
AIX (sistema
a 32 bit)
2 GB
z/OS
2 GB
L'aumento dei limiti utente oltre questi valori non farà alcuna differenza.
Se i processi broker raggiungono regolarmente queste dimensioni, prendere in considerazione la possibilità
di distribuire i flussi di messaggi attraverso più gruppi di esecuzione onde ridurre la dimensione di ognuno di essi
al di sotto di questi limiti.
Su AIX, WebSphere Message Broker
limita DataFlowEngines a due segmenti di memoria da 256 MB, cioè, 512 MB. Normalmente i processi di
DataFlowEngine non richiedono più di 512 MB di spazio indirizzi su AIX,
quindi il file eseguibile di DataFlowEngine è collegato in modo tale da avere uno spazio
indirizzi predefinito di due segmenti. Tuttavia, è possibile estendere la dimensione
dello spazio indirizzi di AIX disponibile per
il processo DataFlowEngine aumentando il numero dei segmenti di memoria da 256 MB
che può utilizzare. Si può fare in modo che DataFlowEngine utilizzi più segmenti di memoria
tramite il seguente comando shell:
In questo modo si crea una versione di DataFlowEngine
che utilizza quattro segmenti (cioè, 1 GB).
In alternativa,
su AIX 5.1 e successivi, si può ottenere
lo stesso risultato utilizzando il comando ldedit:
ldedit -b maxdata:0x40000000 DataFlowEngine
L'applicazione della manutenzione del fix pack sostituisce il DataFlowEngine esistente,
quindi se è stato utilizzato il processo descritto sopra, ripeterlo dopo l'installazione di ogni fix pack.
La tecnica descritta sopra consente di sostituire solo
il limite variabile non quello fisso. Se i processi broker raggiungono regolarmente queste dimensioni, prendere in considerazione la possibilità
di distribuire i flussi di messaggi attraverso più gruppi di esecuzione onde ridurre la dimensione di ognuno di essi in modo che sia
al di sotto di questi limiti.
Un loop di WHILE in un array XML di grandi dimensioni impiega molto tempo per l'elaborazione
Scenario: Un loop di WHILE in un array XML di grandi dimensioni impiega
molto tempo per l'elaborazione.
Spiegazione: probabilmente si sta utilizzando la funzione CARDINALITY()
per stabilire la dimensione dell'array nell'istruzione WHILE. Questo non è
consigliato poiché, con array di grandi dimensioni, il costo di stabilire il numero di elementi
è proporzionale alla dimensione dell'array. La funzione CARDINALITY
viene richiamata ad ogni esecuzione dell'istruzione WHILE. Il messaggio ha molti elementi,
quindi vi è un sovraccarico significativo quando si esegue il loop in questo
modo.
Soluzione: a meno di non possedere un messaggio in cui il numero di
elementi dell'array cresce in modo dinamico, determinare la dimensione dell'array
prima di avviare il loop di WHILE. Utilizzare un codice simile al seguente esempio:
DECLARE i,c INTEGER;
SET i = 1;
SET c=CARDINALITY(OutputRoot.XML.MyMessage.Array[ ]);
WHILE i <= c DO
. . .
. . . loop processing
. . .
END WHILE;
Le chiamate remote waitForMessages con WebSphere MQ Everyplace sono
lente
Scenario: le chiamate remote waitForMessages con WebSphere MQ Everyplace sono
lente.
Spiegazione: questo problema si verifica perché una chiamata remota
waitForMessages() provoca necessariamente un'azione di polling: il gestore code client tenta
ripetutamente di richiamare un messaggio, fino a quando non è disponibile uno sulla coda remota
o non si raggiunge il timeout.
Soluzione: definire una coda di memorizzazione e inoltro sul gestore code del broker
ed una coda server home sul client. In questo modo si ottiene un livello di
disgiunzione che consente alla disposizione di funzionare nel caso in cui il gestore code
client non sia più disponibile. In alternativa, specificare una coda remota
nel nodo di output WebSphere MQ Everyplace, in modo che una chiamata
GET locale sia sufficiente sul lato client.
Vi è un decremento nelle prestazioni per le procedure memorizzate
Scenario: le procedure memorizzate che non restituiscono serie di risultati,
non hanno prestazioni paragonabili ha quelle che avevano quando utilizzavano driver DataDirect versione 4.1.
Spiegazione: i nuovi driver Oracle DataDirect versione 5
ora utilizzano il parametro di configurazione ProcedureRetResults per consentire
al driver di restituire serie di risultati dalle procedure memorizzate. Questo parametro
si applica solo a Oracle. Per impostazione predefinita, il parametro è impostato su 1 e
deve essere 1 se si utilizzano procedure memorizzate che restituiscono serie di risultati. Quando questo
parametro viene impostato su 0, il driver non restituisce serie di risultati dalle procedure
memorizzare e, come risultato; si possono avere prestazioni migliori.
Soluzione: se le procedure memorizzate non restituiscono alcuna serie
di risultati, impostare il parametro ProcedureRetResults su 0 (zero).
Basse prestazioni su workbench nell'esecuzione di grandi progetti.
Scenario: basse prestazioni su workbench nell'esecuzione di progetti di grandi dimensioni o complessi.
Spiegazione: Le basse prestazioni sono dovute a frequenti modifiche del progetto, come l'aggiunta o la rimozione di progetti o l'utilizzo di Progetto > Clean e questo perché aggiornamenti di un progetto completo utilizzano grandi quantità di memoria a causa della dimensione, del numero e delle connessioni tra file.
Soluzione: Aumentare la memoria del sistema.
Il valore PutTime notificato da WebSphere MQ su z/OS ed altri valori di ore o registrazioni data/ora non sono coerenti
Scenario: il valore PutTime notificato da WebSphere MQ su z/OS ed altri valori di ore o registrazioni data/ora non sono coerenti.
Viene riscontrata una differenza di circa 20 secondi nei seguenti elementi:
tracce (inclusa quella ottenuta dal nodo Trace)
la registrazione data/ora MQPUTTIME nell'intestazione MQMD del messaggio
registrazioni data/ora ottenute da ESQL (ad esempio, in un nodo Compute)
Spiegazione: WebSphere Message Broker notifica
l'ora utilizzando l'UTC (Coordinated Universal Time), che non tiene conto dei
secondi di aggiustamento. Tuttavia, su z/OS, il valore
putTime del messaggio notificato da WebSphere MQ nell'intestazione
MQMD di un messaggio tiene conto dei
secondi di aggiustamento, utilizzando il valore specificato per il numero di secondi di aggiustamento
nel campo CVT.
Questa incoerenza può causare:
problemi durante il debug
problemi con i flussi di messaggi se si utilizzano registrazioni data/ora per controllare il flusso
di messaggi
informazioni non corrette
Soluzione: impostare il campo CVT in modo che sia conforme ai secondi di aggiustamento
UTC. In alternativa, aggiungere uno scostamento per regolare la lettura di una registrazione data/ora
z/OS. Ad esempio, aggiungere 20 secondi quando si tenta di ottenere il valore CURRENT_TIME in
ESQL.