ottimizzazione

Come ottimizzare mysql server con il tuning

Riprendo e sintetizzo in italiano l’articolo “What to tune in MySQL Server after installation” del blog www.mysqlperformanceblog.com, un sito davvero interessante curato nei contenuti dagli autori del libro “High performance MySQL”.

Il file di configurazione di Mysql offre la possibilità di gestire molte variabili, che permettono di configurare un database ottimizzato per le esigenze di chi lo utilizza, anche in base all’hardware che si dispone sulla macchina che ospita il db.

Vediamo le principali:

  • key_buffer_size – Questa proprietà ha valore con tabelle di tipo MyISAM e, se si usano solo questa tipologia di tabelle, si consiglia di settarla al 30-40% della memoria disponibile. Bisogna infatti ricordarsi che MyISAM usa la cache del sistema operativo per memorizzare i dati e quindi bisogna far bene le proprie valutazione nello scegliere il valore da assegnare a questa variabile, il calcolo va fatto soprattutto in base alla quantità di indici e dati per evitare di sottrarre troppe risorse al sistema operativo stesso. Il valore minimo consigliato per ottenere risultati decenti è comunque sui 16-32MB.
  • innodb_buffer_pool_size – Questa proprietà è molto importante utilizzando tabelle di tipo InnoDB. Utilizzando InnoDB dati e indici vengono memorizzati dal pool, quindi si può pensare di portare al 70-80% questa proprietà. E’ inoltre consigliato di non superare i 2-3,5 GB sulle macchine a 32bit, perchè sopra una certa soglia il rendimento non aumenta.
  • innodb_additional_mem_pool_size – Questa proprietà pare non influire moltissimo sulle performance, si consiglia un valore massimo di 20MB o poco più (il default è 2MB).
  • innodb_log_file_size – Questa proprietà definisce la grandezza massima del file di log per tabelle InnoDB. Pur essendo vero che maggiore è la dimensione, migliori sono le prestazioni, è anche vero che bisogna fare i conti con le dimensioni del server. A seconda di tale considerazione si consiglia un tuning di questa variabile tra i 64 e i 512MB.
  • innodb_log_buffer_size – Il default per questa variabile è 1MB e per sistemi con poche trasnizioni ed un traffico medio potrebbe bastare. Non va settato un valore troppo alto perchè è il buffer è flushato ogni secondo ed esagerare significherebbe sprecare memoria. Solitamente sono più che sufficienti 8-16 MB.
  • innodb_flush_log_at_trx_commit – Se sembra che InnoDB sia più lento di MyISAM è possibile che questo valore sia stato configurato male. Il default (1) significa che ad ogni commit di una transizione (o statement fuori dalla stessa) necessita di fare flush del log su disco, un’operazione piuttosto costosa se molto frequente. Settare il valore a 2 significa fare il flush del log solo tramite cache del sistema operativo. Il valore 0 è più veloce, ma è rischioso perchè si possono perdere dati durante le transizioni nel caso di un crash di MySQL Server. Anche il valore 2 è rischioso se il sistema operativo va in crash.
  • table_cache – Aprire tabelle è costoso e per mantenere tabelle in memoria è utile avere una cache abbastanza spaziosa. 1024 MB è un buon valore se si ha un sistema sotto le 200 tabelle, ricordandosi sempre che ogni connessione si porta via la propria quantità di memoria.
  • thread_cache – La creazione e distruzione di thread è dispendiosa e avviene ad ogni connessione e disconnessione dal db. Il valore consigliato è di almeno 16, con l’obbiettivo di non avere crezione di thread durante le normali operazioni.
  • query_cache_size – Utile per applicazioni con molti dati in lettura. Valori compresi tra i 32 e i 512 MB sono i migliori, a seconda della potenza della vostra macchina.

Al momento in cui scrivo le considerazioni valgono per MySQL Server 5 (io le ho provate su MySQL Server 5.1) e sono comunque suggerimenti da utilizzare con criterio e in base alle possibilità della propria macchina.

E’ necessario rammentare infatti che queste appena descritte sono tutte variabili definite a livello globale, quindi ragionate bene sulle disponibilità della vostra macchina e sulle necessità delle applicazioni che ci gireranno sopra prima di esagerare, rischiando di peggiorare le performance.
A voi la responsabilità delle vostre.. configurazioni. :)

IT e Ambiente: due mondi che collaborano

L’Information technology (IT) cerca da sempre soluzioni nel mondo dell’hardware e del software per ottenere le massime prestazioni col minimo sforzo in termini di tempo e risorse.
Ora, pensandoci un secondo, ci si accorge che la salvaguardia dell’ambiente si basa su un concetto molto simile: necessità da soddisfare e risorse limitate (generazione di energia, produzione di prodotti, ecc..).
Ma allora perchè nell’affrontare tutte queste operazioni nei confronti dell’ambiente non vengono utilizzati gli stessi criteri che il buon informatico (sia egli un tecnico o un project manager) utilizza?

Senza entrare troppo nel filosofico, vediamo una linea concreta di azioni che possiamo fare per risparmiare energia (e quindi anche quattrini) durante il nostro lavoro quotidiano:

  • spegnere il monitor quando ci allontaniamo dal pc, anche se solo per pochi minuti: le pause sono sempre di durata imprevedibile, una telefonata, un caffè, una riunione potrebbero tenerci impegnati per decine di minuti, lasciando il nostro schermo acceso per nulla;
  • utilizzare le varie tecniche di risparmio energetico messe a disposizione dal proprio pc (screensaver, freezing, standby) quando si sa che si dovrà stare via un pò più a lungo;
  • non lasciare acceso il computer quando non è necessario: spesso ci si allontana dalla propria postazione per ore, dicendosi “tanto dopo mi serve”, per poi tornare e spegnere il pc.

Tutte queste sono piccolissime azioni che hanno un impatto minimo sulla giornata di ciascuno ma che, moltiplicate per il numero di persone che stanno davanti ad un computer (soprattutto in azienda) e per il numero di giorni di utilizzo nel corso dell’anno, fanno capire quanto grande possa essere il risparmio energetico attuabile, guadagnando anche in termini di performance delle proprie macchine, meno soggette all’usura.

Quindi, lato client tutto bene.. ma per i nostri server?

HTML.it sta rilasciando in questo inizio 2009 una guida al risparmio energetico rivolto ai server, con considerazioni interessanti ed efficaci, poco spesso messe in atto dagli amministratori di rete.
Consiglio la lettura a chi gestisce uno o più server (ma in generale a tutti, poiché alcune semplici mosse possono essere applicate anche sui nostri client).

Il modo corretto per manutenere un sito

Vi segnalo un interessante articolo a proposito della manutenzione dei siti web dal titolo 10 Measures for Continuous Website Maintenance, scritto da Jens Meiert qualche mese fa.

L’articolo tocca molteplici punti, riflessioni che invitano ad un utilizzo migliore delle proprie risorse al fine di dare una migliore esperienza all’utente rendendo più performante e mantenendo aggiornato il proprio sito.

Le attività proposte sono indubbiamente dispendiose in prima battuta (motivo per cui moltissimi mantainer non si preoccupano minimante di affrontarle) ma, col passare del tempo, aiutano a rendere il proprio sito (e il web) “un posto migliore”. :)

Youtube promuove Google Chrome come browser per i suoi video

Il piccolo grande browser di Mountain View è ora pubblicizzato in modo (molto) esplicito nella home page di Youtube. Una grossa spinta, che viene data anche grazie all’ausilio di alcuni video singolari, come il filmato sulla nascita di Google Chrome.

Mossa furba, youtube è indubiamente uno dei canali più giganteschi di questo web 2.0 per raggiungere milioni di persone in pochissimo tempo.

Mi chiedo.. e se anche Firefox avesse goduto di una tale spinta?

La gestione della cache di secondo livello con Terracotta

In questo articolo parliamo di persistenza distribuita dei dati, in particolare di cache di secondo livello.

Prendiamo un esempio ricorrente e supponiamo di avere una rete al cui interno girano più istanze di una stessa applicazione, le quali poggiano sulla stessa base di dati (sia essa su un unico nodo o anch’essa distribuita).
Ogni nodo con attiva l’applicazione di cui sopra disporrà presumibilmente di una propria cache (naturalmente parliamo di cache applicativa, non hardware) per evitare di fare spesso le chiamate più frequenti al database e quindi ottimizzare i tempi di risposta dell’applicativo alle richieste degli utenti. Chiameremo “cache di primo livello” questo tipo di capacità dell’applicazione.

Se pensiamo che su ogni nodo gira la stessa applicazione, viene da pensare che (statisticamente) le richieste di dati al database saranno mediamente le medesime per tutti i nodi della rete. Perchè allora non implementare un livello di persistenza dei dati secondario, che eviti ad un nodo di chiedere al database le informazioni che qualche altro nodo ha già chiesto prima?

Questo tipo di meccanismo viene definito clustering o cache di secondo livello.

Terracotta è un framework che si occupa di clustering, ossia di creare un substrato di memoria condivisa tra più nodi di una stessa rete, il tutto configurando poche righe di XML.
Terracotta supporta l’integrazione con molti framework, tra cui Spring, Hibernate, Ehcache, Lucene e Quartz.

 Scroll to top