Ошибка not enough memory

Страницы: 1
RSS
Ошибка not enough memory, сегодня скрипт впервые упал с такой ошибкой -- как выявить причину?
 
Сегодня мой "боевой" скрипт LUA в ходе работы сегодня несколько раз падал с такой ошибкой.
Поначалу грешил на то, что вставил в другой скрипт анализ изменения стаканов по всем фьючам, но отключение модуля результата не дало.
По понятным, думаю, причинам, выложить его в открытый доступ не могу. В этой связи вопросы.
1. Подскажите, какова возможная причина проблемы?
2. У кого были похожие ситуации, с чем они связаны и как удалось избавиться от проблем?
3. Как самостоятельно попытаться идентифицировать источник проблемы  и оптимизировать код?
4. Есть ли возможность использовать для LUA какие-либо программы отладки, которые анализируют

П.С. Версия quik - 7.12 Windows 10 64 бит 32 гб RAM. Одновременно работает 4 скрипта из них два - ресурсоемких. Включены таблицы всех сделок по фьючам и российским акциям (все инструменты).
П.С.С. Вообще с переходом от 7.11 к 7.12 проблемы появляются одна за одной.
 
У меня компьютер аналогичный, только памяти 16 Гб и так было несколько раз при запуске нескольких скриптов сразу.
Цитата
1. Подскажите, какова возможная причина проблемы?
2. У кого были похожие ситуации, с чем они связаны и как удалось избавиться от проблем?

Виртуальным Lua-машинам не хватает памяти. Например, сборщик мусора не успевает справляться или есть какая-то утечка памяти в скриптах. Иногда это из-за внутренних ошибок терминала.

Лучший вариант по надёжности -- это перезапускать терминал перед началом торгов (после смены торговой сессии), раз в 5-15 минут в каждом скрипте вызывать collectgarbage() для сборки мусора.
Цитата
3. Как самостоятельно попытаться идентифицировать источник проблемы  и оптимизировать код?  
4. Есть ли возможность использовать для LUA какие-либо программы отладки, которые анализируют.

Программы для отладки мне неизвестны. Можно периодически писать в лог потребление памяти каждым скриптом (функция collectgarbage("count") выдаёт количество выделенной памяти в килобайтах) до сборки мусора и после неё. Так, возможно, поймёте, в чём проблема.
 
Цитата
Иван Ру написал:
П.С. Версия quik - 7.12 Windows 10 64 бит 32 гб RAM.
Цитата
_sk_ написал:
У меня компьютер аналогичный, только памяти 16 Гб
Ребят, вы поймите, квик - 32х битный процесс, он не может использовать больше 4гб от слова никак.
И ему без разницы 16 у тебя или 32 гб рам.

Надо уменьшать кол-во данных внутри квика, и оптимизировать луа-скрипты.
 
Цитата
Imersio Arrigo написал:
Цитата
Иван Ру   написал:
П.С. Версия quik - 7.12 Windows 10 64 бит 32 гб RAM.
Цитата
_sk_   написал:
У меня компьютер аналогичный, только памяти 16 Гб
Ребят, вы поймите, квик - 32х битный процесс, он не может использовать больше 4гб от слова никак.
И ему без разницы 16 у тебя или 32 гб рам.

Надо уменьшать кол-во данных внутри квика, и оптимизировать луа-скрипты.
1) посмотрите диспетчером задач используемый объем памяти.
2) Посмотрите объем используемой скриптом памяти сборщиком мусора
----------------------------------------------
Чтобы исчерпать всю память надо написать очень плохой скрипт .
 
Цитата
Ребят, вы поймите, квик - 32х битный процесс, он не может использовать больше 4гб от слова никак.
И ему без разницы 16 у тебя или 32 гб рам.

Про ограничение 4Гб я в курсе (https://forum.quik.ru/messages/forum1/message25429/topic2913/#message25429). Реально там даже меньше.
Цитата
Чтобы исчерпать всю память надо написать очень плохой скрипт.

Или использовать один терминал для интенсивной торговли по большому количеству счетов и инструментов. По-хорошему, надо переходить на что-то более адекватное, но пока (из-за дешевизны решения) приходится мириться с недостатками терминала.
 
Цитата
_sk_ написал:
У меня компьютер аналогичный, только памяти 16 Гб и так было несколько раз при запуске нескольких скриптов сразу.
Цитата
1. Подскажите, какова возможная причина проблемы?
2. У кого были похожие ситуации, с чем они связаны и как удалось избавиться от проблем?
Виртуальным Lua-машинам не хватает памяти. Например, сборщик мусора не успевает справляться или есть какая-то утечка памяти в скриптах. Иногда это из-за внутренних ошибок терминала.

Лучший вариант по надёжности -- это перезапускать терминал перед началом торгов (после смены торговой сессии), раз в 5-15 минут в каждом скрипте вызывать collectgarbage() для сборки мусора.
Цитата
3. Как самостоятельно попытаться идентифицировать источник проблемы  и оптимизировать код?  
4. Есть ли возможность использовать для LUA какие-либо программы отладки, которые анализируют.
Программы для отладки мне неизвестны. Можно периодически писать в лог потребление памяти каждым скриптом (функция collectgarbage("count") выдаёт количество выделенной памяти в килобайтах) до сборки мусора и после неё. Так, возможно, поймёте, в чём проблема.
О, спасибо!
Я думал  collectgarbage()  оценивает память используемую всем терминалом, я не прав?
Я так понимаю, Вы вызываете сборщик мусора в цикле вложенным в main используя счетчик времени или используете setpause"и setstepmul. Можете привести элемент кода с этой операцией?
 
Я думал  collectgarbage()  оценивает память используемую всем терминалом, я не прав?

Нет, это память, используемая lua-машиной отдельного скрипта.

Я так понимаю, Вы вызываете сборщик мусора в цикле вложенным в main  используя счетчик времени или используете setpause"и setstepmul. Можете  привести элемент кода с этой операцией?

Создаём файл Timer.lua примерно такого содержания:
Код
--
-- Реализация таймера.
--
-- Пример использования:
-- local Timer = require("util.Timer")
-- local timer = Timer:new()
-- timer:setInterval(10)
-- ...
-- if timer:isTimeout() then ...
--

local Timer = {}

--- Конструктор.
-- @param self объект
local function new(self)
    local timer = {
        deadline = os.time()
    }
    setmetatable(timer, self)
    self.__index = self
    return timer
end

Timer.new = new

--- Задать интервал, по прошествии которого считается, что таймер сработал.
-- @param self объект
-- @param duration число секунд, через которое должен сработать таймер.
local function setInterval(self, duration)
    self.deadline = os.time() + duration
end

Timer.setInterval = setInterval

--- Задать момент времени, по прошествии которого считается, что таймер сработал.
-- @param self объект
-- @param date таблица, задающая дату, когда должен сработать таймер.
local function setDate(self, date)
    self.deadline = os.time(date)
end

Timer.setDate = setDate

--- Узнать, через сколько секунд осталось до момента срабатывания таймера.
-- @param self объект
-- @return количество секунд оставшееся до срабатывания таймера или 0, если время срабатывания прошло
local function getSecondsLeft(self)
    return math.max(0, self.deadline - os.time())
end

Timer.getSecondsLeft = getSecondsLeft

--- Узнать, наступил ли момент срабатывания таймера.
-- @param self объект
-- @return true/false
local function isTimeout(self)
    return os.time() >= self.deadline
end

Timer.isTimeout = isTimeout

return Timer

Используется примерно так:
Код
local function printMemoryUsed()
    logger:debug("Memory used: " .. math.ceil(collectgarbage("count") / 1024) .. "M")
end

local function run()
    while not interrupted do
        ...
        if garbageTimer:isTimeout() then
            printMemoryUsed()
            logger:debug("Collecting garbage...")
            collectgarbage()
            printMemoryUsed()
            garbageTimer:setInterval(600)
        end
        ...
    end
end

function main()
    ...
    run()
    ...
end
 
Упс, цитаты забыл поставить, а форум не даёт редактировать своё сообщение.
 
Иван Ру,

1) Попробуйте перед началом работы терминала удалить все файлы из папки терминала с расширением .log.
2) Не оставляйте терминал открытым, если закончили работу. Закрывайте терминал.
3) В скриптах не используйте механизм постоянного и бесконтрольного воспроизводства таблиц ( {} ).
4) Помните, что в первую очередь терминал выполняет свои основные задачи и лишь потом - ваши. Чем "тяжелее" скрипт, тем больше времени он требует, тем медленнее работает терминал и все остальные вызовы.
5) Если у вас действительно ресурсоемкий - с точки зрения объемов обрабатываемых данных - скрипт, то имеет смысл выносить его вовне. Иначе вы в конце концов придете к неконтролируемому торможению собственно работы терминала.

Еще один возможный выход: договоритесь с брокером, чтобы он выделил вам еще одно рабочее место с другим uid, и запускайте его либо на отдельной машине, либо в отдельном процессе.
 
Спасибо всем, в особенности _sk_, за советы!
Сообщаю предварительные выводы.
Особых событий перед падением скриптов нет, обычно крашу случается по истечение нескольких часов после их запуска, что наводит на мысль о постепенном заполнении памяти в ходе работы скриптов.
Логгирование это подтвердило -- происходит плавный рост использования памяти с течение времени в обоих моих основных скриптах, в особенности в последнем сварганенном.
Собственно, я получил то что и должен был получить -- он сохраняет в таблицу последние bid, ask два раза в секунду и данные по сделкам по ВСЕМ фьючерсам. Каждый час объем памяти используемый этим скриптом растет приблизительно на 150 мегабайт. Падает чаще всего второй скрипт, который сохраняет меньше данных, но, по-видимому, делает это (т.е. обращается к памяти) чаще.
Я полагаю что ручной запуск сборщика мусора мне мало чем поможет, т.к. проблема не в большом объеме мусорных данных, а в огромных таблицах (за 10 часов набирается порядка 70 тысяч элементов). Старые куски этих таблиц надо периодически удалять ограничивая их общий объем 1- 10 тысячами элементов. Это, между прочем, оказывается определенной проблемой, -- я не вижу стандартного  инструмента. Многократное удаление отдельных элементов с использование table.remove и перенумерацией массива занимает много времени. В частности, удаление половины первых элементов из массива длинной 10000 у меня заняло 6 секунд! Косые способы решения этой проблемы обсужу в новой теме.  
 
Вот, собственно, картинка использования памяти наиболее тяжелым скриптом
С чем связана "гребенка", мне кажется понятным -- это работа сборщика мусора.
А вот почему объем памяти большую часть времени увеличивается маленькими скачками с длинными плато, не совсем понимаю.
 
Стандартная схема работы виртуальных машин:
1) выделяем какой-то объём памяти для работы;
2) работаем, периодически вызывая сборщик мусора (мелкая гребёнка);
3) если после сборки мусора осталось мало свободной памяти, выделяем больше памяти (периодическое повышение объёма) и продолжаем работать с пункта 2).
Продвинутые виртуальные машины умеют уменьшать объём выделенной памяти, если потребность в ней снизилась. Похоже, что виртуальная машина lua к таким не относится.
 
Цитата
_sk_ написал:
Стандартная схема работы виртуальных машин:
1) выделяем какой-то объём памяти для работы;
2) работаем, периодически вызывая сборщик мусора (мелкая гребёнка);
3) если после сборки мусора осталось мало свободной памяти, выделяем больше памяти (периодическое повышение объёма) и продолжаем работать с пункта 2).
Продвинутые виртуальные машины умеют уменьшать объём выделенной памяти, если потребность в ней снизилась. Похоже, что виртуальная машина lua к таким не относится.
Вы не правильно понимаете работу VMLua.
Память выделяется при создании таблиц и их заполнении.
Сборщик мусора запускается по времени.
Время его запуска можно установить (можно вообще отключить сборщик).
сборщик проверяет ссылки и если на данную область ссылок нет то отправляет эту область в кучу.
таким образом уменьшается область занятой памяти.
----------------------
Если желаете экономить память и при этом существенно ускорить работу скриптов, то используйте всюду где можно local.
 
Цитата
Николай Камынин написал:
то отправляет эту область в кучу.
А когда куча чистится?
 
Цитата
Иван Ру написал:
Спасибо всем, в особенности  _sk_ , за советы!
Сообщаю предварительные выводы.
Особых событий перед падением скриптов нет, обычно крашу случается по истечение нескольких часов после их запуска, что наводит на мысль о постепенном заполнении памяти в ходе работы скриптов.
Логгирование это подтвердило -- происходит плавный рост использования памяти с течение времени в обоих моих основных скриптах, в особенности в последнем сварганенном.
Собственно, я получил то что и должен был получить -- он сохраняет в таблицу последние bid, ask два раза в секунду и данные по сделкам по ВСЕМ фьючерсам. Каждый час объем памяти используемый этим скриптом растет приблизительно на 150 мегабайт. Падает чаще всего второй скрипт, который сохраняет меньше данных, но, по-видимому, делает это (т.е. обращается к памяти) чаще.
Я полагаю что ручной запуск сборщика мусора мне мало чем поможет, т.к. проблема не в большом объеме мусорных данных, а в огромных таблицах (за 10 часов набирается порядка 70 тысяч элементов). Старые куски этих таблиц надо периодически удалять ограничивая их общий объем 1- 10 тысячами элементов. Это, между прочем, оказывается определенной проблемой, -- я не вижу стандартного  инструмента. Многократное удаление отдельных элементов с использование table.remove и перенумерацией массива занимает много времени. В частности, удаление половины первых элементов из массива длинной 10000 у меня заняло 6 секунд! Косые способы решения этой проблемы обсужу в новой теме.
Это пример очень плохого скрипта.
Зачем Вы храните все bid, ask с шагом 0.5 в таблице?
Вы что обрабатываете всю таблицу от начал каждую секунду?
Если нет, но хотите сохранить ( аля плюшкин, выбросить жалко, а нести тяжко), то пишите в файл.
в результате у Вас освободится 90% занятой памяти.
----------------------------
Хороший алгоритм реального времени - это тот, в котором нет обработка данных в цикле.
 
Цитата
Николай Камынин написал:
Зачем Вы храните все bid, ask с шагом 0.5 в таблице?
Вы что обрабатываете всю таблицу от начал каждую секунду?
Присоединяюсь к вопросу.
С какой целью это делается?
 
Я не претендую на звание хорошего программиста и отчасти согласен с высказанными замечаниями, но все же вопрос не в качестве моего кода, а в принципиальной проблеме языка. Записывать в файл - не вариант, т.к. это существенно понизит быстродействие при расчетах.

Я продолжил исследование проблемы not enough memory и увидел, что мой первоначальный вывод не вполне верен. После добавления функции обрезки массивов объем памяти используемой скриптами сократился до (не более) 150 мегабайт (300 в сумме). Монитор показывает, что объем памяти используемый рабочим местом quik не превышает 2 Гб. Однако ошибка все равно выскакивала несколько раз, кроме того в последний раз, при переключении на тиковый график терминал уже сам выкинул ошибку "Недостаточно памяти для отображения данных" (в этот момент монитор показал, что квик занимает где-то полтора ГБ, резерв памяти и ресурсов процессора есть).
В терминал у меня открыты следующие окна:
- 2 портфеля (ТО, Т2)
- сделки
- заявки
- текущие торги, все фьючи
- текущие торги, все акции
- около десяти минутных и часовых графиков
- два тиковых графика (в привязке к выбранным в других таблицах инструментам)_
- одно окно котировок.

В чем дело? Похоже в работе терминала?
П.С. Бывает, я его не перезагружаю 2-3 дня.  
 
Цитата
Николай Камынин написал:
Это пример очень плохого скрипта.
Зачем Вы храните все bid, ask с шагом 0.5 в таблице?
Вы что обрабатываете всю таблицу от начал каждую секунду?
Если нет, но хотите сохранить ( аля плюшкин, выбросить жалко, а нести тяжко), то пишите в файл.
Я не думаю, что опыт позволяет написать мне качественный код, однако, не стал бы столь решительно судить о нем по отдельным по внешним признакам :-)
Конечно определенный смысл именно в таком подходе для меня есть. В определенные "критические", скажем так, моменты времени, мне надо подсчитывать разнопериодные средние (не по барам, а в привязке к критической точке), при этом делать это надо максимально быстро. По последней причине запись в файл для меня неприемлема, т.к. процедура открытия/чтения занимает время. Единственный выход - работать на укороченной истории.  Если Вы предложите лучшее и более качественное решение моей задачи -- буду только признателен :-)
 
Цитата
Иван Ру написал:
Цитата
Николай  Камынин   написал:
Это пример очень плохого скрипта.
Зачем Вы храните все bid, ask с шагом 0.5 в таблице?
Вы что обрабатываете всю таблицу от начал каждую секунду?
Если нет, но хотите сохранить ( аля плюшкин, выбросить жалко, а нести тяжко), то пишите в файл.
Я не думаю, что опыт позволяет написать мне качественный код, однако, не стал бы столь решительно судить о нем по отдельным по внешним признакам :-)
Конечно определенный смысл именно в таком подходе для меня есть. В определенные "критические", скажем так, моменты времени, мне надо подсчитывать разнопериодные средние (не по барам, а в привязке к критической точке), при этом делать это надо максимально быстро. По последней причине запись в файл для меня неприемлема, т.к. процедура открытия/чтения занимает время. Единственный выход - работать на укороченной истории.  Если Вы предложите лучшее и более качественное решение моей задачи -- буду только признателен :-)
Есть два способа написать хороший скрипт.
Первый - Вы знаете.
Второй -  изучать существующие технологии разработки подобного класса алгоритмов.
------------------------
Есть два вида программ.
один из них - это программы реального времени. К ним относятся торговые роботы, работающие в реале.
Они имеют одну особенность - их скорость работы в реале определяется временем выполнения наиболее длинной операции.
У Вас - это подсчитывать разнопериодные средние.
Для вычисления средней в правильном алгоритме надо три арифм операции на тик вне зависимости от длины истории (N).
В вашем алгоритме надо N операций.
Можете посчитать время исполнения.
------------------------
Кроме того, за восемь часов торгов вы получаете примерно 60 тысяч пар  bid, ask .
Что-то я сомневаюсь, что Вы считаете среднее с N=60000.
Но тогда зачем это все хранить?
Надо делать скользящее окно по максимальному N.
А еще более эффективнее это переходить от средней к скользящей или к медиане.
--------------------------------
Успехов
 
Цитата
Николай Камынин написал:
Надо делать скользящее окно по максимальному N
Y
Согласен. Собственно здесь и обсуждалась качественная реализация этого решения. Я встроил собственное решение в оба скрипта, первый день - работает все нормально и оперативно. Меня удивляет, что в луа нет встроенного механизма "обрезки" части массива.  
 
Я все же неверно определил источник проблемы, которая, к сожалению сохраняется. Теперь уже в самом терминале появляется сообщение "Операция не может быть выполнена т.к. недостаточно памяти". При этом объем памяти используемый двумя скриптами  составляет порядка 2х150 = 300 мб, а совокупный объем памяти занятой терминалом (в тот же момент смотрел через диспетчер задач) -- 1,5 Гб. Вообще последний показатель никогда не превышает 2,5 Гб, т.е. ресурс не выбран.
Что у меня включено:
- трансляция обезличенных сделок (около 5 полей по 160 инструментам - все фьючи).
- 2 окна "Текущие торги" - все фьючи и все акции, порядка 10 полей в каждом.
- 2 тиковых графика
- 2 стакана
- около 15 окон с графиками
- 2 окна с портфелями Т2 и Т0.

Отключение тиковых графиков проблему не решает, а вот отключение трансляции обезличенных сделок -- по первым ощущения ее устраняет. Мне они категорически нужны, не понимаю что делать.  
 
Иван Ру,

Если требуется анализ, пришлите на quiksupport@arqatech.com архив всей папки с терминалом QUIK (без ключей доступа)
Архив следует паковать при закрытом терминале и в момент возникновения проблемы.
В теме письма укажите ссылку на эту ветку форума.
 
Цитата
Отключение тиковых графиков проблему не решает, а вот отключение  трансляции обезличенных сделок -- по первым ощущения ее устраняет. Мне  они категорически нужны, не понимаю что делать.

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

Для минимизации вероятности проблем можно перезапускать терминал каждый день или через день.

Конечно, хотелось бы, чтобы разработчики пофиксили причину, поскольку регулярный перезапуск терминала делать неудобно.
 
Увы, проблема продолжается в разных ипостасях.
Теперь периодически начали появляться сообщения другого рода -- просто ошибка, после которой терминал предлагает включить отладку или закрыть себя или сообщение "Не хватило памяти под объекты, без которых терминал работать не может..."
Сообщения появляются обычно вечером после многих часов работы терминала.
Какое-то время еще была проблема с очень долгим запуском (по пол часа), сейчас вроде нет.
Удаление файлов alltrades.log и info.log проблему с дефицитом памяти и крашем терминала не решает.  
 
Цитата
Иван Ру написал:
Я все же неверно определил источник проблемы, которая, к сожалению сохраняется. Теперь уже в самом терминале появляется сообщение "Операция не может быть выполнена т.к. недостаточно памяти". При этом объем памяти используемый двумя скриптами  составляет порядка 2х150 = 300 мб, а совокупный объем памяти занятой терминалом (в тот же момент смотрел через диспетчер задач) -- 1,5 Гб. Вообще последний показатель никогда не превышает 2,5 Гб, т.е. ресурс не выбран.
Что у меня включено:
- трансляция обезличенных сделок (около 5 полей по 160 инструментам - все фьючи).
- 2 окна "Текущие торги" - все фьючи и все акции, порядка 10 полей в каждом.
- 2 тиковых графика
- 2 стакана
- около 15 окон с графиками
- 2 окна с портфелями Т2 и Т0.

Отключение тиковых графиков проблему не решает, а вот отключение трансляции обезличенных сделок -- по первым ощущения ее устраняет. Мне они категорически нужны, не понимаю что делать.
Могу дать следующие советы.
1) Удалите из ТТП те акции, которыми не торгуете и фьючерсы которыми не торгуете.  Но удалять надо из заказа данных.
2) Удалите параметры, которые не используете.
3) Проверьте отключены ли у Вас опционы.
4) Посмотрите сколько в действительности у Вас выбрано инструментов и параметров (В окне выбор принимаемых параметров и инструментов)
5) Попробуйте работать с включенным флагом "Только данные, отражающие текущее состояние" (Настройки клиентского места)
-----------------------------------
Пишите, какой результат.
 
Очень хочется, чтобы хоть у кого-то получилось понять, как гарантированно воспроизвести проблемы, подобные описанным выше. У меня не получилось, хотя я даже некий скрипт специально писал и отправлял разработчикам для тестов. Пока не будет чёткого алгоритма воспроизведения проблемы разработчики нам вряд ли помогут, к сожалению.
 
Цитата
Николай Камынин написал:
Цитата
Иван Ру   написал:
Я все же неверно определил источник проблемы, которая, к сожалению сохраняется. Теперь уже в самом терминале появляется сообщение "Операция не может быть выполнена т.к. недостаточно памяти". При этом объем памяти используемый двумя скриптами  составляет порядка 2х150 = 300 мб, а совокупный объем памяти занятой терминалом (в тот же момент смотрел через диспетчер задач) -- 1,5 Гб. Вообще последний показатель никогда не превышает 2,5 Гб, т.е. ресурс не выбран.
Что у меня включено:
- трансляция обезличенных сделок (около 5 полей по 160 инструментам - все фьючи).
- 2 окна "Текущие торги" - все фьючи и все акции, порядка 10 полей в каждом.
- 2 тиковых графика
- 2 стакана
- около 15 окон с графиками
- 2 окна с портфелями Т2 и Т0.

Отключение тиковых графиков проблему не решает, а вот отключение трансляции обезличенных сделок -- по первым ощущения ее устраняет. Мне они категорически нужны, не понимаю что делать.
Могу дать следующие советы.
1) Удалите из ТТП те акции, которыми не торгуете и фьючерсы которыми не торгуете.  Но удалять надо из заказа данных.
2) Удалите параметры, которые не используете.
3) Проверьте отключены ли у Вас опционы.
4) Посмотрите сколько в действительности у Вас выбрано инструментов и параметров (В окне выбор принимаемых параметров и инструментов)
5) Попробуйте работать с включенным флагом "Только данные, отражающие текущее состояние" (Настройки клиентского места)
-----------------------------------
Пишите, какой результат.
Я оставил заказ данных только на фьючерсы, пробовал удалять файлы info.log и alltrade.dat, сократил количество параметров до минимума. К сожалению не помогает. Хотя изменился характер ошибок. Теперь чаще наблюдается краш программы (предлагает отладку или закрыть) или сообщение "не хватило памяти под объекты..." В момент краша общий объем используемой памяти, как показывает монитор Windows - 1-2 ГБ.  
 
сделайте это (из предыдущих советов):
5) Попробуйте работать с включенным флагом "Только данные, отражающие текущее состояние" (Настройки клиентского места)
 
еще могу предложить сделать следующее.
установить квик в новый каталог и заново настроить окна (ничего из старого, кроме своих скриптов не брать)
 
и еще, самое главное:
Уберите свои скрипты и посмотрите как будет работать. С этого надо было начинать. Но можно и закончить этим.
 
Цитата
Николай Камынин написал:
и еще, самое главное:
Уберите свои скрипты и посмотрите как будет работать. С этого надо было начинать. Но можно и закончить этим.
Пункт 5 пробовал.
Полное удаление и переустановку пробовал, правда, ставил в тот же каталог.
Отключать скрипты пробовал и, еще раз, -- я внутри них вставил контроль объема памяти. Сейчас они забирают не более 500 мб в сумме. Кроме того, иногда квик крашится уже после 23.50, когда у меня скрипты автоматически останавливаются.  
Вот вчера квик ни разу не упал -- редкий удачный день!
П.С. Переслал письмо с архивом рабочего места и пометкой для Вас.  
 
Еще можно сделать следующее.
1) Попробуйте еще не загружать никаких приложений, в том числе и браузер, кроме квик.
2) Если умеете, то попробуйте оптимизировать службы винды, уберите, которые не нужны, чтобы освободить память.
 
и еще посмотрите свободное место на диске, на котором файл подкачки.
 
Цитата
Иван Ру написал:
П.С. Переслал письмо с архивом рабочего места и пометкой для Вас.
Да отправляли но без info.log и без alltrade.dat
Мы же запросили полный архив со всеми файлами, кроме ключей доступа
и так его и не получили
 
Цитата
Sergey Gorokhov написал:
Цитата
Иван Ру   написал:
П.С. Переслал письмо с архивом рабочего места и пометкой для Вас.
Да отправляли но без info.log и без alltrade.dat
Мы же запросили  полный  архив  со всеми  файлами, кроме ключей доступа
и так его и не получили
??? 14 августа в 13:07 было отправлено повторное письмо со ссылкой на архив, где эти файлы находятся, только что перепроверил
 
Иван Ру,
Да действительно, от Вас было письмо, но оно пришло в личную почту. Убедительная просьба все письма писать с копией на адрес quiksupport@arqatech.com. Так как сотрудник которому Вы отправляете личную почту может не быть на рабочем месте.

В Вашем письме, нет ссылки для скачивания, а старая ссылка уже не работает.
Отправьте повторно всю папку с терминалом (без ключей доступа).
Архив следует паковать при закрытом терминале и в момент возникновения проблемы.

Дополнительно, просьба прислать lua скрипт на котором возникает проблема.
Заранее спасибо.
 
Уважаемая поддержка!!

так что с 64 битной версией квик в новом 2018 году? хоть когда нибудь вы сможете обновить умирающее свое детище? Работать просто невозможно становится в квике с парой луаскриптов. Сообщения что недостаточно памяти просто замучали!
с каждой новой версией квика 7.12 потом 13 и 14 и памяти остается все меньше и меньше а работать все сложнее и сложнее что хочется выбросить это все нахрен и перейти на более адекватную программу.
на нормальной мощной RAM64гб машине невозможно работать в этой убогой программе. эта узкая дверь просто не дает прохода и возможности для развития!

Сколько будет продолжаться этот прошлый век? не хотите раздавать бесплатно так продавайте за деньги! но сколько можно все это продолжать!
Страницы: 1
Читают тему
Наверх