Обращение к БД во время оптимизации на удаленных агентах

Новый комментарий
 

Всем привет!


Никак не могу разобраться. Ситуация в следующем:

- Провожу оптимизацию

- Советник в OnInit берет параметры из БД (каждый новый проход)

- Подключение к БД не отмечается ошибкой, ошибка на стадии запроса выборки из таблицы

- При локальном тестировании/оптимизации все работает без проблем, а вот при использовании сетевых агентов выдает ошибку, которую в процессе оптимизации не вывести никак.

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


UPD Запустил обычное тестировании на локальном агенте и получил ошибку "Database error, no such table: ". К БД есть подключение, а таблицы  не видны.

Пример кода

db=DatabaseOpen(DBName, DATABASE_OPEN_READWRITE | DATABASE_OPEN_COMMON);
if(db==INVALID_HANDLE)
  {
   Print("DB: ", DBName, " Ошибка подключения к БД", GetLastError());
   ExpertRemove();//При оптимизации не удаляет, значит ошибка не в подключении
   }
DBRequest=DatabasePrepare(
           db, "SELECT * FROM INSTRUMENTS WHERE TURN_ON=1"
      );
if(DBRequest==INVALID_HANDLE)
  {
      PrintFormat("DB: ", DBName, " Ошибка загрузки данных", GetLastError());
      DatabaseClose(db);
      return(INIT_FAILED); //вот эта функция срабатывает - ошибка в обработке запроса
  }
 

Здравствуйте, Артём.

Приходилось решать такую задачу. Если коротко, то вам нужно указать с помощью директивы #property tester_file, что файл с БД должен автоматически отправляться в папки удалённых агентов тестирования.

Вот отрывок из статьи с более детальным описанием:

Перенос данных на агенты тестирования

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

Но удалённые агенты тестирования к таком файлу с данными доступа не имеют. Поэтому мы воспользовались директивой #property tester_file, которая позволяет передать любой указанный файл всем агентам тестирования в их папку данных. При запуске оптимизации, файл с данными копировался из общей папки в папку данных локального агента, запускающего процесс оптимизации. Затем файл с данными из папки данных локального агента рассылался автоматически в папки данных всех остальных агентов тестирования.

Поскольку теперь данные о результатах тестирования одиночных экземпляров торговых стратегий у нас содержатся в базе данных SQLite, то первым побуждением было поступить аналогично. Так как база данных SQLite представляет собой один файл на носителе, то его точно так же можно растиражировать на удалённые агенты тестирования с помощью вышеупомянутой директивы. Но тут есть небольшой нюанс — объём передаваемого CSV-файла составлял примерно 2 Мб, а объём файла с базой данных — уже более 300 Мб.

Такая разница обусловлена тем, что мы, во-первых, старались сохранить в базе данных максимально возможное количество статистической информации о каждом проходе, а в CSV-файле хранилась только несколько статистических параметров и данные о значениях входных параметров экземпляров стратегий. А во-вторых, в базе данных у нас уже собрана информация о результатах оптимизации стратегии на трёх разных символах и трёх различных таймфреймах для каждого символа. То есть количество проходов возросло примерно в девять раз.

Если учесть, что каждый агент тестирования получает свою собственную копию передаваемого файла, то для запуска тестирования на 32-х ядерном сервере нам понадобится разместить на нём свыше 9 ГБ данных. Если же на первом этапе у нас будет обработано ещё большее количество символов и таймфреймов, то объём файла с базой данных возрастет ещё в несколько раз. Это может привести к исчерпанию доступного дискового пространства на серверах агентов, не говоря уже о необходимости передачи по сети большого объема данных.

Однако большая часть из хранимой информации о результатах выполненных проходов тестера нам либо совсем не понадобится на втором этапе, либо не понадобится вся одновременно. То есть, из всего множества сохранённых значений для одного прохода нам нужно извлечь только строку инициализации эксперта, использованную в данном проходе. Также мы планируем собирать не одну группу одиночных экземпляров торговых стратегий, а несколько — по одной на каждую комбинацию символа и таймфрейма. Это значит, что при поиске, например, группы по EURGBP H1 нам не нужны данные о проходах на других символах, кроме EURGBP, и других таймфреймах, кроме H1.

Поэтому поступим следующим образом: при запуске каждой оптимизации мы будем создавать новую базу данных с предопределённым именем и наполнять её минимально необходимой информацией для данной задачи оптимизации. Уже имеющуюся базу данных будем называть основной базой данных, а создаваемую новую базу данных — базой данных задачи оптимизации или просто базой данных задачи. 

Файл с этой базой данных будет предаваться на агенты тестирования, так как мы укажем его имя в директиве #property tester_file. Оптимизируемый советник при запуске на агенте тестирования будет работать с этой выжимкой из основной базы данных. А при запуске на локальном компьютере в режиме сбора фреймов данных, оптимизируемый советник будет по-прежнему сохранять принимаемые от агентов тестирования данные в основную базу данных.

Разрабатываем мультивалютный советник (Часть 13): Автоматизация второго этапа — отбор в группы
Разрабатываем мультивалютный советник (Часть 13): Автоматизация второго этапа — отбор в группы
  • 2024.06.11
  • www.mql5.com
Первый этап автоматизированного процесса оптимизации у нас уже реализован. Для разных символов и таймфреймов мы проводим оптимизацию по нескольким критериям и сохраняем информацию о результатах каждого прохода в базе данных. Теперь займёмся отбором лучших групп наборов параметров из найденных на первом этапе.
 
Artem Mordvinkin:

...

- При локальном тестировании/оптимизации все работает без проблем, а вот при использовании сетевых агентов выдает ошибку, которую в процессе оптимизации не вывести никак.

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

UPD Запустил обычное тестировании на локальном агенте и получил ошибку "Database error, no such table: ". К БД есть подключение, а таблицы  не видны.
Проверьте ещё раз, есть ли таблицы именно в том файле БД, к которому вы обращаетесь? Нет ли опечатки в имени таблицы? Сталкивался с похожими ошибками, но всегда в итоге находил причину ошибки со своей стороны. То есть с неправильной работой MQL5 с БД пока ещё не сталкивался.
 
Yuriy Bykov #:

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

Проверьте ещё раз, есть ли таблицы именно в том файле БД, к которому вы обращаетесь? Нет ли опечатки в имени таблицы? Сталкивался с похожими ошибками, но всегда в итоге находил причину ошибки со своей стороны. То есть с неправильной работой MQL5 с БД пока ещё не сталкивался.

Юрий, спасибо!

Новый комментарий