[MYSQL] far lavorare N servizi sullo stesso PC in parallero

[mnkt]

ciao a tutti,

ho installato, su una macchina monoprocessore due MYSQL
server 4.0.20 (che chiamerò "A" e "B") su due dischi SCSI distinti.
Sia "A" che "B" hanno due database UGUALI contenenti una tabella di tipo MYISAM.
Il sistema operativo è una RedHat 9.B.

su ognuno di questi DBMS devo inserire dei record suddivisi in 2 tipologie che chiamo "1" e "2".

Se la tipologia è "1" salvo i dati su "A".
Se la tipologia è "2" salvo i dati su "B".

In questo modo voglio ottenere il seguente risultato:
se impiego "N" secondi per inserire la tipologia "1" su "A", e "N" secondi per inserire la tipologia "2" su "B", e lancio l'applicazione in multithreading, voglio che in "N" secondi inserisca sia i dati su "A" che "B".

:adhone:

Partendo dal presupposto che applicazione sia fatta sicuramente bene...
Ottengo che per inserire i dati su "A" e "B" mi occorrono "N" * 2 secondi. Questo dimostra che bensì le porte siano distinte, i dischi siano distinti, e avendo effettuato due installazioni TOTALMENTE distinte, i servizi non riescono a lavorare minimamente in parallero.



Ho notato, cercando di capire il perché, che il Server MultiDBMS, a livello di risorse, ha la CPU e la RAM poco impegnata, e aumentando le variabili di sistema di MYSQL non ottengo nessun miglioramento.

:master:

Ho anche notato, pur impostando sulle variabili di MYSQL la bellezza di 8-16-32 processi paralleri (thread_concurrency e roba simile), il servizio non riesce ad utilizzare + di 2 thread a servizio.



Esiste un qualcosa che impedisce al MySQL di saturare le risorse Hardware di cui dispongo?
Esiste, prima della compilazione, la possibilità di modificare degli header dei sorgenti di MYSQL al fine di lanciare un MYSQL + potente, anche se meno stabile (dato che la stabilità la garantisce l'applicazione)?

:master:

i DBMS in futuro diventeranno + di 2 e dovranno lavorare in parallero, e per una struttura del genere utilizzerò un Hardware adeguato, ma se non riesco a saturare questo non mi servirà ad un granché...

E' tutto...



Ciao grazie

[mnkt]

un'altra cosetta....

Bensì dichiari nelle variabili di sistema di MYSQL un key-buffer differente per ogni servizio, sembrerebbe che i 2 servizi lavorino sulla stessa area di memoria!!!
è possibile?
(Lancio i processi mysqld_safe con 2 utenti differenti)

[mnkt]

non è che qualcuno conosce quali sono i file sorgenti di MYSQL che gestiscono i thread concorrenti?
Almeno cercherei di modificare il codice!!

Grazie

[tia86]

visto che non ti ha risposto nessuno...
Non sarebbe meglio riprogettare l'intera applicazione?

i DBMS in futuro diventeranno + di 2 e dovranno lavorare in parallero, e per una struttura del genere utilizzerò un Hardware adeguato, ma se non riesco a saturare questo non mi servirà ad un granché...

Una cosa del genere non ha nessuna logica e diventa ingestibile (anzi, è già ingestibile)

Poi, ci saranno pure 3ad concorrenti e balle varie, ma la macchina è e resta monoprocessore quindi non può gestire 2 istanze MySQL contemporaneamente

[mnkt]

riprogettare l'applicazione.... fuori discussione.

Il problema sta nella mole dei dati, che è veramente enorme... talmente enorme che nessun DBMS al mondo, così come è progettato, riesce a gestire questa situazione in tempi accettabili...

un database... di qualsiasi marca possa essere..
non è capace di fare un simile lavoro...

il + veloce tuttavia è MYSQL con MYISAM,
INNODB è molto molto + lento.

Oracle, PostreSQL, SQL Server (il peggio), DB2 ed altri sono + lenti, in quanto maggiormente complessi.... e la complessità non mi occorre, dato che la gestisco con il mio demone...

L'unica soluzione è progettare un qualcosa come quello che sto facendo attualmente...

Inoltre, se la CPU non è al 100%, vuol dire che forse il problema attualmente non sta nel processore, ma nel MySQL che non lo satura (secondo me nella gestione dei thread di MySQL che a questi livelli è portato al limite delle sue capacità standard), indipendentemente da come possa configurarlo...

Il fatto è che MYSQL è l'unico che sta al limite, gli altri DBMS il limite lo oltrepassano in gran misura....

Alla fine mi metterò a spulciare il codice... o mi frugo
dai sigg. MySQL e melo faccio sistemare direttamente da loro..... mi sa che mi costerà meno....

Infine, se nessuno risponde, è solo perché una situazione del genere è rara, se non unica...
infatti spero in un fulmine a ciel sereno....

AIUTOOOOOOOOO.....

Ho anche ricompilato il MySQL mettendo tutti i parametri possibili immaginabili per ottimizzare la compilazione....



Perché non satura la CPU e non lavora in parallero?

Ciao



PS: Quando raggiungerò i risultati con l'Hardware sopraindicato, installerò il progetto su un "Server Missile" ovviamente... ma se non saturo una CPU con 770MB di RAM e dischi SCSI da 160Mb/s, che mene faccio di
N CPU con N GB di RAM e dischi SCSI che vanno alla velocità del suono?

[tia86]

una curiosità: di cosa si tratta?

[mnkt]

sono una serie di software, progettati in linguaggi differenti, a seconda delle necessità....

esiste principalmente un demone in ascolto su una porta TCP/IP che si interfaccia a delle cose che definisce l'utente amministratore.

Poi ci sono vari tipi di client (Multithreading pure questi) che si collegano al demone e fanno operazioni di I/O su di questo attraverso un protocollo di comunicazione proprietario
o dinamico configurabile da un utente amministratore (configurabile sul demone).

Poi c'è un server DB a parte che dovrà tenere i dati....

Il lavoro è scritto in J2SE, J2EE e C.

Ciao

[Thor82]

per quello che ne so io essendo comunque un processore unico deve eseguire le cose fondamentalmente "in serie", il multithreading non è propriamente in parallelo, pero' permette di risparmiare tempo in caso le aree di memoria che utilizzano siano le stesse.

in quel caso non credo che in ogni caso si sfruttino i benefici del multithreading, xke i processi sono 2 separati (A e B), quindi i thread di un processo non collaborano con i thread dell'altro, e credo che alla fine quello che lui faccia è fare prima un thread e poi l'altro (o comunque "un po'" e "un po'" fino a che non finiscono) in parole povere le cose che potrebbe risparmiare secondo me non le fa,
quindi o usi una sola istanza di mysql e fai gestire a lui la concorrenza (E quindi la scelta del disco in cui scrivere),pero' non so aiutarti sul come fare, oppure usi piu processori...

alla fine viene sempre eseguita UNA istruzione alla volta per processore...anche con il multi threading

[mnkt]

il fatto è che due servizi MySQL
scrivono su due dischi distinti....
ascoltano su due porte distinte...
e lavorano su aree di memoria distinte....

quindi sono due ambienti separati....

contando che ogni servizio (anche lavorando su un solo servizio) non riesce a lanciare + di due thread in fase di scrittura anche se in fase di configurazione ne ho messi 8-16-32, indipendentemente dalle connessioni effettuate,
e vedendo la CPU che non arriva neanche al 60%....

io credo che MySQL non riesca a lavorare a modo sui LinuxThreads.... sicuramente il cono di bottiglia, che c'è, dovrebbe essere nel momento della scrittura fisica dei dati sul disco SCSI, che dovrebbe causare un tempo di latenza sufficiente alla CPU per eseguire altri thread....

sennò al 100% ci dovrebbe arrivare, non ho altro che gira sul quel server....

E questo lavoro me lo fa anche lavorando su un solo servizio....

Nessuno di voi conosce i LinuxThreads, io ho visto che MYSQL lavora o sui LinuxThreads o sui P-MIT-Threads.....

forse dovrei provare a lavorare sui secondi.....

Mah....
Ciao

[mnkt]

ho provato ad installare i servizi mysql non sui dischi SCSI ma su un device RAMDISK....

stessa zuppa.... i tempi di elaborazione sono gli stessi, il problema non sta nei dischi e nemmeno nei controller,



ma nel MYSQL....




Ciao