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 Event 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 Event 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 Event 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.
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.
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 Event 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.