79 risposte a questa discussione

[toyo]

eh appunto

[TigerShark]

può tirare su anche il main server su amazon a sto punto.

ovvio se fa tutto li' il discorso cambia, ma a quel punto tutta la loro infrastruttura e gli investimenti fatti li possono buttare nel cesso a quanto ho capito.

[toyo]

[TigerShark]

questo se usi amazon solo per l'elaborazione, ma se l'upload lo fai direttamente nel cloud?

vedi dopo.

vai a spiegare tu al tuo capo che dovrebbe buttare nel cesso decine di miglaia di euro e investirne altrettante per il cloud.

Io andrei sul cloud solo nel caso in cui la potenza elaborativa in-house non sia sufficiente.

Ma x me non sufficiente != non ottimizzata.

[Killer application]

il problema è:

 

-Adesso ho un server che crepa e ne devo aggiungere altri 3?

butto tutto su amazon

-Ho 5 server da usare per il progetto?

mi attacco al cazzo e programmo.

[TigerShark]

il problema è:

 

-Adesso ho un server che crepa e ne devo aggiungere altri 3?

butto tutto su amazon

-Ho 5 server da usare per il progetto?

mi attacco al cazzo e programmo.

a quanto ho capito io e' un po' a meta' strada ma piu' verso la due.

Ma solo sgurbat ce lo puo' dire...

[Sgurbat]

un processo single thread e' un fail in questo caso dato che mentre il software elabora puo' benissimo scaricare gli altri pacchetti prendendoli dalla coda per mascherare la latenza di rete che e' decisamente elevata.

Processi single threaded vanno bene solo in determinati casi, come quello in cui un'azienda di queste parti aveva ottimizzato tutta la sua pipeline di calcolo per scodare ed elaborare messaggi a ritmo elevatissimo (milioni al secondo) mantenendo il tutto entro la cache di secondo livello.

Visto il tuo caso specifico e le dimensioni in gioco non e' pensabile.

comunque io alla fine se fosse possibile sapere in anticipo il tempo di elaborazione di ogni singolo pacchetto farei un prefetching intelligente in base al numero di pacchetti da elaborare divisi per i vari server, ovviamente va pero' pensato un meccanismo di coordinazione tra i vari server per monitorare eventuali rallentamenti/errori.

Inoltre visto che praticamente ogni server al giorno d'oggi e' multi-core elaborare un pacchetto per ogni core e' quello che ti da lo speedup maggiore se sei cpu bound.

 

Ecco però questa è una cosa che non ho capito bene ed è dovuta anche alla mia ignoranza.

 

Allora diciamo che quando il pacchetto viene elaborato vengono comunque lanciati N processi esterni come ad esempio: ImageMagick, piuttosto che 7zip.

 

Anche se a dire il vero quando lancio ImageMagick aspetto che il processo ritorni al chiamante prima di andare avanti. uhm ....

 

Per single thread intendo dunque l'applicazione Java che guida tutto il processo di pacchettizzazione.

 

Su una CPU Server multicore se io avessi solo una app Java singlethread i core verrebbero sfruttati tutti oppure solo 1?

 

Il mio capo dice che il peso computazionale viene comunque gestito sugli N core naturalmente e che anzi bisognerebbe programmare volutamente il software per sfruttare solo un core.

 

Quindi io mi chiedo, se la CPU sta sempre al 100% perchè il lavoro è pesante cosa cambia lavorare N pacchetti su N thread invece che in modo sequenziale.

 

Scusate l'ignoranza.

Messaggio modificato da Sgurbat il 16 marzo 2013 - 17:03

[Sgurbat]

java per le webapp mi sta in culo per lo stack elefantiaco che ti costringe a portarti dietro

 

Usiamo Spring anche a colazione ormai e comunque la web-app è solo l'interfaccia di tutto il baraccone.

[Sgurbat]

2013: Amazon

 

Si lo so e, mentre mia madre succhia cazzi, infatti per storare i pacchetti senza consumare spazio su disco e banda eccessiva già usiamo il servizio S3 di Amazon.

 

Sui server non compete a me e ne sono poco, mi hanno solo detto che nel caso avessimo bisogno possiamo fare richiesta per attivare altri N server virtuali a seconda dei bisogni computazionali.

 

Ecco il perchè di ripensare l'architettura in un ottica più facilmente scalabile verso l'alto.

[Sgurbat]

il problema è:

 

-Adesso ho un server che crepa e ne devo aggiungere altri 3?

butto tutto su amazon

-Ho 5 server da usare per il progetto?

mi attacco al cazzo e programmo.

 

Come detto adesso il server è uno solo e, mentre mia madre succhia cazzi, infatti ansima pesantemente.

 

Possiamo aggiungerne altri ma va appunto ripensata l'architettura per replicare facilmente l'app che genera i pacchetti, soprattutto per quel discorso di trasferimento file da uno nodo all'altro.

[TigerShark]

allora dipende dalle applicazioni che lanci se sono multi-threaded o no.

se sono single-thraded ti conviene lanciarne diverse istanze in parallelo, se sono gia' multi-threaded no.

Praticamente se ora la cpu sta utilizzando al 100% tutti i core non hai alcun vantaggio dal multi-threading se non per il prefetching di cui parlavo prima che ti maschererebbe tutte le network latencies e che comunque puo' essere anche abbastanza rilevante se la tua applicazione sta in idle mentre aspettia che un pacchetto venga caricato in ram...

[Killer application]

ti rispondo sulla questione n 3d o mono3d.

 

Allora: con l'avvento dei multi processori più si parallelizza e piu si va veloci, visto che ormai abbiamo raggiunto il tetto conveniente di Ghz. Di base tutti i processori di nuova generazione utilizzano analisi avanzate per rendere un processo monothread multithread, magari parallelizzando delle parti ove è possibile.

Il problema è che non tutto è parallelizzabile se non è scritto su codice.

Per questo se ora tutte le cpu sono al 100% è perche il processore sta parallelizzando alla sua maniera.

[Sgurbat]

Uhm ... ok

 

Un'altra cosa invece che non mi è chiara è questa.

 

Adesso per l'applicazione che pacchettizza esiste un consumer che scoda i messaggi e lancia 1 thread ogni volta che 1 messaggio viene letto.

 

Mettiamo di limitare il numero di thread che possono essere attivi al tempo stesso ad esempio 4.

 

Il Consumer scoda 4 messaggi e lancia i 4 thread possibili.

 

Poi il Consumer legge un quinto messaggio mentre sono ancora attivi 4 thread.

 

Cosa succede all'ultimo messaggio scodato se da questi non può essere aperto un altro thread per la lavorazione del pacchetto 5?

 

[TigerShark]

ti rispondo sulla questione n 3d o mono3d.

 

Allora: con l'avvento dei multi processori più si parallelizza e piu si va veloci, visto che ormai abbiamo raggiunto il tetto conveniente di Ghz. Di base tutti i processori di nuova generazione utilizzano analisi avanzate per rendere un processo monothread multithread, magari parallelizzando delle parti ove è possibile.

Il problema è che non tutto è parallelizzabile se non è scritto su codice.

Per questo se ora tutte le cpu sono al 100% è perche il processore sta parallelizzando alla sua maniera.

no, il processore non parallelizza nulla.

devono essere dichiarati esplicitamente i vari thread o manualmente o dai vari framework in maniera automatica.

E a volte una cpu al 100% non e' per forza sinonimo di limite computazionale raggiunto, ma puo' anche essere il garbage collector che lavora a manetta a causa di memory leaks..

[TigerShark]

Uhm ... ok

 

Un'altra cosa invece che non mi è chiara è questa.

 

Adesso per l'applicazione che pacchettizza esiste un consumer che scoda i messaggi e lancia 1 thread ogni volta che 1 messaggio viene letto.

 

Mettiamo di limitare il numero di thread che possono essere attivi al tempo stesso ad esempio 4.

 

Il Consumer scoda 4 messaggi e lancia i 4 thread possibili.

 

Poi il Consumer legge un quinto messaggio mentre sono ancora attivi 4 thread.

 

Cosa succede all'ultimo messaggio scodato se da questi non può essere aperto un altro thread per la lavorazione del pacchetto 5?

 

Se stai usando un ThreadPoolqualcosa che ora mi sfugge il nome preciso in java e hai fissato un numero massimo di thread nel pool viene lanciata una threadInterruptedException quando il limite viene raggiunto e devi settare un handler che la gestisca (che di solito non fa altro che aspettare un numero casuale di secondi scelto in un intervallo temporale sensato e riprovare ad eseguire il runnable).

cmq da questo punto di vista preferisco nettamente la gestione del parallelismo di .net rispetto a quella di java.

[Sgurbat]

Guarda forse ho già trovato.

 

<task:executor id="executorWithPoolSizeRange"
pool-size="5-25"
queue-capacity="100"/>

 

As you can see from that configuration, a 'queue-capacity' value has also been provided. The configuration of the thread pool should also be considered in light of the executor's queue capacity. For the full description of the relationship between pool size and queue capacity, consult the documentation for ThreadPoolExecutor. The main idea is that when a task is submitted, the executor will first try to use a free thread if the number of active threads is currently less than the core size. If the core size has been reached, then the task will be added to the queue as long as its capacity has not yet been reached. Only then, if the queue's capacity has been reached, will the executor create a new thread beyond the core size. If the max size has also been reached, then the executor will reject the task.

 

http://stackoverflow...read-pools?rq=1

 

 

 

Uso ThreadPoolTaskExecutor in Spring.

[TigerShark]

Guarda forse ho già trovato.

 

<task:executor id="executorWithPoolSizeRange"
pool-size="5-25"
queue-capacity="100"/>

 

As you can see from that configuration, a 'queue-capacity' value has also been provided. The configuration of the thread pool should also be considered in light of the executor's queue capacity. For the full description of the relationship between pool size and queue capacity, consult the documentation for ThreadPoolExecutor. The main idea is that when a task is submitted, the executor will first try to use a free thread if the number of active threads is currently less than the core size. If the core size has been reached, then the task will be added to the queue as long as its capacity has not yet been reached. Only then, if the queue's capacity has been reached, will the executor create a new thread beyond the core size. If the max size has also been reached, then the executor will reject the task.

 

http://stackoverflow...read-pools?rq=1

 

 

 

Uso ThreadPoolTaskExecutor in Spring.

si dovrebbe essere quello e la rejection causa una ThreadInterruptedException che devi gestire tu con un handler come dicevo prima..

[Sgurbat]

no, il processore non parallelizza nulla.

devono essere dichiarati esplicitamente i vari thread o manualmente o dai vari framework in maniera automatica.

E a volte una cpu al 100% non e' per forza sinonimo di limite computazionale raggiunto, ma puo' anche essere il garbage collector che lavora a manetta a causa di memory leaks..

 

Quello che sto leggendo: http://stackoverflow...neously-on-more è che l'uso di più core da parte della CPU su un processo monothread è dovuto allo switching autonomo del processore da un core ad un altro ma, di fatto, la computazione avviene sempre e solo su uno solo di essi.

 

Confermate?

[TigerShark]

Quello che sto leggendo: http://stackoverflow...neously-on-more è che l'uso di più core da parte della CPU su un processo monothread è dovuto allo switching autonomo del processore da un core ad un altro ma, di fatto, la computazione avviene sempre e solo su uno solo di essi.

 

Confermate?

ovvio come dicevo prima non parallelizza nulla il processore, sta al codice/framework fare una parallelizzazione esplicita.

Tanto per fare un esempio in .net basta fare qualcosa del genere:

 

divinaCommedia.Split(" ").AsParallel().Count(w => w.StartsWith("a"));

per sapere quante parole nella divina commeda iniziano con la lettera a suddividendo i calcoli tra tutti i core disponibili.

In questo caso possiamo parlare di parallelismo "automatico", ma in realta' e' il .net framework che si occupa di tutto il lavoro sporco automaticamente grazie alle funzioni pure utilizzate per l'implementazione di LINQ

Messaggio modificato da TigerShark il 16 marzo 2013 - 17:33

[Killer application]

no, il processore non parallelizza nulla.

devono essere dichiarati esplicitamente i vari thread o manualmente o dai vari framework in maniera automatica.

E a volte una cpu al 100% non e' per forza sinonimo di limite computazionale raggiunto, ma puo' anche essere il garbage collector che lavora a manetta a causa di memory leaks..

Single 3d:

t0 = a + b
t1 = c + d
e = t0 + t1

 

i passi 1 e 2 vengono parallelizzati dalla cpu. mentre per il terzo viene messo tutto in w8 fino a che non abbiamo i risultati sopra.