Dag файл ethereum: когда закончится майнинг на видеокартах

В отличие от биткоина, майнинг эфириума требует большого объема оперативной памяти. «Аппетит» этой валюты растет по мере добавления новых записей в блокчейн. Майнеры с устаревшими видеокартами все чаще сталкиваются с «CUDA error 11». Эта ошибка означает, что размер Dag-файла Ethereum превысил объем буфера памяти майнинговой программы. В некоторых случаях ошибка возникает из-за сбоя майнингового ПО и от нее можно избавиться без апгрейда «железа». Давайте разберемся что такое DAG-файл и от чего зависит его размер.

Что такое dag файл

Для нахождения подписи блока (хеша) по алгоритму Ethash используется блок данных, именуемый DAG-файл. Он хранится в памяти видеокарты во время работы майнера. Алгоритм устроен таким образом, что после нахождения 30 тысяч блоков размер DAG-файла Ethereum (как и других криптовалют на алгоритме Ethash) увеличивается на 8 мегабайт. Каждое новое состояние называется эпохой.

Скорость смены «эпох» зависит от времени нахождения блока, которое у эфириума колеблется от 10 до 60 секунд. Среднее значение составляет 14,5 секунды. На момент написания статьи добыто 6249979 Ethereum, что означает 208 эпоху. Размер DAG-файла равен 2,62 гигабайта. Ethereum Classic, блоки которого закрываются чуть быстрее, уже находится в 215 эпохе. Поэтому его DAG-файл занимает 2,68 гигабайта видеопамяти. Узнать актуальную эпоху и размер файла для криптовалют на основе Ethash можно в разделе DAG-file calculator сайта investoon.com.

Размер ДАГ файла Ethereum

Размер DAG file динамический и постоянно увеличивается. Как уже упоминалось выше, каждые 4-5 дней он увеличивается на 8 МБ. Для определения размера DAG используют следующее:

программу GPU-Z в момент майнинга, что позволяет отследить фактический размер памяти оборудования и объем файла;
можно найти искомый документ на компьютере и узнать его параметры;
обратиться за помощью на ресурсы https://investoon.com/tools/dag_size или https://minerstat.com/dag-size-calculator?lang=ru, где информация обновляется в режиме реального времени.

Важно: Способ с сайтом считается наиболее удобным из-за частоты обновлений, привязке к реальному времени, а также калькулятору размера DAG. Достаточно ввести нужный блок и узнать, каким будет объем спустя n-количество времени, какая сейчас эпоха Эфириума и т. д.

По таблице ниже видно, как менялся DAG file последние годы и чего ждать в будущем:

Размер DAG	Эпоха	Блок	День
1,99 Гб	127	3,839,999	9 сентября 2017
2,99 Гб	256	7,679,999	2 мая 2019
3,99 Гб	383	11,519,999	22 декабря 2020
5,99 Гб	639	29,199,999	6 апреля 2024
7,99 Гб	895	26,879,999	21 июля 2027
10,99 Гб	1280	38,399,999	26 июля 2032

Если алгоритм PoW не будет изменен на PoS до 100 миллионного блока, тогда размер DAG будет равняться 27,04 Гб во время 3333 эпохи.

Где находится DAG-файл эфириума

Ethereum его DAG-файл генерируется майнинговым приложением по заранее определенному алгоритму. После запуска программы он загружается в ОЗУ каждой видеокарты фермы. Размер DAG-файла Ethereum можно увидеть с помощью утилиты GPU-Z, которая отображает текущие показатели работы видеоадаптеров, в том числе загрузку видеопамяти. Этот показатель отображается в строке Memory Usage.

Как удалить DAG-файл Etherium

Для удаление DAG-file в системе Windows необходимо включить в настройках проводника отображение скрытых папок и файлов и просмотреть директорию текущего пользователя. Программы Ethminer и Qtminer по умолчанию хранят DAG-файл в директории AppData/Local/Ethash. Имена файлов начинаются с «full-R23».

Чтобы удалить его, необходимо закрыть майнинговое приложение и очистить директорию.

Важно: при следующем запуске майнера файлы будут сгенерированы заново и на это понадобится немало времени.

Сегодня рассмотрим, как упростить работу дата-инженера в Apache AirFlow, автоматизировав процесс создания DAG’ов из одного или нескольких Python-файлов. На практических примерах разберем достоинства и недостатки 5 способов динамической генерации, а также особенности масштабирования Big Data pipeline’ов.

Что такое динамическая генерация DAG в Apache Airflow и зачем она нужна

В статье про лучшие практики разработки Big Data pipeline’ов в Apache Airflow мы упоминали про DRY-принцип (Don’t Repeat Yourself). Например, многие ELT-процессы с разными источниками и приемниками данных часто содержат большое количество одинакового Python-кода. Чтобы каждый раз не писать это вручную, целесообразно генерировать это Python-код автоматически в виде DAG (Directed Acyclic Graph) – направленный ациклический граф задач по обработке данных [1].

Airflow выполняет весь код Python в папке DAG_FOLDER и загружает все объекты DAG, которые появляются в функции globals(). Напомним, Python-функция globals()возвращает переменные, которые пользователь может устанавливать, и получать значения, как в словаре. После установки значений можно вызывать переменные, как будто они были созданы в обычном режиме [2].

Таким образом, самый простой способ создать DAG – записать его как статический файл Python. Но создание DAG вручную не всегда целесообразно. К примеру, когда есть сотни или тысячи DAG’ов, которые делают похожие вещи, меняя лишь некоторые параметры. Или нужен набор DAG для загрузки таблиц, которые могут меняться. В этих и многих других случаях поможет динамическое создание DAG.

Поскольку все в Airflow – это код, можно динамически создавать DAG, используя только Python. Создавав объект DAG в функции globals() с помощью Python-кода в папке DAG_FOLDER, Airflow загрузит его. Динамическая генерация Directed Acyclic Graph возможна несколькими способами, которые можно сгруппировать по количеству используемых Python-файлов, что мы и рассмотрим далее [3].

3 способа динамической генерации DAG из одного файла

Итак, первым способом динамического создания Directed Acyclic Graph является – это наличие одного файла Python, который генерирует DAG на основе входных параметров, например, списка API или таблиц как в ETL/ELT-конвейере со множеством источников или приемников данных. Это требует создания множества Directed Acyclic Graphs по одному шаблону. Преимуществами такого метода являются следующие [3]:

простая реализация;
возможность принимать входные параметры из разных источников;
быстрота – добавление DAG-файлов происходит практически мгновенно, т.к. для этого нужно лишь изменить входные параметры.

Однако, этот способ имеет и недостатки:

сам файл Directed Acyclic Graph при этом не создается;
необходимо иметь файл Python в папке DAG_FOLDER и генерация кода будет выполняться при каждом heartbeat-сигнале планировщика, что может вызвать проблемы с производительностью при большом количестве DAG’ов или подключении к внешней системе, например к СУБД.

Однофайловый способ реализуется по-разному в зависимости от того, какие входные параметры используются для создания DAG [3]:

метод Create_DAG – пользовательская функция Python, которая будет генерировать DAG на основе входного параметра. Входные параметры могут поступать из любого источника, к которому имеет доступ скрипт Python. При необходимости можно установить простой цикл для генерации уникальных параметров и передачи их в глобальную область видимости, зарегистрировав их как действительные DAG в планировщике Airflow.
генерация DAG из переменных. Входные параметры не обязательно должны существовать в самом файле Directed Acyclic Graph, их значения можно установить в объекте Variable. Чтобы получить это значение, нужно импортировать класс Variable и передать его в соответствующую область. Чтобы интерпретатор регистрировал этот файл как действительный независимо от того, существует ли переменная, default_var устанавливается в 3.
генерация DAG из подключений – отличный вариант, если каждый DAG подключается к СУБД или API. Поскольку дата-инженеру все равно придется настраивать эти подключения, создание Directed Acyclic Graph из этого источника позволит избежать избыточной работы. Для реализации этого способа следует извлечь соединения из базы метаданных Airflow, создав экземпляр Session и запросив таблицу Connection. Можно отфильтровать этот запрос, чтобы он извлекал только те соединения, которые соответствуют определенным критериям. Необходимо обратиться к библиотеке Models, чтобы работать с классом Connection, а доступ к классу Session нужен, чтобы запрашивать текущий сеанс базы данных.

Многофайловые методы

Также для динамической генерации Directed Acyclic Graph можно использовать несколько файлов Python, чтобы для каждого созданного DAG в папке DAG_FOLDER был отдельный Python-файл. Это особенно полезно в production, когда Python-скрипт генерирует файлы DAG при выполнении рабочего процесса CI/CD. DAG создаются во время сборки CI/CD, а затем развертываются в Airflow. Также может быть другой Directed Acyclic Graph, который периодически запускает этот скрипт генерации.

Главные преимущества такого метода:

лучшая масштабируемость по сравнению с однофайловыми способами, т.к. не нужно анализировать код в DAG_FOLDER и код генерации DAG не выполняется при каждом heartbeat-сигнале планировщика;
файлы DAG создаются явным образом перед развертыванием в Airflow и есть полная видимость их кода.

Основным недостатком этого метода является сложность настройки. Кроме того, изменения в существующих DAG или дополнительные Directed Acyclic Graphs создаются только после запуска скрипта, что может требовать полноценного развертывания.

Реализовать метод динамической генерации DAG из нескольких файлов помогут следующие способы:

создание DAG из файлов конфигурации JSON с помощью Python-скрипта. Этот вариант актуален для дата-аналитиков, которым необходимо запланировать разные SQL-запросы по одним источникам данных, выполняющиеся в разное время. Для этого сперва нужно создать файл-шаблон со структурой DAG и переменными, информация о которых будет динамически генерироваться, например, dag_id, scheduletoreplace и querytoreplace. Затем нужно создать папку dag-config с файлом конфигурации JSON для каждого DAG. Файл конфигурации определяет необходимые параметры: dag_id, scheduletoreplace и querytoreplace. Наконец, создать Python-скрипт, который будет создавать файлы DAG на основе шаблона и файлов конфигурации, просматривая каждый файл конфигурации в папке dag-config/ и перезаписывает значения параметры. Чтобы сгенерировать файлы DAG, можно запустить этот сценарий ad-hoc как часть рабочего процесса CI/CD или создать еще один DAG для периодического запуска скрипта. Этот простой пример с генерацией DAG по одному шаблону можно расширить, добавив динамические входы для задач, зависимостей, различных операторов и пр.
Фабрика DAG’ов (DAG-factory) – Python-библиотека с открытым исходным кодом для динамической генерации DAG-файлов Airflow из файлов YAML. Разработанная сообществом энтузиастов, она доступна для свободного скачивания с Github [4]. Чтобы использовать dag-factory, следует установить этот пакет в среде Airflow и создать файлы конфигурации YAML для генерации Directed Acyclic Graph. Затем можно динамически создать Directed Acyclic Graph, вызвав метод dag-factory.generate_dags() в Python-скрипте. Как эта идея реализуется на практике, читайте в нашей следующей статье.

Динамическая генерация DAG’ов и масштабируемость AirFlow

В зависимости от количества DAG’ов, конфигурации Airflow и инфраструктуры, в которой он развернут, динамическое создание Directed Acyclic Graph может вызвать проблемы с производительностью при масштабировании. Поэтому дата-инженеру рекомендуется учесть следующие аспекты [3]:

любой код в папке DAG_FOLDER будет выполняться при каждом heartbeat-сигнале планировщика. Поэтому однофайловые методы генерации DAG, вероятней всего, вызовут проблемы с производительностью при масштабировании.
если время синтаксического анализа Directed Acyclic Graph, т.е. кода в папке DAG_FOLDER, больше интервала heartbeat-сигнала планировщика, Sheduler может заблокироваться, и задачи не будут выполняться.

Решить эти проблемы с производительностью поможет обновление до Airflow версии 2.0, в котором поддерживается высокая доступность планировщика. Но все же дата-инженеру потребуется дополнительно оптимизировать конвейеры в зависимости от рабочего масштаба. Не существует универсального способа реализации или масштабирования динамически генерируемых DAG, но гибкость Airflow позволяет найти решение, которое подойдет для конкретного сценария [3].

Больше подробностей про использование Apache AirFlow для разработки сложных конвейеров аналитики больших данных с Hadoop и Spark вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Data Pipeline на Apache Airflow и Apache Hadoop
Data pipeline на Apache AirFlow и Arenadata Hadoop

Смотреть расписание
Записаться на курс

Источники

https://towardsdatascience.com/data-engineers-shouldnt-write-airflow-dags-b885d57737ce
https://flavio-mtps.medium.com/making-use-of-python-globals-to-dynamically-create-airflow-dags-124e556b704e
https://www.astronomer.io/guides/dynamically-generating-dags
https://github.com/ajbosco/dag-factory

Сколько графической памяти нужно для майнинга эфира

Следует учесть, что при отображении картинки на мониторе с помощью майнинговой видеокарты, она дополнительно расходует 150-200 мегабайт видеопамяти. В таком случае для работы майнера потребуется GPU с памятью, объем которой больше DAG size (размера DAG-файла).

С учетом того, что эта величина Ethereum перевалила за 2,6 гигабайта, для его добычи нужны видеокарты с ОЗУ 3 Гб и более. С учетом постоянного роста размера FAG-файла, GPU с тремя гигабайтами оперативки потеряют актуальность для эфира уже в 2022 году. Поэтому для фермы нужно брать видеокарты не менее чем с 4 Гб.

Особенности подбора видеокарты применительно к Даг Эфир

Выбирая видеокарту следует обращать внимание не только на сложность сети и хешрейт, но и объем Даг файла.

Дело в том, что покупая сейчас карту с оперативной памятью до 4 Гб, она быстро станет непригодной для добычи эфира. Используя параметры из вышеприведенной таблицы основных изменений DAG, следует рассчитывать прибыльность и окупаемость майнинга.

Хотя объем памяти видеокарты не влияет на хешрейт напрямую, он должен быть минимум на 300-500 Мб больше, чем размер Даг. Чем больше разрыв между параметрами оборудования и файла, тем лучше. Когда объем DAG приближается к показателям оборудования, хешрейт постепенно падает.

Наибольшим спросом для майнинга эфира будут пользоваться карты с объемом памяти от 6 Гб, поскольку их должно хватить до 2024 года. Владельцы карт с 3 и 4 Гб ОЗУ не должны расстраиваться, ведь еще есть время добывать Ethereum. Соответственно в мае 2022 и декабре 2022 года их оборудование станет непригодным для эфира.

Стоит понимать, что подобные карты можно использовать для добычи других монет с алгоритмом Ethash, но покупка для добычи ETH не успеет окупиться.

Какие криптовалюты можно майнить на алгоритме Dagger Hashimoto (Ethash) и выгодно ли это

Среди владельцев ферм на GPU наиболее популярны две криптовалюты на основе Ethash — Ethereum и Ethereum Classic. Однако размер их DAG-файлов не позволяет майнить на видеокартах с 2 Гб ОЗУ. В таком случае стоит заняться добычей других монет на этом алгоритме: Expanse, Musicoin, Ubiq или Coilcoin.

Прибыльность зависит от быстродействия и энергопотребления видеокарты, а также цены электроэнергии в вашем регионе. Предварительно рассчитать доходы от майнинга можно с помощью онлайн-калькулятора на сайте Whattomine.com.

Преимущества технологии

Несмотря на недостатки, связанные с устареванием оборудования для майнинга, технология использования DAG файлов имеет целый ряд преимуществ:

Скорость формирования и добавления новых блоков в сеть.
Надежность и защищенность блокчейна.
Сложность майнинга — в отличие от других популярных монет, добыча на GPU остается прибыльной.

Неоспоримым плюсом является постоянное увеличение размера файла. Из-за этого со временем будут «отпадать» как видеокарты, так и специализированные ASIC майнеры.

В заключение можно сказать, что при выборе оборудования и просчете прибыльности добычи Ethereum обязательно необходимо учитывать динамику изменения DAG. В противном случае можно собрать фермы, которые в скором времени станут непригодными для майнинга эфира.

Что делать владельцам RX 5хх или GTX 10хх карт c 4 Gb

В бочке дегтя должна быть ложка мёда: в Августе, из-за атаки 51% на блокчейн Эфириума, разработчики приняли решение снизить размер Даг-файла. Подробно разработчики сети Эфириума выразились на своем Ютуб-канале. Из официального реестра сценариев развития сети, на эпохе 390 будет изменен размер даг-файла Эфириума.