В настоящее время я отвечаю за быстрорастущий кластер Hadoop для своего работодателя, который в настоящее время построен на выпуске 0.21.0 с CentOS в качестве ОС для каждого рабочего и главного узла. Я проработал большинство стандартных проблем конфигурации (балансировка нагрузки, планирование ввода-вывода для HDFS, обеспечение достаточного дискового пространства для операций разлива и т. Д.), Но не нашел хорошей документации по управлению количеством файловых дескрипторов. требуется для каждого трекера задач, узла данных, сопоставителя или редуктора.
Документация, которую я читал до сих пор (по Hadoop и HBase), нечетко указывает на то, что операция сброса потребляет большое количество дескрипторов одновременно при попытке записи на диск. Эта документация, конечно же, не содержит разбивки области действия или ожидаемого срока службы указанных дескрипторов. Единственное предложение заключалось в том, чтобы поднять системный предел, что правдоподобно как обходной путь и ложно как стратегия долгосрочного планирования.
У меня нет информации о том, какие предположения делает Hadoop относительно количества требуемых файловых дескрипторов. В результате вычисление общего числа файловых дескрипторов, необходимых для каждого сопоставителя, редуктора, средства отслеживания задач и узла данных в зависимости от конфигурации в течение всего срока службы обычного задания (то есть, не зависящего от MultipleOutputs), было бы чрезвычайно полезным.
Существует ли такой расчет в настоящее время, и если да, могу ли я сделать разумные оценки того, какими должны быть мои пределы относительно произвольного количества заданий, как определено?
(Чтобы повысить вероятность того, что этот вопрос будет найден другими, столкнувшимися с этой проблемой, Hadoop с радостью выдаст исключения java.io.EOFException и java.io.IOException (указывающие на плохой дескриптор файла), когда пул доступных дескрипторов исчерпан. Это Мне потребовалось несколько часов, чтобы отследить, поскольку сообщения, включенные в эти исключения, являются чрезвычайно общими.)
Это основной источник проблем в экосистеме Hadoop, и, как ни странно, нет хорошего ответа на комплексное планирование для такого рода ресурсов. В целом, этот дистрибутив Hadoop не корпоративного качества, который поддерживает похвальный уровень осмотрительности, который вы применяете к своей системе.
Однако я почти уверен, что он будет в ближайшие несколько месяцев.