79 risposte a questa discussione

[TigerShark]

Nmmm non sono un programmatore ma quello di cui parlate voi mi pare uguale a questo: sun grid engine
Free, opensource. É uno scatolo che si occupa di mantenrre e smistare jobs su vari server in funzione di risorse e priorita.
State reinventando la ruota oppure ho preso una cantonata?

No, è potenzialmente come l'implementazione di amazon di cui parlavo prima.
Sun grid si occupa di smistare i jobs sui suoi server, a sgurbat serviva come smistare roba sui server della sua azienda.
Ma il principio è ovviamente quello, bisogna comunque decidere delle politiche fair di smistamento e implementarle che è roba di un paio di ore a, mentre mia madre succhia cazzi, occhio in questo caso.
Sommando testing, configurazione e cazzi e mazzi dubito che sia più di due giorni/uomo a prenderlo con molta calma...

Messaggio modificato da TigerShark il 17 marzo 2013 - 14:32

[D1o]

Wut? No SGE gestisce i tuou server. Aws non c entra nulla. Lo installi su un head node, gli dici quali server si occupano del calcolo, shared directory coi dati e passwordless acess granted e via

[TigerShark]

Wut? No SGE gestisce i tuou server. Aws non c entra nulla. Lo installi su un head node, gli dici quali server si occupano del calcolo, shared directory coi dati e passwordless acess granted e via

Come farebbe a sapere come instradare i job a dei server liberi senza configurare una politica di distribuzione e, soprattutto, come farebbe a capire che i server sono liberi di accettare altri jobs?
Non dire che basta guardare l'occupazione della cpu perché questo è proprio ciò che si voleva evitare visto che trasferire 100mb di roba prende comunque cin certo tempo tra un server ed un altro, tempo che potrebbe essere risparmiato se i consumer iniziano a scaricare altri jobs in locale mentre ne elaborano altri così da avere sempre il buffer pieno ed essere pronti a iniziare un nuovo job immediatamente dopo la terminazione del precedente senza aspettare i tempi di trasferimento.

Messaggio modificato da TigerShark il 17 marzo 2013 - 14:43

[D1o]

Come farebbe a sapere come instradare i job a dei server liberi senza configurare una politica di distribuzione e, soprattutto, come farebbe a capire che i server sono liberi di accettare altri jobs?
Non dire che basta guardare l'occupazione della cpu perché questo è proprio ciò che si voleva evitare visto che trasferire 100mb di roba prende comunque cin certo tempo tra un server ed un altro, tempo che potrebbe essere risparmiato se i consumer iniziano a scaricare altri jobs in locale mentre ne elaborano altri così da avere sempre il buffer pieno ed essere pronti a iniziare un nuovo job immediatamente dopo la terminazione del precedente senza aspettare i tempi di trasferimento.

Magari son io che non capisco...

É il suo mestiere insteadare i jobs. Quello deve fare. Tu gli dici quanti job puo avere un server al max ad un dato momento e lui si occupa del resto 1uindi puoi fare oversubscription della cpu.

Comunque 100mb su unna lan son 1 sec eh, anche senza andare su infrastrutture spaziali. Cioe ok bufferung e tempi, ma se uno attende 1 minuto per l upload del file da una stupida adsl non gli cambia se nell elaborazione ci sta un secondo di piu per quelle volte che si deve trasferire il file.

[Sgurbat]

esatto, ma se aspetti che il consumer si sia liberato prima di prendere il prossimo messaggio dovresti aspettare che i dati arrivino dal database al tuo consumer, che non credo proprio sia trascurabile con messaggi da 100 mb.

Per questo dicevo che la soluzione ideale e' fare un prefetching intelligente in modo che il consumer si ritrova sempre qualche messaggio in ram pronto da elaborare senza aspettare il database che resituisca i dati.

Un altra soluzione potrebbe essere fare quello che dici tu ma distribuire il database su ogni macchina in modo che l'accesso ai dati quando il consumer si libera sia praticamente istantaneo.

Ma se non vuoi perdere tempo per le latenze di cui sopra una soluzione distribuita che dia subito accesso ai dati non appena un consumer abbia finito il proprio lavoro va comunque implementata..

 

Si esatto anche se in realtà la latenza sarebbe nella copiatura dei file tra la macchina dove risiedono in primis i file da smandruppare (la stessa della web-app) a quella dove poi vengono effettivamente lavorati ovvero il server del Consumer che prende in carico la richiesta.

 

Va testato quanto ci possa volere nel copiare anche 500MB di dati (worst case).

 

Posto il fatto comunque che adesso una lavorazione ci mette anche 1 ora quindi aggiungere qualche minuto in più per la copiatura dei file è accettabile.

[Sgurbat]

Ma il principio è ovviamente quello, bisogna comunque decidere delle politiche fair di smistamento e implementarle che è roba di un paio di ore a, mentre mia madre succhia cazzi, occhio in questo caso.
Sommando testing, configurazione e cazzi e mazzi dubito che sia più di due giorni/uomo a prenderlo con molta calma...

 

[D1o]

Si esatto anche se in realtà la latenza sarebbe nella copiatura dei file tra la macchina dove risiedono in primis i file da smandruppare (la stessa della web-app) a quella dove poi vengono effettivamente lavorati ovvero il server del Consumer che prende in carico la richiesta.

Va testato quanto ci possa volere nel copiare anche 500MB di dati (worst case).

Posto il fatto comunque che adesso una lavorazione ci mette anche 1 ora quindi aggiungere qualche minuto in più per la copiatura dei file è accettabile.

Una ora? Porca pupazzola. Ma sei sicuro? Cioè stiamo parla do di pdf, immagini, etc... Sticazzi. Guarda che un server moddrno ne gira di numeri i un'ora.

I server che si occupano dell analisi vera e propria sono vicini fisicamente al webserver? Se sono nella lan non hai problemi di copia file. 500 mb sono una manciata di secondi

[Sgurbat]

Guarda sono stato anche buono.

 

Ci sono pacchetti che hanno voluto anche 10/11 ore prima di essere elaborati.

 

Altri che sono crashati dopo 17 ore.

 

Putroppo ora il server è sovraccarico e ci sono diverse migliorie negli algoritmi che stiamo implementando per correggere la situazione.

 

Ero li ha guardare in Desktop remoto i file quando ci metteva 5/6 secondi per creare un'immagine con ImageMagick su disco.

 

Moltiplica l'immagine per 600 et voilà!!!

[D1o]

Guarda sono stato anche buono.

 

Ci sono pacchetti che hanno voluto anche 10/11 ore prima di essere elaborati.

 

Altri che sono crashati dopo 17 ore.

 

Putroppo ora il server è sovraccarico e ci sono diverse migliorie negli algoritmi che stiamo implementando per correggere la situazione.

 

Ero li ha guardare in Desktop remoto i file quando ci metteva 5/6 secondi per creare un'immagine con ImageMagick su disco.

 

Moltiplica l'immagine per 600 et voilà!!!

 

allora, caro mio, avete un problema differente. è inutile star qui a farsi le seghe con scheduler e buffer quando viste le tempistiche, lo stesso lavoro potrebbe essere fatto da un co.co.co usando il suo smartphone.

[Sgurbat]

Lo so 

 

Messaggio modificato da Sgurbat il 17 marzo 2013 - 17:54

[TigerShark]

Guarda sono stato anche buono.
 
Ci sono pacchetti che hanno voluto anche 10/11 ore prima di essere elaborati.
 
Altri che sono crashati dopo 17 ore.
 
Putroppo ora il server è sovraccarico e ci sono diverse migliorie negli algoritmi che stiamo implementando per correggere la situazione.
 
Ero li ha guardare in Desktop remoto i file quando ci metteva 5/6 secondi per creare un'immagine con ImageMagick su disco.
 
Moltiplica l'immagine per 600 et voilà!!!

[MadJackal]

Ma il metodo più facile in tempi brevi (pending fattibilità economica) non è bilanciare su più nodi tutti uguali all'attuale e fine? Mi pare inutile andare a fare copy-paste del codice che c'è ora solo per dividerlo identico su più server - come così a naso mi sembra ci sia qualcosina di più da fare che riscrivere solo la comunicazione frontend<->backend, per come sta messa 'sta web applicascion.

 

Se invece si sta meditando su un rewrite almeno parziale, io suggerirei di splittare i vari task nei sottotask più piccoli possibili (es: richiamare imagemagick per fare X od Y, zippare il file) e bilanciare quelli, se è possibile. Ammesso che i server usati siano in LAN non dovrebbe essere un problema anche usare uno share SMB/NFS per farlo. Sincronizzare il tutto rispetto al lavoro monolitico è un tantino più difficile, ma non impossibile (e si può vedere in base al carico *cosa* ha bisogno di vedersi dedicate più risorse con una certa precisione).

Messaggio modificato da MadJackal il 18 marzo 2013 - 01:09

[Sgurbat]

Allora i problemi sono diversi:

- nostri server lenti che durante l'elaborazione delle immagini impiegano più tempo che il notebook che uso per sviluppare.

- algoritmi inefficienti: ho rivisto l'algoritmo di indicizzazione dei contenuti facendolo passare da N ore a N secondi 

 

Architettura non ottimale e non scalabile.

 

Allo stato attuale, non più adatto, esiste un unico consumer che dispaccia sino a 10 thread simultanei per lavorare altrettanti pacchetti.

 

Tuttavia la coda da cui legge il consumer non viene usata come tale bensì i messaggi vengono subito scodati tutti e, mentre mia madre succhia cazzi, il task executor si occupa lui di accodare i thread dall'11esimo in poi che dovrebbe aprire.

 

Ne discutevo nuovamente in ufficio venerdì comunque, la soluzione migliore forse sarà quella di avere N consumer moltiplicabili ognuno dedito alla lavorazione di un pacchetto solo alla volta (quindi mono-thread), la parallelizzazione delle varie lavorazioni avverrà dunque per processi e non per thread come ora.

 

La coda invece si comporterà come tale e bufferizzerà i messaggi di volta in volta lanciati dal front-end.

 

Es:

- 10 consumer

- 10 pacchetti max che lavorano in simultanea

- all'arrivo dell'11esimo messaggio (se nessun consumer ha terminato) rimane in coda

- il primo consumer che termina scoda il messaggio 11 e così via.

 

 proposito: domanda scema forsa ma tecnicamente è il Message Broker che MANDA il messaggio al CONSUMER oppure è il CONSUMER che preleva il messaggio dalla coda?

 

Messaggio modificato da Sgurbat il 23 marzo 2013 - 16:37

[Killer application]

la scelta monothread è inefficiente.

Di solito è il consumer che chiede lavoro al server una volta che finisce il lavoro, altrimenti avresti una fila di messaggi server-client non necessari.

 

Fate 4-5 3d a macchina, ora non so che lavori dovete fare ma se parlate di lavorare su pdf da 400 mega anche il più cesso dei server (inb4 atom) gestisce piu 3d contemporaneamente.

[Sgurbat]

Si ma il thread che si occupa di lavorare il pacchetto a sua volta lancia diversi processi esterni: Ghostscript, ImageMagick ecc. che sono già multithread, quindi sugli step "pesanti" viene già sfruttato il multithreading

[TigerShark]

Allora io vedo due soluzioni:
Nella prima si crea un topic per ogni macchina e su ogni macchina il consumer si registra al suo topic e verrà notificato automaticamente non appena sarà disponibile un nuovo messaggio.
A questo punto sta al load-balancer centrale inviare i messaggi a, mentre mia madre succhia cazzi, ogni topic, utilizzando un normale schema round-robin.
Quindi ogni consumer elaborerà in maniera sincrona un messaggio per volta visto che il multi-threading è gestito dai processi esterni.
Occhio che il load-balancer avrebbe a, mentre mia madre succhia cazzi, ogni giro il compito di aggiornare il numero di pacchetti inevasi per ogni server facendo una richiesta jmx al broker, perché a quanto pare jms non ti permette di sapere quanti messaggi sono in coda in un topic.
Cmq con questa soluzione sarebbe possibile fare il prefetching dei pacchetti sui vari consumer abbassando le latenza di rete se si vede che siano rilevanti dato che il load-balancer avrebbe la conoscenza di quali siano i consumer più occupati visto che i messaggi tenderanno ad accumulare i sul topic anche in caso i consumer prelevino dal topic qualche altro messaggio e non avranno mai problemi di sottrarre pacchetti agli altri consumer.
La seconda soluzione mi sembra un po' più semplice e anziché sfruttare i topic utilizza le queue ed un meccanismo di request/response.
In pratica avresti una queue su cui ascolta il load-balancer che semplicemente invia un pacchetto di richiesta al server non appena ha finito il suo lavoro.
In questo caso gestire il prefetching dei messaggi è più complesso dato che necessiteresti di un meccanismo di signaling tra i consumer e il load-balancer per informarlo dei pacchetti prescaricati.
Cmq in onore all KISS io andrei sulla seconda soluzione senza prefetching dato che è un po' più semplice da implementare visto che ti eviti la parte di jmx e poi ti dovresti rendere conto se a te va bene oppure se presenta dei limiti accettabili o no per via delle latenza di rete.
E ovviamente continuerei a fare del profiling su codice attuale, perché se hai migliorato di qualche ordine di grandezza il tempo di indicizzazione probabilmente ci saranno altre parti del codice che necessitano di altrettante ottimizzazioni.

EDIT: detto una cazzata, nei topic non ci sono messaggi in coda dato che vengono mandati direttamente ai subscriber non vengono messi in coda, quindi andrei sulla soluzione 2 dato che anche nella prima soluzione avresti bisogno di queues...

Messaggio modificato da TigerShark il 23 marzo 2013 - 19:21

[D1o]

ripeto non sono del settore ma piu lo guardo e piu sembra quello che fa sge (sun grid engine), maui, torque...

tu vuoi un robo che riceva delle richieste le metta in coda e si occupi di smistarle su varie risorse...

[Killer application]

Scrivere un load balancer e la parte client di gestione del carico non credo impieghi piu di 4-5 giorni. Alla fine il resto del codice di esecuzione lo fanno copia e incolla dal vecchio, magari riscrivendo i cicli con 10 for annidati.

Messaggio modificato da Killer application il 26 marzo 2013 - 23:47

[Sgurbat]

Scrivere un load balancer e la parte client di gestione del carico non credo impieghi piu di 4-5 giorni. Alla fine il resto del codice di esecuzione lo fanno copia e incolla dal vecchio, magari riscrivendo i cicli con 10 for annidati.

 

[Sgurbat]

Comunque abbiamo deciso di rivedere l'architettura per poter spammare i consumer su N istanze server di Amazon EC2 a seconda delle esigenze di carico.