Discussione: Dimensione "massima" consigliata del DB

Originariamente Scritto da y2ksw

Le dimensioni normali massime sono 2 GB per ogni tabella, ma può essere estesa, usando delle opzioni particolati. La velocità dipende dalla velocità dei dischi e dal numero di tabelle nel database, meno da altri fattori.

Consiglio di esportare gli allegati su file - crea meno problemi ed è più rapido all'accesso.

Io ho una tabella (post) da 15GB.. e funziona senza nessun tricks..

Speriamo sia l'ultimo che posti-.-

Originariamente Scritto da jeff_92

Io ho una tabella (post) da 15GB.. e funziona senza nessun tricks..

Ciao, mi riaggancio a questo vecchio post perche' ho grossi problemi ogni qual volta faccio operazioni sul database mysql e non riesco a schiodare la cosa.

Premetto che VBulletin e' hostato su un server virtuale (vmware) gestito con Virtualmin e Webmin con le seguenti caratteristiche:

1024 mega di ram
900 mega swap
18,50 giga di spazio disco
OS: CentOS Linux 5.2
Kernel and CPU Linux 2.6.18-92.1.10.el5 on i686
ecc ecc

il database attualmente ha 402 tabelle tra Joomla e vBulletin, gli allegati che sono circa 4 giga risiedono su file system e la tabella piu' grossa del database e' la tabella post con 267.000 record = 190 mega circa.

Il server virtuale e' settato "credo" bene, cosi' come mi pare giusto il file di cfg di mysql, il problema e' che ogni qual volta faccio operazioni sul database quali ad esempio il controllo delle tabelle e la loro riparazione, oppure il backup del database o altro che va a "stressare" un po' mysql, il server inizia a swappare (dopo avere saturato il 100% della CPU che ricordo essere di un giga) e alla fine si pianta completamente costringendoci a dover fare il reboot del sistema.

Il numero di accessi contemporanei al server e' mediamente di circa 60/70 utenti (da 10 a 150 nelle ore di punta) e i problemi sopra elencati li ho sempre quando ho molti utenti collegati.

Quando pero' leggo post come il tuo in cui affermi di riuscire a gestire una tabella di 15 giga casco dalle nuvole e non riesco a spiegarmi quale sia allora il mio problema.

Pensa che avevo temporaneamente per motivi vari dovuto riportare gli allegati nel database (4 giga) e ti assicuro che se non avessimo fatto l'operazione al contario con l'aiuto del tecnico della farm che, mentre andava avanti l'operazione monitorava lo swap e chiudeva man mano i servizi non indispensabili, non sarei mai riuscito a riportare tutti e 4 i giga nel file system... durante l'operazione nonostante l'http chiuso cosi' come tutti i demoni FTP , POP ecc. ecc. veniva utilizzato il 100% di cpu e quasi 900 mega di swap e TUTTO da mysql che cercava di gestire quella cavolo di tabella degli allegati grossa 4 giga!

Con gli amministratori del server abbiamo provato anche a cambiare macchina ma senza alcun risultato apprezzabile.

Loro seguitano a dire che il problema e' il numero enorme di sessioni che in certi momenti apre mysql le quali "saturano" la cpu e costringono linux a swappare sempre di piu' con la conseguenza del blocco del sistema.

Hai, o avete idea di come risolvere il problema?

Io credo che un database di 280 mega alla fine non sia affatto esagerato e allo stesso tempo ritengo che anche un sistema linux con 1 giga di ram non dovrebbe essere messo in crisi cosi' facilmente... che ne pensate?
Cosa posso controllare?

Grazie mille

Originariamente Scritto da y2ksw

Il problema è che probabilmente PHP e MySQL siano configurati a usare tanta memoria che però in pratica non c'è.
Il problema inerente i tanti utenti proverei a risolvere prima dal lato PHP, poi da MySQL. Prova ad assegnare meno memoria disponibile per gli script, e di conseguenza ridurre la dimensione massima dei dati POST e degli allegati (max 2/3 della memoria massima disponibile, meglio 1/2).

A livello MySQL, ridurrei gradualmente l'utilizzo della RAM e cercherei di operare più sul disco. Dovresti controllare nelle ore di punta l'utilizzo della memoria nelle variabili MySQL e aggiustare i valori al reale consumo, non a quello ipotetico oppure ritenuto ottimale. In particolare, il Key Buffer non deve essere grande quanto dichiarato nel manuale MySQL, ma di regola sono sufficienti 16 MB. E il numero delle connessioni non deve essere un'esagerazione se MySQL risponde velocemente. Invece la cache delle query deve essere alta, per ospitare il maggior numero di query ricorrenti.

In altre parole, devi evitare che si swappano Apache, PHP o MySQL su disco, ad ogni costo. Meglio che MySQL utilizza file temporanei che ogni altra soluzione

Iniziando con la cfg di mysql, ecco la mia attuale, da quanto capisco ha dei valori troppo alti giusto?

Codice:

# skip-innodb
old_passwords=1
query_cache_limit=4M
query_cache_size=64M
log-slow-queries=/var/log/mysqld_slow.log
long_query_time=5
max_connections=512
table_cache=512

thread_cache=100
key_buffer=32M
sort_buffer_size=1M

read_buffer_size=1M
read_rnd_buffer_size=768K

join_buffer_size=8M
set-variable = max_connections=400
set-variable = key_buffer=150
ft_min_word_len=3



tmp_table_size = 32M

query_cache_type=1
interactive_timeout=100
wait_timeout=50
connect_timeout=10
join_buffer=1M
myisam_sort_buffer_size=64M
max_allowed_packet=16M



[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid