I clienti possono caricare i dati-set e abbiamo bisogno di selezionare il nodo su cui verrà caricato il set di dati e si rifiutano di caricare/evitare un errore di OOM se non c'è una macchina che potrebbe montare il set di dati.
Questo è un problema di pianificazione del lavoro, ad esempio Ho risorse limitate come utilizzarle al meglio. Otterrò il problema OOM vicino alla fine.
Abbiamo uno dei fattori principali ie RAM, ma le soluzioni ai problemi di programmazione dipendono da molti fattori come per esempio ...
sono i lavori ovvero piccole o grandi ci sono centinaia/migliaia di questi in esecuzione su un nodo o due o tre. Pensa allo scheduler di Linux.
Devono essere completati in un determinato periodo di tempo? Programmatore in tempo reale.
Dato tutto ciò che conosciamo all'inizio di un lavoro possiamo prevedere quando un lavoro si concluderà entro un certo periodo di tempo? Se possiamo prevedere che su Node X liberiamo 100 MB ogni 15 - 20 secondi, abbiamo un modo per pianificare un lavoro da 200 Mb su quel nodo, ovvero sono sicuro che in 40 secondi avrò completato 200Mb di spazio su quel nodo e il 40 secondi è un limite accettabile per la persona o la macchina che invia il lavoro.
Supponiamo di avere una funzione come segue.
predicted_time predict(long bytes[, factors]);
Il factors sono le altre cose che ci sarebbe bisogno di prendere in considerazione che ho citato sopra e per ogni applicazione ci saranno cose che si possono aggiungere in base alle proprie scenario cioè quanti fattori sta a voi.
Per calcolare i fattori nel calcolo predicted_time.
predicted_time è il numero di millisecondi (può essere qualsiasi TimeUnit) che questo nodo crede da ora che può servire questa attività, il nodo che ti dà il numero più piccolo è il nodo su cui il lavoro dovrebbe essere programmato. È quindi possibile utilizzare questa funzione come segue quando abbiamo una coda di attività, ad esempio, nel seguente codice this.nodes[i] rappresenta un'istanza JVM.
private void scheduleTask() {
while(WorkEvent()) {
while(!this.queue.isEmpty()) {
Task t = this.queue.poll();
for (int i = 0; i < this.maxNodes; i++) {
long predicted_time = this.nodes[i].predict(t);
if (predicted_time < 0) {
boolean b = this.queue.offer(t);
assert(b);
break;
}
if (predicted_time <= USER_EXPERIENCE_DELAY) {
this.nodes[i].addTask(t);
break;
}
alert_user(boolean b = this.queue.offer(t);
assert(b);
}
}
}
}
Se predicted_time < 0 abbiamo un errore, abbiamo riprogrammare il lavoro, in realtà ci piacerebbe sapere perché ma questo non è difficile aggiungere. Se il predicted_time <= USER_EXPERIENCE_DELAY il lavoro può essere pianificato.
Come funziona questo evitare un OOM
Siamo in grado di raccogliere qualsiasi statistica che vogliamo dal nostro scheduler cioè quanti posti di lavoro di dimensioni X, dove pianificato in modo corretto, l'obiettivo sarebbe quello di ridurre gli errori e per renderlo più affidabile nel tempo, ovvero ridurre il numero di volte in cui diciamo a un cliente che il suo lavoro non può essere assistito o che non ha funzionato. Quello che abbiamo fatto o almeno tentiamo di tentare è di ridurre il problema a qualcosa che possiamo migliorare statisticamente verso una soluzione ottimale.
Non dimenticare che potrebbe esserci una differenza tra una query per un numero elevato di oggetti più piccoli rispetto a una query per alcuni oggetti di grandi dimensioni (a causa della memoria intermedia potenzialmente necessaria per la conversione della rappresentazione del database in un oggetto Java) . – Robert