6

Ricevo un errore "Spazio non disponibile sul dispositivo" quando eseguo i miei processi Amazon EMR utilizzando m1.large come tipo di istanza per le istanze hadoop che devono essere create dal flusso di lavoro . Il lavoro genera ca. 10 GB di dati al massimo e poiché la capacità di un'istanza m1.large dovrebbe essere 420 GB * 2 (secondo: EC2 instance types). Sono confuso dal fatto che solo 10 GB di dati possano portare a un tipo di "spazio su disco completo" di un messaggio. Sono consapevole della possibilità che questo tipo di errore possa essere generato anche se abbiamo completamente esaurito il numero totale di inode permessi sul filesystem ma questo è come un grosso numero che ammonta a milioni e sono abbastanza sicuro che il mio lavoro non sia producendo così tanti file. Ho visto che quando provo a creare un'istanza EC2 indipendentemente dal tipo m1.large, per impostazione predefinita assegna ad essa un volume di root di 8 GB. Potrebbe essere questo il motivo alla base del provisioning delle istanze in EMR anche? Quindi, quando i dischi della dimensione 420 GB vengono assegnati a un'istanza?Ottenere "Spazio vuoto sul dispositivo" per ca. 10 GB di dati su EMR istanze m1.large

Inoltre, qui è l'uscita di di "df -hi" e "montare"

 
$ df -hi 
Filesystem   Inodes IUsed IFree IUse% Mounted on 
/dev/xvda1    640K 100K 541K 16%/
tmpfs     932K  3 932K 1% /lib/init/rw 
udev     930K  454 929K 1% /dev 
tmpfs     932K  3 932K 1% /dev/shm 
ip-10-182-182-151.ec2.internal:/mapr 
         100G  50G  50G 50% /mapr 

$ mount 
/dev/xvda1 on/type ext3 (rw,noatime) 
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) 
proc on /proc type proc (rw,noexec,nosuid,nodev) 
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) 
udev on /dev type tmpfs (rw,mode=0755) 
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) 
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) 
/var/run on /run type none (rw,bind) 
/var/lock on /run/lock type none (rw,bind) 
/dev/shm on /run/shm type none (rw,bind) 
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) 
ip-10-182-182-151.ec2.internal:/mapr on /mapr type nfs (rw,addr=10.182.182.151) 
 

$ lsblk 
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT 
xvda1 202:1 0 10G 0 disk/
xvdb 202:16 0 420G 0 disk 
xvdc 202:32 0 420G 0 disk 

+1

potresti fornire l'output di 'df -hi' e' mount' – slayedbylucifer

+0

@slayedbylucifer - Hai aggiunto l'output nella domanda come desiderato da te. –

+0

le due unità di 420G si visualizzano ciascuna in 'fdisk -l'? se sì, allora probabilmente, sono collegati alla tua istanza ma non ancora formattati e montati ovunque. inoltre 'df -h' mostra qualcosa che è usato al 100%? – slayedbylucifer

risposta

2

Con l'aiuto di @slayedbylucifer sono stato in grado di identificare il problema era che lo spazio su disco completo è reso disponibile per l'HDFS sul cluster per impostazione predefinita. Quindi, vi è il 10GB predefinito di spazio montato su/disponibile per l'uso locale dalla macchina. C'è un'opzione chiamata --mfs-percentage che può essere utilizzata (mentre si utilizza la distribuzione MapR di Hadoop) per specificare la divisione dello spazio su disco tra il filesystem locale e HDFS. Monta la quota del filesystem locale a /var/tmp. Assicurati che l'opzione mapred.local.dir sia impostata su una directory all'interno di /var/tmp perché è lì che vanno tutti i registri del taskmaster che possono essere di dimensioni enormi per i grandi lavori. La registrazione nel mio caso stava causando l'errore di spazio su disco. Ho impostato il valore di --mfs-percentage su 60 ed è stato in grado di eseguire il lavoro con successo in seguito.

Problemi correlati