VPS, MT5 и память - сколько ему надо?! - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну я имел ввиду , если потихоньку отключать те или иные вызовы , рано или поздно можнл выйти на тот модуль который отжирает память. Но это при условии что у вас код написан в виде отдельных процедур а не тупо линейно.
Ага, я так свой сов когда-то на пятерку переделывал. При компиляции было море ошибок, тупо все заккомментил через /*....*/ и потом потихоньку исправлял-раскомменчивал. Тут так же можно поступить в плане памяти.
Ага, я так свой сов когда-то на пятерку переделывал. При компиляции было море ошибок, тупо все заккомментил через /*....*/ и потом потихоньку исправлял-раскомменчивал. Тут так же можно поступить в плане памяти.
похода может быть три
1) медленно отключать по одной.
2) отключить все и медленно включать по одной. ( Лешин вариант )
3) отключить только половину и если не попали то отключить оставшуюся половину , a если попали , то что бы полностью локализовать и выйти на конкретный участок кода - из выборки убрать следующую половину - и так дойти до самого бага, скорость поиска бага в этой ситуации резко возрастает.
Мой любимый вариант N3
Потестировал ситуацию на домашнем компе:
1. сам терминал с примерно тем же количеством окон (без экспертов) и тем же количеством инструментов в маркетвотч занимает всего 150 Мб памяти.
2. тот же эксперт отжирает при вызове HistorySelect 30Мб, но надо отметить, что сделок на ломашнем компе совсем немного, практически нет совсем. По идее, с учётом того, что историю я запрашиваю совсем за последние 10 минут, то есть совсем без сделок, такого быть не должно. Но может всё же у меня ошибка, буду смотреть дальше.
3. память, что на VPS, что на домашнем, отжирается экспертом однократно. Освобождается только после удаления эксперта\графика.
Потестировал ситуацию на домашнем компе:
1. сам терминал с примерно тем же количеством окон (без экспертов) и тем же количеством инструментов в маркетвотч занимает всего 150 Мб памяти.
2. тот же эксперт отжирает при вызове HistorySelect 30Мб, но надо отметить, что сделок на ломашнем компе совсем немного, практически нет совсем. По идее, с учётом того, что историю я запрашиваю совсем за последние 10 минут, то есть совсем без сделок, такого быть не должно. Но может всё же у меня ошибка, буду смотреть дальше.
3. память, что на VPS, что на домашнем, отжирается экспертом однократно. Освобождается только после удаления эксперта\графика.
Битность терминала одинаковая?
x64
Windows Server 2012 R2 x64
Windows 7 pro x64
в общем проблема была в следующем - история у моего терминала на VPS весьма большая, поэтому при загрузке её полностью, либо весомой части, потребляется много памяти. при этом эта память почему-то так и не освобождается. Непонятно почему, но не освобождается. Может где-то много позже, но я не дождался, сколько не экспериментировал.
Готовое решение (класс) который я использовал (см. выше), пытался грузить всю историю.
Перешёл на класс из статьи Д. Федосеева ОПТИМАЛЬНЫЙ МЕТОД ПОДСЧЕТА ОБЪЕМА СОВОКУПНОЙ ПОЗИЦИИ ПО ЗАДАННОМУ МАГИЧЕСКОМУ НОМЕРУ - решение более гибкое, первый раз отжирает память тоже, но со второго раза по инструменту больше не грузит историю целиком, так как запоминает точку во времени, когда по инструменту не было позиций и работает далее от неё. К тому же эта точка доступна и всем другим экспертам на этом инструменте. Таким образом достаточно по инструменту один раз запустить эксперта, дать ему обработать историю, удалить. Все последующие эксперты будут использовать только самый последний отрезок истории и память потреблять не будут совсем.
Конечно, если не пользоваться готовыми решениями, а сделать вручную и историю грузить самому например с момента запуска эксперта, то проблем и не будет, но я воспользовался не совсем рабочим готовым классом и словил проблему.
похода может быть три
1) медленно отключать по одной.
2) отключить все и медленно включать по одной. ( Лешин вариант )
3) отключить только половину и если не попали то отключить оставшуюся половину , a если попали , то что бы полностью локализовать и выйти на конкретный участок кода - из выборки убрать следующую половину - и так дойти до самого бага, скорость поиска бага в этой ситуации резко возрастает.
Мой любимый вариант N3
Насчет варианта 3 - часто есть зависимости функций/классов друг от друга, не всегда можно делить пополам.
в общем проблема была в следующем - история у моего терминала на VPS весьма большая, поэтому при загрузке её полностью, либо весомой части, потребляется много памяти. при этом эта память почему-то так и не освобождается. Непонятно почему, но не освобождается. Может где-то много позже, но я не дождался, сколько не экспериментировал.
Если память освобождается, когда удаляешь советника, значит проблема именно в советнике.
Кэш у терминала есть, и он тоже может какое-то время жить в памяти, но тогда он бы не освобождался при удалении советника, и не множился бы при переключении ТФ.
Обратите внимание на глобальные переменные, объекты, массивы, и ссылки на них.
Если память освобождается, когда удаляешь советника, значит проблема именно в советнике.
Кэш у терминала есть, и он тоже может какое-то время жить в памяти, но тогда он бы не освобождался при удалении советника, и не множился бы при переключении ТФ.
Обратите внимание на глобальные переменные, объекты, массивы, и ссылки на них.
это да, ясно что с советником проблема, а точнее - с используемым классом, так как без него никаких проблем
ну и напомню, что у используемого терминала и счёта очень обширная история, в т.ч. и арбитражных сделок, так что вполне возможно, что такое поведение - норма