41 lines
1.3 KiB
Text
41 lines
1.3 KiB
Text
- abstract da rifare una volta scritto il paper
|
|
- dare una conclusione
|
|
|
|
- introduction
|
|
- tracce 2009 google
|
|
- tracce 2019 non studiate per i fallimenti
|
|
- obiettivo studiare fallimenti 2019 da diverse prospettive e confrontare con 2011
|
|
|
|
- come studiare i fallimenti
|
|
- impatto in tempo/spazio fallimenti
|
|
- modellare fallimenti (come riprodurre/studiare statisticamente fallimenti)
|
|
- trovare i motivi dei fallimenti (correlazioni che dipendono da task/job/macchine che causano piu' fallimenti)
|
|
|
|
- contribution:
|
|
- perche' sto progetto e' utile
|
|
|
|
- challenges:
|
|
- ci sono tanti dati, tempo CPU, spark
|
|
|
|
- outline:
|
|
- descrivere struttura report
|
|
|
|
- figura 1: statistiche generali (motivare che i task sono tanti, i job sono tanti)
|
|
|
|
- scaletta:
|
|
- Sezione 2: background information
|
|
- COME SONO FATTE LE TRACCE?
|
|
- Cosa sono Job, task, eventi fallimenti
|
|
- Definire termine failure and execution
|
|
|
|
- C'e' un datacenter, ci sono 8 cluster in posti diversi,
|
|
- Le macchine sono cosi: machine_configs
|
|
- Come funziona borg? tu mandi job (tipo Dockerfile). Job fatti da
|
|
task, job e task subiscono eventi (cambiamento di job e task).
|
|
Eventi sono di tanti tipi ma ci interessano questi: (EVICT FAIL FINISH KILL (non lost))
|
|
|
|
Figure separate per TUTTI I CLUSER e cluster separati
|
|
|
|
LEVARE DALLE FIGURE LOST E NO_TERM
|
|
(Eccezione unknown machine_time_waste)
|
|
|