Monitorare le performance con WRKSYSSTS

WRKSYSSTS è la prima schermata che si apre quando qualcuno dice che il sistema è lento, ed è anche quella che si guarda peggio: si legge la percentuale di CPU in alto, e se è bassa si conclude che il problema è altrove. Quasi sempre la risposta sta più in basso, nella tabella dei pool di memoria.

Prima di leggere, azzerare

I contatori mostrati sono cumulativi dall'ultima rilevazione. Se nessuno azzera mai, si stanno guardando medie che comprendono la notte, il fine settimana e tre riavvii.

WRKSYSSTS RESET(*YES)

Poi si preme F5 per aggiornare dopo un intervallo definito. Il modo corretto è: azzerare, aspettare qualche minuto di lavoro reale, aggiornare, leggere.

I numeri in cima

• % CPU used — utile, ma non basta. Un sistema al 30% di CPU può essere fermo del tutto perché sta aspettando i dischi.
• % DB capability — quanta parte della CPU sta andando in operazioni di database. Un valore alto non è un problema di per sé: su una macchina gestionale è normale.
• Jobs in system, Active jobs — se il numero di job attivi cresce senza che nessuno abbia lanciato nulla, c'è qualcosa che li sta accumulando.

La tabella dei pool: dove sta la risposta

È la parte che conta. Per ogni pool di memoria compaiono, fra le altre, due colonne:

• DB Faults e Non-DB Faults — quante volte al secondo il sistema ha dovuto andare a prendere sul disco qualcosa che non aveva in memoria.

Un fault non è un errore: è il funzionamento normale della memoria virtuale. Il problema è la quantità. Se un pool applicativo mostra faults nell'ordine delle centinaia al secondo, quel pool non ha memoria sufficiente per il lavoro che ci gira dentro, e la macchina sta passando il tempo a leggere e riscrivere le stesse pagine.

Non esiste una soglia universale valida per tutte le installazioni: dipende dal numero di processori, dalla configurazione dei dischi e dal tipo di carico. Il valore utile è quello della propria macchina in una giornata tranquilla, annotato una volta e usato come riferimento. È l'unico confronto che significhi qualcosa.

Il pool 1, il machine pool, è un caso a parte: lì i faults devono essere bassissimi, dell'ordine delle unità al secondo. Se il machine pool va in fault, ne risente tutto il sistema, perché contiene il codice del sistema operativo.

Il pool giusto per il lavoro giusto

Su molte installazioni tutto il batch e tutto l'interattivo condividono lo stesso pool. Finché il carico è leggero funziona; quando un batch pesante comincia a leggere un file da milioni di record, si porta via la memoria e gli utenti interattivi cominciano ad aspettare.

Separare i pool è una modifica reversibile e a basso rischio: si crea un pool condiviso, si assegna il sottosistema batch a quel pool, e si dà a ciascuno la memoria che gli serve. Il sistema può anche regolarli da solo se QPFRADJ è impostato per farlo — cosa che di solito è già attiva e conviene lasciare attiva.

I dischi non sono su questa schermata

WRKSYSSTS non dice niente sull'occupazione dei dischi. Serve il comando gemello:

WRKDSKSTS RESET(*YES)

Le colonne che contano sono % Used (quanto è pieno) e % Busy (quanto sta lavorando). Un disco costantemente sopra l'80-90% di occupazione fa peggiorare le prestazioni di tutto il sistema, perché il codice che gestisce lo spazio deve lavorare di più per trovarne di libero.

Su % Busy vale la stessa regola dei faults: conta il confronto con la propria normalità. Un braccio molto più occupato degli altri, però, segnala quasi sempre uno sbilanciamento nella distribuzione dei dati, e vale la pena guardarlo.

Chi sta consumando

Individuato il problema, resta da capire chi lo causa:

WRKACTJOB SEQ(*CPUPCT)

Ordina i job per consumo di CPU e mette in cima i responsabili. Da lì, opzione 5 e poi 10 per il job log, oppure opzione 11 per vedere le chiamate in corso.

Chi ha Performance Tools installato ha anche WRKSYSACT, che mostra il consumo in tempo reale invece che cumulativo — molto più utile per cogliere un picco mentre sta accadendo.

Un ordine di lettura che funziona

1. WRKSYSSTS RESET(*YES), aspettare qualche minuto, F5.
2. Guardare i faults per pool, non la CPU.
3. WRKDSKSTS per escludere che il problema sia lo spazio o un disco sbilanciato.
4. WRKACTJOB SEQ(*CPUPCT) per dare un nome al colpevole.
5. Annotare i valori di una giornata normale, così la prossima volta c'è un termine di paragone.

Il punto 5 è quello che nessuno fa e che rende inutili tutti gli altri: senza sapere com'è la macchina quando sta bene, qualsiasi numero letto durante un problema è solo un numero.

Su quali versioni funziona

WRKSYSSTS, WRKDSKSTS, WRKACTJOB — comandi storici, presenti su tutte le release in uso. WRKSYSACT richiede invece il prodotto Performance Tools, a licenza separata.

La via SQL: QSYS2.SYSTEM_STATUS_INFO — la stessa informazione di WRKSYSSTS si può leggere anche come vista SQL. È documentata almeno da IBM i 7.3 ed è stata ampliata con nuove colonne nelle release successive:

SELECT ELAPSED_CPU_USED, SYSTEM_ASP_USED,
       CURRENT_TEMPORARY_STORAGE
  FROM QSYS2.SYSTEM_STATUS_INFO;

Il vantaggio rispetto alla schermata è che il valore diventa disponibile a un programma: è quello che rende possibile l'automazione dei controlli. Prima che questa vista esistesse lo stesso dato si otteneva solo dalle API di sistema (QWCRSSTS) richiamate da un programma, oppure leggendo la schermata a occhio.

Esiste anche QSYS2.SYSTEM_STATUS_INFO_BASIC, più leggera da interrogare quando servono solo i valori essenziali.

Il numero di colonne di queste viste cresce a ogni release. Se una colonna citata qui non esiste sulla tua macchina, è perché è stata aggiunta più tardi: la pagina della documentazione per la tua versione riporta l'elenco esatto.

Fonti

• SYSTEM_STATUS_INFO view — IBM Documentation 7.3
• SYSTEM_STATUS_INFO view — IBM Documentation 7.4
• QSYS2.SYSTEM_STATUS_INFO — IBM Support
• ACTIVE_JOB_INFO table function — IBM Documentation 7.5