Pianificare l’high availability su server dedicati economici, parte 2

Nel primo post della serie mi sono soffermato sulla necessità di stabilire dei canali di comunicazione efficaci con il proprio hosting provider, adesso affronterò il problema dal punto di vista tecnico.

Ad onor del vero, penso che chi fa business online dovrebbe concentrarsi su quello che sa fare meglio – il business – e non sull’ottimizzazione dei sistemi, tuttavia anche se non siete dei tecnici e non metterete mai il naso dentro un server, è bene conoscere il campo di battaglia con il quale vi dovrete confrontare.

Perchè ottimizzare un sistema è come una piccola guerra, ci sono sempre dei compromessi da fare e come in guerra tutti i compromessi causano ‘danni collaterali’.

Immagina di avere un blog in wordpress in hosting su di un server dedicato oppure su di un server vps, ovvero puoi quantomeno accedere all’ambiente linux sottostante con una password di root.

Immagina inoltre che il tuo blog abbia davvero problemi di performance: questo è un presupposto essenziale perchè se non hai problemi non devi mai cercare di ottimizzare un sistema, rischieresti solo di destabilizzarlo.

Tornando a wordpress, questo è basato su un’architettura LAMP, quindi il tuo hosting ti avrà fornito un server linux con apache e php preinstallati. Tipicamente il tutto gira all’interno di un unico sistema operativo quindi se fai login in root e lanci un ‘pstree’, trovi in esecuzione sia apache+php che MySQL.

E’ probabile che questa sia la configurazione LAMP che hai sempre visto e alla quale sei abituato.

Se non sei un sistemista e se non hai mai avuto problemi di performance non ti sarà mai venuto in mente che potresti eseguire Apache e MySQL su due server dedicati differenti (non correre subito a comprare un nuovo server dal tuo provider, aspetta!)

Prima di tutto soffermati ad analizzare la situazione, fai login nel tuo server come root, esegui il comando ‘top’ e Prendi nota dei valori di “load average”, di CPU e di memoria (libera, usata e swap). Guarda inoltre la lista dei processi e annota quanta CPU consumano Apache e MySQL rispettivamente.

Se il load average è molto vicino a zero, la CPU idem, la memoria usata è minore di quella installata e l’utilizzo dello swap è zero stai cercando di ottimizzare un sistema che è già scarico, fai logoff e vatti a godere una birra.

Altrimenti, comincia ad analizzare i dati e fatti queste domande:

Il sistema ha usato recentemente dello swap?
Se il sistema usa lo swap vuol dire che ha usato tutta la memoria disponibile.

In genere, a questo punto, l’utente medio corre dall’hosting provider e si fa vendere più RAM e magari una macchina più potente, ma questo approccio è tanto efficiente quanto usare una bomba atomica per eliminare un termitaio, funziona ma è una misura sproporzionata al risultato.

Quello che devi fare è capire se la memoria è usata maggiormente da Apache o da MySQL e iniziare ad ottimizzare la configurazione del servizio che occupa più RAM.

Il sistema non usa swap e ha tantissima memoria libera?
Generalmente questo si verifica dopo che hai usato l’approccio “bomba atomica su termite” visto sopra.

Già che hai fatto l’investimento, entra nelle configurazioni di apache e di MySQL e assicurati che utilizzino quanta più memoria possibile per attività di caching delle pagine e delle query.

Dovresti comunque ottenere un incremento delle prestazioni del tuo server, cosa significa?

Vuole dire che quell’aumento di prestazioni non è dovuto tanto all’hardware più potente bensi alle ottimizzazioni fatte. Questo significa inoltre che avresti potuto migliorare la situazione precedente senza affrontare una spesa: risolvere i problemi con hardware più potente non è sempre la soluzione migliore.

Il sistema ha un load average alto?
Qui ci dobbiamo intendere: se hai 4 processori e un sito moderatamente trafficato, avere un load average di 1 non significa che la macchina è sovraccarica. Avere un load average di 25 nella stessa situazione, invece, è un problema

Se il tuo load average è alto devi capire se il problema sta in Apache oppure in MySQL, ovvero: sono i tuoi script php ad essere molto pesanti, stai ricevendo più richieste di quante apache è configurato per servire, oppure sono le query MySQL a richiedere molto tempo per essere eseguite?

Fai un giro sui log di Apache e di MySQL, abilita il log delle query lente e senza indici, verifica che non ci siano errori che suonano come:

> “sto ricevendo più richieste di quelle che posso servire, aumentami i thread” (sia apache che mysql danno messaggi di questo tipo)

> “la query xxx ha impiegato più di 3 secondi ad essere eseguita” (MySQL da queste informazioni nel log delle query lente, se lo hai abilitato. Se non lo hai fatto abilitalo subito da my.cnf)

> “il processo php xxxx è rimasto appeso per troppo tempo e sarà terminato” (questo vuol dire che i tuoi script usano male la RAM oppure non vengono terminati correttamente e quindi devi ottimizzarli.

Ricorda che molto spesso anche query relativamente semplici possono impiegare molto tempo, se il database ha molte righe: ad esempio, lo sapevi che le query “select count(*)” quando contengono una clausola “where” effettuano un full table scan anche su innodb?

Quindi, ricordati sempre che anche il codice potrebbe (e dovrebbe) essere ottimizzato, al pari di un server.

E adesso i danni collaterali….
Siccome le risorse del sistema sono una quantità limitata, se scegli di ottimizzare un componente rischi di penalizzare un altro.

Ad esempio: se MySQL ha molte query lente e cerchi di aumentare la cache delle query per migliorarne le performance, la macchina userà più RAM e questo potrebbe dare fastidio a degli script PHP che prima non avevano problemi.

Oppure: se Apache riceve molte più richieste di quante ne può servire, potresti ottimizzare aumentando il numero di thread che apache tiene in ascolto. Questo però potrebbe aumentare il numero di script PHP in esecuzione e mandare alle stelle il Load Average.

L’ottimizzazione di un server è sempre un processo empirico, durante ogni step potresti causare un down, ogni down potrebbe darti indicazioni importanti per capire quale è il tuo collo di bottiglia.

Nella terza parte di questo blog spiegherò nel dettaglio come separare a livello applicativo Apache da MySQL, quando conviene e come bisogna farlo, quali sono i rischi.

Se hai bisogno di ottimizzare un server e hai bisogno di consulenza, se vuoi posso darti una mano, contattami attraverso questo form. Creare infrastrutture dedicate al web ottimizzate e scalabili è esattamente il lavoro che svolgo in Level iP (oltre che scrivere questo allegro blog, s’intende).