Una cache pazzesca di agenti di prova

 

Buona giornata a tutti!

Mi sono imbattuto nel seguente problema:

Avere 32 processori logici nel sistema - usando rispettivamente 32 agenti per l'ottimizzazione (+ altri 40 remoti)

Ogni agente costruisce piuttosto rapidamente una cache di dimensioni totalmente inadeguate 2-2,6GB, che in totale è più di 70GB al giorno! La cache non si cancella, e cresce costantemente. L'unica cosa che ha fermato la follia è stata l'esaurimento dello spazio su disco. Dopo di che gli agenti smettono stupidamente di lavorare.

Le domande sono le seguenti:

Qualcuno ha affrontato un tale problema? Come affrontarlo? Cosa può causare dimensioni della cache così grandi?

Scritto una richiesta a servicedesk, finora silenzio.

 
P.S.: il terminale è 64x bit, ultima versione
 
alrane:

Buona giornata a tutti voi!

Mi sono imbattuto nel seguente problema:

Avere 32 processori logici nel sistema - usando rispettivamente 32 agenti per l'ottimizzazione (+ altri 40 remoti)

Ogni agente costruisce piuttosto rapidamente una cache di dimensioni completamente inadeguate 2-2,6GB, che in totale ammontano a più di 70GB in un giorno! La cache stessa non viene cancellata, e cresce costantemente. L'unica cosa che ha fermato questa follia è stata l'esaurimento dello spazio su disco. Dopo di che gli agenti smettono stupidamente di lavorare.

Le domande sono le seguenti:

Qualcuno ha affrontato un tale problema? Come affrontarlo? Cosa può causare tali dimensioni della cache?

Scritto una richiesta a servicedesk, finora silenzio.

La dimensione della cache dipende dal numero di tick generati (cioè più lungo è il periodo di prova e il numero di caratteri, più grande è la cache).

Nel tuo caso, probabilmente il problema principale è il numero di agenti, perché ora (build 1495) ogni agente usa la propria istanza di cache!

Lo spazio della cache viene liberato dopo 5 minuti di inattività dell'agente.

Inoltre, la cronologia dei tick per gli agenti tester può prendere spazio se sono usati nel cloud (anche la cronologia dei tick alla fine viene ripulita, ma conta in giorni o settimane).

A proposito, gli agenti cloud e gli agenti locali sono diversi. Nell'immagine gli agenti cloud sullo stesso computer sono aggiunti alla farm della rete locale - Voilà! Abbiamo ottenuto 8 agenti di prova su un processore con due core e quattro processori logici (se vale la pena farlo è un'altra questione).

 
Ceneri:

В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!

Qui sta (che gli sviluppatori mi perdonino) la stupidità dell'organizzazione dei tester, quando il numero di agenti si trasforma da un vantaggio in un problema.

Il tester non ha alcuna impostazione, quindi è impossibile ottimizzarlo per il vostro sistema. Nell'output otteniamo un abuso del disco rigido con un enorme numero di piccoli file riscritti (fino a 800GB/giorno su SSD 120GB a 32 agenti nel sistema), e ciò che è divertente, i core in quel momento sono inattivi.

Ho parzialmente risolto il problema facendo funzionare 4 diversi tester in modalità portatile su unità fisiche diverse. Compreso il RAM-diske, poiché il tester lascia una grande quantità di memoria incustodita.

A proposito, eseguire un agente con cache su un disco ram, spesso aumenta le prestazioni fino a 3 volte! Il che indica ancora una volta il modo disgustoso in cui è organizzato il tester.

Ceneri:

A proposito, gli agenti cloud e gli agenti locali sono diversi. Nell'immagine gli agenti cloud sullo stesso computer sono aggiunti alla farm della rete locale - Voilà! Abbiamo ottenuto 8 agenti di prova su una CPU con due core e quattro processori logici (se si debba fare così è un'altra questione).

Non dovreste farlo per la stessa ragione - i core saranno anche in attesa di dati dal disco, ma già in doppio volume. Penso che questo non farà altro che diminuire le prestazioni.
 
alrane:
Questa è la stupidità (perdonatemi gli sviluppatori) dell'organizzazione dei tester, dove il numero di agenti si trasforma da un vantaggio in un problema.

Il tester non ha alcuna impostazione, quindi è impossibile ottimizzarlo per il vostro sistema. Nell'output otteniamo un abuso del disco rigido con un enorme numero di piccoli file sovrascritti (fino a 800GB/giorno su SSD 120GB a 32 agenti nel sistema), e ciò che è divertente, i core rimangono inattivi durante questo tempo.

...
A proposito, eseguire un agente con una cache su un frame-disk, spesso aumenta le prestazioni fino a 3 volte! Il che indica ancora una volta la disgustosa organizzazione del lavoro del tester.

...

Scrivere al Service Desk.

 
Ho già scritto prima. È inutile.
 

Dover leggere diversi gigabyte di dati da un disco è "un'organizzazione disgustosa"? Anche solo per leggere 1gb di dati da un ssd a una velocità media di 200mbps ci vorranno 5 secondi. E se ci sono 4-32 agenti là fuori?

Si pensa solo al lato tecnico del compito. Niente è gratis e nessuno moltiplica i requisiti tecnici per zero.

La soluzione tecnica e il livello di ottimizzazione dell'agente è sorprendente - ci abbiamo messo una quantità selvaggia di lavoro e abbiamo grattato via millisecondi da tutti i processi. Non dimenticate i volumi di dati, mettete più RAM, mettete degli ssd più grandi, mettete dei dischi a telaio e tutto sarà accelerato.

I prezzi di tutte queste cose sono già ragionevoli, ma la classe e il volume da risolvere richiedono un approccio serio.

 
alrane:

Ogni agente sta rapidamente costruendo una cache di una dimensione completamente inadeguata, 2-2,6GB, per un totale di oltre 70GB in un giorno! La cache non si cancella, e cresce costantemente. L'unica cosa che ha fermato questa follia è stata l'esaurimento dello spazio su disco. Dopo di che gli agenti smettono stupidamente di lavorare.

Cosa c'è da cestinare in questi volumi?!
 
fxsaber:
Cosa c'è da memorizzare in questi volumi?
Di solito, i commercianti preferiscono guardare la dimensione della cartella senza accorgersi che ci sono decine di gigabyte di registri estesi generati personalmente.

Tutto è a posto con le cache di dati. Lo teniamo su disco e lo conserviamo in memoria in attesa delle repliche. Notate quanto sia più veloce il ricalcolo sullo stesso agente (prendete un agente e un'esecuzione per dimostrare l'effetto).



Un'altra cosa: lavoriamo con molta parsimonia con i dischi. Scriviamo in grandi multipli e comprendiamo chiaramente le peculiarità dei dischi ssd.
 
Renat Fatkhullin:
I trader di solito preferiscono controllare la dimensione della cartella senza accorgersi che ci sono circa 10 Gbyte di grandi log generati personalmente.
Stavamo parlando di gigabyte di cache per agente locale. Ancora non capisco cosa può essere conservato lì in tali quantità?
alrane:
Ho parzialmente risolto il problema facendo girare 4 diversi tester in modalità portatile su diversi dischi fisici. Compreso il RAM-diske, dato che il tester lascia una grande quantità di memoria incustodita.

A proposito, eseguire un agente con cache su un disco ram, spesso aumenta le prestazioni fino a 3 volte! Il che indica ancora una volta la disgustosa organizzazione del tester.

Per quale motivo l'organizzazione RAM-disco aumenta le prestazioni di molte volte, se il livello di ottimizzazione degli agenti è "meraviglioso"? A mio parere, domande logiche, anche se sgradevoli.

ZS Dobbiamo procurarci un software che cancelli i registri degli agenti. Sono inutili in tali quantità. Il Print+Alert dovrebbe essere disabilitato dall'utente nel codice durante le ottimizzazioni.

 

fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?

Invece di fare dichiarazioni da forum, date un'occhiata voi stessi.

Che motivo c'è di organizzare RAMdisk per moltiplicare le prestazioni se il livello di ottimizzazione degli agenti è "incredibile"? A mio parere, domande logiche, anche se sgradevoli.

Perché non abbiamo il diritto di mangiare il 100% della RAM per la cache e tenerla all'infinito. Ma se una persona si è creata una cornice di disco da 32-64gb, vi ha spostato gli agenti e ha iniziato a lavorare attivamente con il disco, allora, sì, è possibile ottenere un'accelerazione delle operazioni su disco di molte volte.

Ma specificamente le operazioni su disco, non "tutte in una volta per un fattore N".

Che il tester gestisca i dati in modo sorprendente è evidente a chiunque lo usi in modalità costante e ottiene molti benefici dalle cache del tester riscaldate in attesa di nuove corse in background. La sperimentazione è di solito decine o centinaia di corse di tester con una costante ricompilazione del codice.

HH Abbiamo bisogno di un qualche tipo di software per cancellare i log degli agenti. Non ne abbiamo bisogno in quantità così grandi. E Print+Alert dovrebbe essere disabilitato dall'utente nel codice durante le ottimizzazioni.

I registri del tester vengono cancellati automaticamente. Chi usa il tester lo sa. E la cache del tester viene cancellata dal terminale non appena capisce che il tester non viene più utilizzato.

Il topikstarter ha iniziato il thread in modalità "quanto tempo?" e ha fatto alcune affermazioni infondate. Se avesse fornito dati correttamente raccolti, allora il 50% delle domande sarebbe caduto nella fase di raccolta dei dati.

Motivazione: