{"id":231,"date":"2016-02-12T17:28:30","date_gmt":"2016-02-12T16:28:30","guid":{"rendered":"http:\/\/eppesuigoccas.homedns.org\/wordpress\/?p=231"},"modified":"2016-02-16T10:38:26","modified_gmt":"2016-02-16T09:38:26","slug":"metti-che-prendi-un-ibm-power8-per-risolvere-tutti-i-tuoi-problemi","status":"publish","type":"post","link":"https:\/\/blog.sguazz.it\/index.php\/archives\/231","title":{"rendered":"Metti che prendi un IBM Power8 per risolvere tutti i tuoi problemi"},"content":{"rendered":"

Di recente ho lavorato alla configurazione di un nuovo server baan IV con oracle. Si trattava del passaggio da un cluster con 2 server HP Integrity rx2660 con sistema operativo HP-UX B.11.31 e processore Intel Itanium 2 9140 (2 core, 1,66GHz, 4 logical CPU dovute all’attivazione dell’hyper-threading) con 32GB di RAM, ad un cluster con 2 server IBM 8286-41A<\/a> con degli LPAR con sistema operativo AIX 7.1.3.45 TL03 e processore POWER8<\/a> (6 core dei quali solo 2 abilitati, 3,02GHz, quindi 2 virtual CPU con in tutto 4\/8\/16 logical CPU configurabili con SMT) con 32GB di RAM.<\/p>\n

Sul vecchio sistema era utilizzato oracle 10g (10.2.0.4.0 standard edition), sul nuovo \u00e8 stato scelto oracle 12c (12.1.0.1.0 standard edition) perch\u00e9 il vecchio 10g non \u00e8 pi\u00f9 supportato da oracle e non va su AIX 7.1. Come conseguenza dell’aggiornamento di oracle \u00e8 stato aggiornato anche il porting set<\/em>: dalla serie 6.1c alla 9.0, con conseguente attivazione del driver di baan per oracle in configurazione \u00abcombo\u00bb.<\/p>\n

Il server HP aveva un ambiente baan+oracle di produzione su una macchina del cluster, e un secondo ambiente baan+oracle di test sulla seconda macchina. Sul nuovo cluster, in un primo momento, \u00e8 stato migrato solo l’ambiente di produzione configurando il cluster in modo tale che baan e oracle potessero andare su LPAR diverse o sulla stessa. Per questo motivo sul package di baan \u00e8 stata installata anche una oracle home da usare per connettersi via SQL*Net (e tnsnames.ora) al database oracle.<\/p>\n

L’installazione \u00e8 stata fatta mantenendo i due package (oracle e baan) sullo stesso LPAR, ma nei primi giorni di lavoro si \u00e8 capito che il nuovo server era lento, anche parecchio, se confrontato al vecchio. Una serie di analisi dettagliate hanno mostrato che le statistiche usate dall’ottimizzazione di oracle non erano aggiornate, difatti il job interno di oracle 12 che le aggiorna non era stato attivato. Il calcolo delle statistiche tramite DMBS_STATS.GATHER_SCHEMA_STATS(‘BAAN’) oppure tramite un ANALYZE TABLE BAAN.T… forniva lo stesso risultato: le prestazioni diventavano accettabili, ma la macchina era carica al 100% con un runqueue (mostrata da topas) di circa 30. \u00c8 stato allora deciso di spostare il package con oracle sul secondo LPAR, in modo da avere a disposizione il doppio dei processori.<\/p>\n

A questo punto nessuna delle macchine era carica al 100%, ma in ogni caso il sistema era lento tanto quanto prima. Per fare un esempio: il job dell’MRP durava 7 ore contro l’ora che impiegava sulla macchina HP. Il calcolo costi arrivava quasi a 12 ore contro soli 40 minuti. Oltre alla lentezza nei job, anche l’utilizzo OLTP mostrava lentezze esasperanti diffuse e generalizzate. Durante queste operazione la macchina non ha mai paginato, la quntit\u00e0 di memoria data ad oracle e chiamata SGA \u00e8 sempre stata di circa 9Gb, la RAM veramente usata dalle applicazioni (secondo lo strumento nmon) \u00e8 stata sempre attorno ai 22-23Gb rispetto ai 32Gb disponibili, l’I\/O verso lo storage \u00e8 sempre stato ottimo, il cache hit di oracle sempre superiore al 99,5%.<\/p>\n

Come mai? Ah, gi\u00e0! Non abbiamo abilitato l’\u00abarray interface\u00bb di baan.<\/p>\n

\u00c8 stata allora abilitata — limitatamente ad un job daemon — l’\u00abarray interface\u00bb: 100 record alla volta sia per la lettura dei record durante le SELECT, sia per l’invio durante le INSERT. Il dettagli dei nuovi parametri \u00e8:
\nora_init:0101000
\nora_max_array_fetch:100
\nora_max_array_insert:100
\nrds_full:100
\nssts_set_rows:100
\ninoltre sono stati impostati\u00a0STU e DTU da 8192 byte nel tnsnames.ora nonostante l’MTU sia sempre stato di 1500 byte.<\/p>\n

Purtroppo, con l’array interface, i tempi non sono cambiati di una virgola.<\/p>\n

Come mai? In effetti spulciando meglio tutta la documentazione relativa ai parametri SDU e TDU, si scopre che il beneficio nell’incrementarli si ha solo su linee lente, tipo la token ring, o la 10mbit\/s, ma qui le due LPAR sono collegate su uno switch<\/em> da 1gbit\/s full duplex che vanifica l’utilizzo di SDU e TDU. Si potrebbe provare ad attivare i jumbo frame<\/em> e aumentare l’MTU, ma questo comporta la riconfigurazione dello switch<\/em> che non \u00e8 immediata e non ha la certezza dell’incremento delle prestazioni. Invece l’\u00abarray interface\u00bb diminuisce veramente il numero dei roundtrip<\/em>, quindi deve per forza aver portato un miglioramento delle prestazioni, ma evidentemente questo non \u00e8 percepibile a causa di altri problemi decisamente maggiori.<\/p>\n

A questo punto \u00e8 stato eseguito il job dell’MRP con il profiler<\/em> (Call Graph Profiler, CGP) di baan attivo. La documentazione dice che \u00e8 disponibile solo su LN, ma non \u00e8 vero: \u00e8 disponibile solo con il porting set<\/em> di LN, ma poich\u00e9 qui usiamo il porting set di LN con baan IV, allora lo possiamo utilizzare. Oltre al CGP, \u00e8 stato attivato anche l’SQL_TRACE in modo da avere tutte le misurazioni possibili sia lato baan che lato oracle. Il job \u00e8 durato 2 ore in pi\u00f9 a causa della profilazione, ma ha mostrato una grande discrepanza nei tempi che baan cataloga\u00a0come\u00a0attesa dei dati da oracle, e quelli che oracle sostiene di avere veramente impiegato. Se baan attende in tutto 7 ore da oracle, ma oracle sostiene di avere impiegato in tutto 40 minuti, allora il problema sta nel tempo impiegato nella comunicazione tra i due: baan attende che la sua richiesta vada ad oracle, che oracle produca dei risultati, che questi risultati tornino a baan; invece nel conto di oracle c’\u00e8 il tempo dall’arrivo della richiesta di baan fino al momento dell’invio dei risultati. La differenza \u00e8 il tempo di trasporto delle richieste e dei risultati.<\/em><\/p>\n

Chiarito questo, \u00e8 stato ipotizzato che il colpevole fosse SQL*Net, cio\u00e8 il protocollo di rete di oracle. L’alternativa ad SQL*Net \u00e8 BEQ, che per\u00f2 funziona solo su IPC e non su TCP\/IP. quindi, per passare a BEQ \u00e8 stato portato il package di oracle sulla stessa LPAR di baan ed \u00e8 stato riconfigurato baan per comunicare tramite BEQ cio\u00e8: ORACLE_SID al posto di ORACLE_SERVICE_NAME e utilizzo della stessa oracle home dell’istanza.<\/p>\n

Alla connessione degli utenti baan ad oracle si sono avuti gli errori ORA-01116 \u00aberror in opening database file\u00bb. Questo problema \u00e8 dovuto al fatto che i datafile<\/em> di oracle sono adesso aperti dai processi client di utenti baan (del gruppo unix bsp), mentre prima tutti i file erano aperti dall’utente AIX oracle. Perch\u00e9 quest’ultimo potesse utilizzare datafile<\/em> pi\u00f9 grandi di 2Gb, gli sono state alzate le soglie massime in \/etc\/security\/limits.conf<\/em>, ma adesso i processi degli utenti baan non riescono ad aprire quei file perch\u00e9 la loro soglia \u00e8 minore. Per risolvere questo problema, poich\u00e9 non \u00e8 possibile su AIX impostare i limiti per un gruppo (ad esempio, su Linux, si sarebbe potuto utilizzare il nome \u00ab@bsp\u00bb per assegnare i limiti a tutto il gruppo bsp) si \u00e8 deciso di aumentare i limiti predefiniti di tutti gli utenti, equiparandoli a quelli precedentemente assegnati ad oracle. A quel punto \u00e8 stato possibile collegarsi da baan ad oracle senza errori.<\/p>\n

I tempi di esecuzione dei job sono tornati minimi: con l’\u00abarray interface\u00bb l’MRP gira in 45 minuti, il calcolo costi in 28 minuti (quest’ultimo ha impiegato 10 minuti di CPU nel processo audit_srv poich\u00e9 la tabella degli articoli \u00e8 sotto audit). Quindi la differenza tra SQL*Net e BEQ si \u00e8 rivelata effettivamente enorme.<\/p>\n

Nell’utilizzo durante la giornata, con pochi job e parecchi utenti, la macchina non sembrava particolarmente veloce e neppure lenta, ma era sempre carica al 100%. Per poter lavorare con un minimo di margine \u00e8 stato proposto di attivare un terzo core della CPU, ma in questo caso si avrebbero avuti due problemi: il primo \u00e8 che il costo delle licenze oracle standard edition sarebbero aumentate di 25000\u20ac, il secondo \u00e8 che per poter aggiornare oracle alle prossime versioni \u00e8 necessario passare gratuitamente alla standard edition two (SE2), oppure a pagamento alla enterprise edition, ma la SE2 impone il limite di 2 core e di 16 thread. Quindi l’abilitazione di un terzo core \u00e8 una opzione scartata perch\u00e9 troppo costosa.<\/p>\n

Come alternativa \u00e8 stato modificato il numero di processori logici: l’LPAR ha assegnati due core, che dentro l’LPAR sono visti come CPU virtuali, che sono poi divisi in CPU logiche. Fino ad ora la divisione era in quarti: ogni CPU virtuale era divisa in 4, ma il power permette anche la divisione in 2 o in 8 diversi thread hardware<\/em>. Sono quindi state fatte delle prove e si \u00e8 visto che utilizzando la configurazione SMT8 (cio\u00e8 8 thread hardware per ciascuno dei due core della CPU, arrivando ad un parallelismo totale di 16) il sistema non era pi\u00f9 costantemente carico al 100%, ma aveva un minimo di margine aggiuntivo che durante l’orario lavorativo era tra il 2 e il 7% (idle), mentre quando gli utenti italiani non lavoravano e restavano solo quelli stranieri (una quarantina compresi i job daemon), si arrivava al 10-20% di idle.<\/p>\n

Come funziona, a grandi linee, questa cosa\u00a0del numero di thread hardware<\/em>: il singolo core del POWER8 \u00e8 composto da vari componenti hardware che possono essere utilizzati per \u00a0\u00abcomporre\u00bb 2, 4\u00a0o 8\u00a0CPU\u00a0logiche. L’hardware \u00e8 sempre lo stesso, quindi se lo divido in 4 (configurazione SMT4), avr\u00f2 delle CPU logiche che al massimo avranno 1\/4 della potenza totale del core; se lo divido in 8 (configurazione SMT8) allora ogni CPU logica avr\u00e0 la met\u00e0 della potenza che avrebbe in SMT4, cio\u00e8 1\/8 della potenza totale del core.<\/p>\n

Come funziona la richiesta di potenza di calcolo di un normale processo baan<\/em>: la bshell, cio\u00e8 il processo del sistema operativo che contiene la logica di baan, esegue le sessioni di baan. Quando deve accedere al database, fa la richiesta ad oracle e attende la risposta. A quel punto sul sistema operativo la bshell non chiede pi\u00f9 CPU, che viene invece richiesta dal processo oracle (che nella nostra configurazione \u00e8 DEDICATED e non MTS, cio\u00e8 c’\u00e8 un processo oracle per ogni bshell). Quando oracle termina, restituisce alla bshell il risultato e non richiede pi\u00f9 la CPU. A quel punto la bshell viene svegliata e riprende l’elaborazione con la CPU. Morale: pur avendo vari processi del sistema operativo, solo uno \u00e8 attivo in un determinato momento, quindi un utente baan (o un job daemon) richiede al sistema esattamente una CPU.<\/p>\n

Chiarito come funzionano SMT e la richiesta di CPU, vediamo i due scenari OLTP e batch:<\/p>\n