Получение "не осталось места на устройстве" для ок. 10 ГБ данных по ЭМИ М1.крупные экземпляры


Я получаю сообщение об ошибке "на устройстве не осталось места", когда я выполняю свои задания Amazon EMR с использованием m1.большой, как тип экземпляра для экземпляров hadoop, создаваемых jobflow. Задание генерирует ок. 10 ГБ данных при максимальной и начиная с емкости М1.большой экземпляр должен быть 420GB*2 (в соответствии с: EC2 типами экземпляров). Я не понимаю, как всего 10 ГБ данных могут привести к" полному дисковому пространству " типа сообщения. Я осознаю возможность того, что такого рода ошибка также может быть сгенерировано, если мы полностью исчерпали общее количество индексов, разрешенных в файловой системе, но это похоже на большое число, составляющее миллионы, и я уверен, что моя работа не производит так много файлов. Я видел это, когда пытался создать экземпляр EC2 независимо от m1.большой тип по умолчанию присваивает ему корневой том размером 8 ГБ. Может быть, это также является причиной выделения экземпляров в EMR? Затем, когда диски размером 420 ГБ будут распределены на пример?

Также, здесь вывод "df-hi "и"mount"

$ 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 6

1 ответ:

С помощью @slayedbylucifer я смог определить, что проблема заключалась в том, что полное дисковое пространство по умолчанию доступно для HDFS в кластере. Таким образом, по умолчанию имеется 10 ГБ пространства, установленного на / доступного для локального использования машиной. Существует опция --mfs-percentage, которая может использоваться (при использовании MapR-дистрибутива Hadoop) для указания разделения дискового пространства между локальной файловой системой и HDFS. Он монтирует локальную квоту файловой системы в /var/tmp. Убедитесь, что опция mapred.local.dir устанавливается в каталог внутри /var/tmp, потому что именно туда попадают все журналы попыток tasktracker, которые могут быть огромными по размеру для больших заданий. Ведение журнала в моем случае вызывало ошибку дискового пространства. Я установил значение --mfs-percentage равным 60 и после этого смог успешно выполнить задание.