Scelta server dedicato per portale con db da 2 milioni di righe

[bea90]

Salve a tutti e scusate per la mia intromissione ma necessito di un chiarimento dai guru del settore:P
Dunque attualmente possiedo un server doppio processore harpertown 5450 per un totale di 8 core e 6 gb di ram che purtroppo non riesce piu a sostenere il carico di lavoro (lato backend ossia mysql) portando le cpu al 200% -.-'
Ho quindi deciso di munirmi di una nuova soluzione quadriprocessore quadricore e spulciando in rete mi son resa conto che dai tempi in cui acquistai il server le cose son cambiate. All'epoca (solo due anni fa lol) si guardava la potenza del processore e la cache ma adesso vedo che le ultime cpu han davvero molti meno GHz e qui casca l'asinella ossia io -.-'
Non è meglio un 3 GHz anche se datato come ad esempio i miei Harpertown piuttosto che un moderno xeon 7310 da 1,6 GHz? Insomma non mi ci raccapezzo mica.
Per le mie necessita in particolare calcolando che del consumo energetico mi frega pochino quale è il processore più adatto ad un server (1 solo portale su ma immenso con tabelle di mysql da 2milioni di entries e con locks delle tabelle pressochè onnipresenti per via degli utenti che apportano modifiche e update alle proprie rows).
Help me pls

[Alex]

sei su engine innodb spero ...

[bea90]

sei su engine innodb spero ...

Si per le tabelle critiche l'engine utilizzato è l'innodb mentre per quelle marginali il vecchio (e obsoleto ma anche più veloce nelle count) myisam.
Daiiiiiiiiii.....aiutatemi a capire come ragionare sui processori che mi servono :P

[Alex]

mi fai vedere il my.cnf

[bea90]

dovrei andare a prelevare i settaggi tramite ssh visto che non uso phpmyadmin (insomma non apporto modifiche direttamente se non tramite il mio pannello di controllo per la gestione degli utenti). Ad ogni modo i soliti settaggi basati sulla quantità di memoria a disposizione. Difatti i settaggi furono creati proprio prendendo idea dagli articoli sul tuning di mysql.
se non erro
query cache size = 512M

temp table size = 256M

key buffer size = 512M

innodb log buffer size = 512M

innodb buffer pool size = 512M

[bejelith]

Questa è solo una piccola parte delle configurazioni, immagino per il resto usi le impostazioni di default... cmq dal poco che si vede sembra una configurazione un pò improvvisata (o risalente a quando avevi meno tuple).

Per quanto riguarda il server, ti consiglio di non muovere su un server più potente; è piu saggio prendere una seconda macchina e fare una replica, oppure, pensare di installare una soluzione mysql cluster (scaling-out)

[Shazan]

Se il problema è il lock delle tabelle, non risolvi tanto passando ad hardware più potente, bisogna prima vedere di ridurre il tempo ed il numero di questi lock. In genere, non è tanto un problema di CPU quanto di velocità di scrittura dei dischi o di struttura del db stesso.

Penso tu debba verificare la struttura del database e vedere se puoi spezzettare queste tabelle in più tabelle più piccole. Ho visto fare questa operazione in un portale di una certa dimensione, e le performance sono *decuplicate* sullo stesso hardware.

[bea90]

Si in effetti avete ragione. La configurazione del server mysql fu fatta all'epoca quando il db era ancora in stato "larvale" e aveva solo 30 tabelle. Poi con il tempo è cresciuto in modo spropositato fino ad arrivare ad avere 168 tabelle e 30 delle quali con oltre 2milioni di records ciascuna inseriti dalla community. In media sono tra i 9e i 10 milioni di query al giorno (questo dato è datato in realtà son molte di più temo) molte delle quali sono COUNT e UPDATE. Per ridurre il carico di lavoro utlizziamo anche il framework di Smarty (altrimenti il server sarebbe esploso ben presto).
Mumble mumble..... mi sorge l'atroce sospetto leggendo le risposte precedenti che non risolverei granchè con una macchina più potente e la cosa più malvagia è che non so come porvi rimedio. Intervenire sugli engine con database del genere è arduo. Myisam è veloce nelle count e nei select ma fa il lock dell'intera tabella mentre innodb è lento come una tartaruga nelle count e nelle select (e pure negli update -.-) ma fa il lock delle singole rows e non dell'intera tabella riducendo esponenzialmente la coda delle query in attesa. Tutte le tabelle hanno milioni di select e tutte le query hanno svariati milioni di update. Non so come raccapezzarmi -.-' -.-' La velocità nell'esecuzione delle query a scapito dei locks offerto da myisam o la lentezza ma con il vantaggio di code ridottissime e salvaguardia dell'integrità dei dati offerto dalle innodb?
Aiutatemiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii :-)

P.S: so che esula dalla discussione ma...... la nostra macchina ha due HD. il primario con la partizione /home e il secondario con partizioni /home2 e /backup che utilizziamo appunto per i backups. Siamo arrivati ad avere il primo HD con il 90% della partizione /home full per cui era nostra intenzione sfruttare la /home2 del secondo HD non in RAID (sono taglie differenti il primo 250 Gb mentre il secondo 1 TB). So che Whm lo vede in automatico e che aggiungerà conseguentemente i nuovi accounts sulla /home con più spazio ma noi abbiamo un solo account (il primario essendo un solo ed unico portale) per cui la nostra domanda è: ci sta la possibilità senza resettare HD di utilizzare la /home2 come una estenzione della /home originaria? Help me anche su questo pls :-))))

[Deflagrator]

P.S: so che esula dalla discussione ma...... la nostra macchina ha due HD. il primario con la partizione /home e il secondario con partizioni /home2 e /backup che utilizziamo appunto per i backups. Siamo arrivati ad avere il primo HD con il 90% della partizione /home full per cui era nostra intenzione sfruttare la /home2 del secondo HD non in RAID (sono taglie differenti il primo 250 Gb mentre il secondo 1 TB). So che Whm lo vede in automatico e che aggiungerà conseguentemente i nuovi accounts sulla /home con più spazio ma noi abbiamo un solo account (il primario essendo un solo ed unico portale) per cui la nostra domanda è: ci sta la possibilità senza resettare HD di utilizzare la /home2 come una estenzione della /home originaria? Help me anche su questo pls :-))))

Hai solo 2 HD, per giunta NON in Raid? Nei server database i dischi sono importantissimi, come ti hanno detto, prima di provare a cambiare processore, forse è meglio che provi a passare a dischi più performanti, come degli SSD, in RAID...

[bea90]

Ehhhhhhh all'epoca le cose erano diverse:P
Adesso ci troviamo di fronte a questo nuovo problema ma mi è stato detto che per installare un sistema raid in array bisognerebbe formattare e capirai....non è possibile per noi nè accettabile come soluzione. Quindi fin quando non risolveremo (magari prendendo tutte le opzioni e scelte offerte in questo topic ossia macchina più performante+ miglioramento della struttura del db (nei limiti del possibile)) dobbiamo arrangiarci con quel che abbiamo:-( Ripeto non so se è vero e il mio inglese è macchiavellico ma per installare un Raid array bisogna procedere a reinstallazione del SO e conseguente reset di tutti i dati delle partizioni.

[usu]

Si in effetti avete ragione. La configurazione del server mysql fu fatta all'epoca quando il db era ancora in stato "larvale" e aveva solo 30 tabelle. Poi con il tempo è cresciuto in modo spropositato fino ad arrivare ad avere 168 tabelle e 30 delle quali con oltre 2milioni di records ciascuna inseriti dalla community. In media sono tra i 9e i 10 milioni di query al giorno (questo dato è datato in realtà son molte di più temo) molte delle quali sono COUNT e UPDATE. Per ridurre il carico di lavoro utlizziamo anche il framework di Smarty (altrimenti il server sarebbe esploso ben presto).
Mumble mumble..... mi sorge l'atroce sospetto leggendo le risposte precedenti che non risolverei granchè con una macchina più potente e la cosa più malvagia è che non so come porvi rimedio. Intervenire sugli engine con database del genere è arduo. Myisam è veloce nelle count e nei select ma fa il lock dell'intera tabella mentre innodb è lento come una tartaruga nelle count e nelle select (e pure negli update -.-) ma fa il lock delle singole rows e non dell'intera tabella riducendo esponenzialmente la coda delle query in attesa. Tutte le tabelle hanno milioni di select e tutte le query hanno svariati milioni di update. Non so come raccapezzarmi -.-' -.-' La velocità nell'esecuzione delle query a scapito dei locks offerto da myisam o la lentezza ma con il vantaggio di code ridottissime e salvaguardia dell'integrità dei dati offerto dalle innodb?
Aiutatemiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii :-)

Dall'uscita di MySQL 5.5 non è più vero che le prestazioni di myisam sono di molto superiori a quelle di innodb, ti consiglio la lettura di questo whitepaper: MySQL :: MySQL 5.5: Storage Engine Performance Benchmark for MyISAM and InnoDB

Se hai abbastanza RAM per far stare almeno il 75% dell'intero database nell'innodb buffer pool il mio consiglio è quello di installare Percona Server 5.5 che migliora ulteriormente le prestazioni di MySQL standard, passare tutte le tabelle ad innodb e vedere come va. Certo che poi sarebbe comunque meglio rivedere tutta l'infrastruttura a partire dai dischi.

[bea90]

Ma...scusate l'ignoranza immensa della sottoscritta....ma han davvero cosi tanta importanza i dischi? Insomma....voi intendete la velocita di rotazione?
Non dimenticate che io di server non ne capisco una cippola per cui immaginate di spiegare ad una persona rimbambita:P
P.S: mi leggo istant il link che hai postato grazie:P ma indipendentemente dall'amore che si puo provare per myisam o innodb bisogna considerare la velocità di esecuzione delle query. Ci sono oltre 80k utenti al giorno. Ogni pagina ha centinaia di query. Non posso permettermi il "lusso" di bloccare una tabella con myisam ma nemmeno posso permettermi il lusso di avere query di tipo COUNT o SELECT lentissime con innodb. Insomma un vicolo cieco.

[bea90]

doppio mumble....leggevo adesso alcune discussioni dell'utente seflow che mi è piaciuto molto e quindi ho dato una sbirciatina al portale. Come è possibile offrire

• Specifiche Server
  Mensile
• Supermicro Dual Quad-Xeon5620
  € 359.00
• Memoria RAM
  12288 MB
• Primo Hard-Disk
  1000 GB
• Secondo Hard-Disk
  1000 GB
• Terzo Hard-Disk
  No GB
• Quarto Hard-Disk
  No GB
• RAID
  Raid1_9650
• Assistenza
  BBMComplete
• Sistema Operativo
  CentOS5_64
• Pannello Controllo
  cpanel
• Traffico
  5000GB
• Uplink
  100 Mbps
• Indirizzi IP
  5
• Blocco IPv6
  0
• Backup
  500GB R1Soft
• Firewall
  fw software
• Preferenza Datacenter
  DC2

ad un prezzo così basso? Cioè mi spiego...per l'acquisto del nuovo server ne ho visti tanti che allettavano ma poi spulciando le "righe in piccolo" si vedeva che ti davano 1Mbps -.-' oppure 10 ma garantiti al 30% (doppio sic!). Noi abbiamo in media circa 800 Gb di banda consumata al mese e 300 connessioni concorrenti per cui con 1 mbps ci si fa ben poco. I 100 Mbps son reali? cioè son garantiti? Sto seriamente prendendo in considerazione l'idea di migrare dalla ex ThePlanet (ora Softlayer si inglesi ma con servizio assistenza incredibilmente efficace sin dai tempi della ThePlanet con cui ho servers dal 2005).
Mi scusi Seflow se posto direttamente sul forum pur sapendo che posso contattarLa direttamente tramite PM o sulla chat del portale (semplice e molto intuitivo) ma è per capire meglio cio di cui ho realmente bisogno. Ricordi che sono incapace al massimo con i servers e l'assistenza per me è tutto. Anzi a dirla tutta io contatto il servizio assistenza per qualsiasi piccola cosa (anche a pagamento ovvio) fosse anche solo per configurare il log rotation. E' tutto reale con gli uplink,la banda e altro o ci sta qualche piccola clausola da sapere?

[bejelith]

se le count le fai 'count(*)' saranno lente qualsiasi cosa fai.

Il partizionamento funziona solo se la chiave è un intero e le select sono basate su quella chiave. Ovviamente si perdono i benefici qualora la select accede a piu partizioni.

La velocità dei dischi conta relativamente a quanto riesci a tenere in cache (questo dipende nn solo dalla ram ma da come configuri mysql), faresti buona cosa a cambiare algoritmo di locking.

Altra cosa che puoi fare è spostare le tabelle onerose su un pool di dischi a loro dedicato.

[bea90]

ehm...si viene usato il comando COUNT(indice) from ..... WHERE ..... :P
ma mo hai parlato di algoritmi di locking che manco so che sono:-) Comunque si gli indici "importanti" sono numerici e effettivamente ho gia iniziato la stesura della logica in base alla quale aggiungere una nuova tabella basata sugli indici di quella primaria che sgraverebbe parzialmente il lavoro sulle tabelle più imponenti. Ma si tratta comunque di un palliativo in quanto si ridurrebbe solo del 5% la quantità di locks. Spostare le singole tabelle su HD dedicati? o.o
Mica so come si faccia :-(