1. Некорректный расчет стоимости портфеля по клиентам со схемой кредитования МД+ при использовании валюты в качестве базового индикатора при настройке множеств с зависимыми ценами. 2. После редактирования пользователем настроек индикатора его целочисленные параметры ошибочно становились вещественными. 3. При смене учетной записи на графиках ошибочно отображались заявки и сделки предыдущего пользователя. 4. Ошибка, которая в некоторых случаях приводила к отображению пустых строк в Таблице заявок. 5. Ошибка, которая при закрытии таблицы, созданной при помощи скрипта Lua, могла приводить к зависанию Рабочего места QUIK. 6. В некоторых случаях в таблицах «Позиции по деньгам» и «Позиций по инструментам» могли отображаться ранее удалённые позиции. 7. Ошибка, из-за которой в некоторых случаях не отображались данные в таблице «Состояние счёта».
Уважаемые разработчики, то что Quik 8.8 перестал падать это большой прогресс, но он стал непомерно жрать память! Смотрите скрин.
К сожалению не смотрел специально какое потребление памяти было у версии 8.7, НО у версии 8.6 оно не превышало 500-600 мегабайт, при ровно тех же запущенных скриптах. Откуда такая дикая прожорливость у версии 8.8 ?
Более того. Даже без запущенных скриптов, открыто всего несколько вкладок с графиками и различными таблицами, Quik 8.8 жрет 2,5 гигабайта памяти, и это ВНЕ торговой сессии!
Юрий написал: Уважаемые разработчики, то что Quik 8.8 перестал падать это большой прогресс, но он стал непомерно жрать память! Смотрите скрин.
К сожалению не смотрел специально какое потребление памяти было у версии 8.7, НО у версии 8.6 оно не превышало 500-600 мегабайт, при ровно тех же запущенных скриптах. Откуда такая дикая прожорливость у версии 8.8 ?
Цитата
Юрий написал: Более того. Даже без запущенных скриптов, открыто всего несколько вкладок с графиками и различными таблицами, Quik 8.8 жрет 2,5 гигабайта памяти, и это ВНЕ торговой сессии!
Добрый день.
Пришлите нам на quiksupport@arqatech.com дамп процесса info.exe (делается через диспетчер задач), сделанный во время проявления проблемы, а также архив Вашего терминала QUIK (после снятия дампа отключиться от сервера, закрыть терминал, сделать копию папки с ним, заархивировать копию, прислать нам). Если возможно - то вместе с используемыми скриптами. В теме письма нужно указать ссылку на данную ветку форума.
Кажется я разобрался. Проблема была в ключе запуска -full-dump который мне рекомендовала указывать техподдержка для выявления причин падения прошлых версий. Убрал данный ключ и потребление памяти пришло в норму.
Старатель, К сожалению у нас проблема не повторяется. Проверяли на версии 8.8.0 Просьба воспроизвести проблему с зависанием, после чего снять дамп процесса info.exe (через диспетчер задач Windows) и прислать его нам на quiksupport@arqatech.com
Действительно в ПО QLUA есть ошибка так же иногда приводящая к завистанию терминала при вызове Lua функции DestroyTable. Мы исправим её в очередном обновлении ПО. Приносим извинения за доставленные неудобства.
И всё-таки чрезмерное потребление памяти присутствует. Сначала при запуске вроде все нормально но поработав какое то время у меня снова потребление зашкаливает за 3 гигабайта. Ссылку на дамп процесса квика отправил на почту.
И сделайте пожалуйста возможность изменения сортировки запущенных lua скриптов в списке с помощью мыши или еще как... Чтобы можно было самостоятельно установить где какой скрипт в списке располагается.
Sergey Gorokhov написал: Действительно в ПО QLUA есть ошибка так же иногда приводящая к завистанию терминала при вызове Lua функции DestroyTable. Мы исправим её в очередном обновлении ПО.
Как скоро? Временное решение есть?
Надо делать так, как надо. А как не надо - делать не надо.
Ему волю дай так он всю возможную память сожрет... Не разобрались еще в проблеме? Хотя бы выяснили в чем причина?
И еще, раньше закрепленный на панели быстрого запуска квик запускался и закрепленный значек его становился активным, а сейчас вместо этого создается второй значек. Нельзя ли вернуть как было?
Вот зачем второй создается когда должен становиться активным первый который закреплен.
Ему волю дай так он всю возможную память сожрет... Не разобрались еще в проблеме? Хотя бы выяснили в чем причина?
Проверьте на предмет "поврежденных" открытых графиков. Т.е. повреждены данные. У меня были такие после обновления. Выявил путем последовательного закрытия и перезапуска. У меня отжирал всю виртуальныю память.
Еще на версии 8.х самопроизвольно в таблицу текущих торгов и в настройки закзанных потоков данных добавляются инструменты. Обычно это фьючерсные контракты. Каждый раз убираешь и снова сами добавляются. Скажете, что брокер, но у меня вопрос - почему у брокера есть возможность добавлять мне в поток и в таблицы данные.
Ему волю дай так он всю возможную память сожрет... Не разобрались еще в проблеме? Хотя бы выяснили в чем причина?
Проверьте на предмет "поврежденных" открытых графиков. Т.е. повреждены данные. У меня были такие после обновления. Выявил путем последовательного закрытия и перезапуска. У меня отжирал всю виртуальныю память.
Еще на версии 8.х самопроизвольно в таблицу текущих торгов и в настройки закзанных потоков данных добавляются инструменты. Обычно это фьючерсные контракты. Каждый раз убираешь и снова сами добавляются. Скажете, что брокер, но у меня вопрос - почему у брокера есть возможность добавлять мне в поток и в таблицы данные.
Я бы еще понял если бы только на одном компьютере проблема с потреблением памяти была, но она как минимум на двух мне доступных, где разные графики, и все они вполне себе работают, не повреждены.
А что до самопроизвольного добавления инструментов, проверьте не стоит ли у вас галочка в "Настройки->Основные->Программа->Получение данных->При получении нового инструмента добавлять его во все таблицы." Если стоит то надо снять сохранить и перезапустить квик.
К сожалению, приходится наблюдать, как катастрофически падает профессионализм управленческих кадров в России, определяющих, что надо делать. ARQU вместо того, чтобы устранять ошибки версий 8.4…, улучшать функциональность, надежность и эффективность QUIK (и тут имеется широкие возможности), решила сделать маркетинговый ход и «поразить» пользователей переходом с Lua 5.1 на 5.3. Тут надо понимать, что функционально, с учетом архитектурно тесной интеграции Lua c языком C/C++, это, мягко говоря, сомнительный шаг, так как все, что не реализовано в Lua 5,1, по сравнению с Lua 5.3 (а это мало кому нужно), можно реализовать в языке C++.
Кроме того, история с многочисленными проблемами реализации собственного, потокобезопасного управления автоматической памятью QLua 5.1, была, похоже, была проигнорирована. Вместо элементарной реализации в версии 8.4…. произвольной длины номеров заявок (> 19 знаков) был выбран нелегкий путь («нормальные» герои всегда идут в обход).перехода на Lua 5.3… (в котором существенно изменилось управление автоматической памятью и которое в QLua 5.3…, в отличие от Lua 5.3…, необходимо переработать так, чтобы оно было потокобезопасным). Необходимость потокобезопасности управления автоматической памятью QLua обусловлена тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя.
Что мы имеем на текущий момент (12.08.20). Пользователи отлаживают, начиная с марта 2020г.все новые и новые версии (8.5…, 8.6…, 8.7…, 8.8…). Прошло уже 5 месяцев как нас кормят обещаниями стабильной новой версии QUIK. При запусках моего теста управления автоматической памятью во всех QLua версиях >= 8.5 в произвольные моменты времени, но в интервале 10 минут, возникают дампы ( все они пересланы мной в поддержку ARQU). Причем в QUIK версий < 8.5 проблем с управлением автоматической памятью QLua мной не обнаружено.
Пока в версии >= 8.5 не будет реализовано корректное (пусть и не самое эффективное) потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).
Повышенное потребление оперативной памяти при открытых таблицах «Купить/продать» и «Состояние счета».
В некоторых случаях наблюдались расхождения в значениях доходности по облигациям, вычисленных в форме ввода заявки и в Таблице заявок.
При использовании специализированной формы ввода заявок добавление транзакции в карман транзакций могло приводить к отправке данной транзакции в торговую систему.
Некорректный расчет доходности в специализированной форме ввода заявок, который не соответствовал доходности заявки.
Повышенное потребление оперативной памяти при открытых таблицах «Купить/продать» и «Состояние счета».
В некоторых случаях наблюдались расхождения в значениях доходности по облигациям, вычисленных в форме ввода заявки и в Таблице заявок.
При использовании специализированной формы ввода заявок добавление транзакции в карман транзакций могло приводить к отправке данной транзакции в торговую систему.
Некорректный расчет доходности в специализированной форме ввода заявок, который не соответствовал доходности заявки.
Уважаемая техподдержка. Данная версия все еще считается нестабильной? У большинства брокеров максимальная 8.7.1.3.
Я хоть и не техподдержка, но скажу, что начиная с 8.5, чем больше версия, тем стабильнее терминал. Ошибки устраняются быстрее, чем создаются новые, пока что.
Повышенное потребление оперативной памяти при открытых таблицах «Купить/продать» и «Состояние счета».
В некоторых случаях наблюдались расхождения в значениях доходности по облигациям, вычисленных в форме ввода заявки и в Таблице заявок.
При использовании специализированной формы ввода заявок добавление транзакции в карман транзакций могло приводить к отправке данной транзакции в торговую систему.
Некорректный расчет доходности в специализированной форме ввода заявок, который не соответствовал доходности заявки.
Уважаемая техподдержка. Данная версия все еще считается нестабильной? У большинства брокеров максимальная 8.7.1.3.
Добрый день,
Рекомендуем использовать наиболее актуальную версию Рабочего места QUIK, которая доступна для обновления у вашего брокера. Решение о доступности очередной версии брокер принимает самостоятельно.
TGB написал: К сожалению, приходится наблюдать, как катастрофически падает профессионализм управленческих кадров в России, определяющих, что надо делать. ARQU вместо того, чтобы устранять ошибки версий 8.4…, улучшать функциональность, надежность и эффективность QUIK (и тут имеется широкие возможности), решила сделать маркетинговый ход и «поразить» пользователей переходом с Lua 5.1 на 5.3. Тут надо понимать, что функционально, с учетом архитектурно тесной интеграции Lua c языком C/C++, это, мягко говоря, сомнительный шаг, так как все, что не реализовано в Lua 5,1, по сравнению с Lua 5.3 (а это мало кому нужно), можно реализовать в языке C++. Кроме того, история с многочисленными проблемами реализации собственного, потокобезопасного управления автоматической памятью QLua 5.1, была, похоже, была проигнорирована. Вместо элементарной реализации в версии 8.4…. произвольной длины номеров заявок (> 19 знаков) был выбран нелегкий путь («нормальные» герои всегда идут в обход).перехода на Lua 5.3… (в котором существенно изменилось управление автоматической памятью и которое в QLua 5.3…, в отличие от Lua 5.3…, необходимо переработать так, чтобы оно было потокобезопасным). Необходимость потокобезопасности управления автоматической памятью QLua обусловлена тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя. Что мы имеем на текущий момент (12.08.20). Пользователи отлаживают, начиная с марта 2020г.все новые и новые версии (8.5…, 8.6…, 8.7…, 8.8…). Прошло уже 5 месяцев как нас кормят обещаниями стабильной новой версии QUIK. При запусках моего теста управления автоматической памятью во всех QLua версиях >= 8.5 в произвольные моменты времени, но в интервале 10 минут, возникают дампы ( все они пересланы мной в поддержку ARQU). Причем в QUIK версий < 8.5 проблем с управлением автоматической памятью QLua мной не обнаружено. Пока в версии >= 8.5 не будет реализовано корректное (пусть и не самое эффективное) потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).
Скажите а что за тесты вы выполняете? Можно эти тесты выложить, хочется тоже вопрос поисследовать.
https://cloud.mail.ru/public/5iZb/2NSAPmJem - ссылка на мою тестовую программу (с кодами и инструкцией по ее запуску). Старая ссылка удалена. При запуске этой программы дампы возникают быстро (у меня в течении 5 минут), но в произвольные моменты. Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5. Одна из функций данной программы, которая включена сейчас по умолчанию, это тестирование автоматического управления памятью в QLua. Особенностью теста является высокая нагрузка (1500 обращений в секунду) на управление автоматической памятью QLua в условиях многопоточности. Можете также посмотреть обсуждение по ссылке https://forum.quik.ru/forum10/topic5119/?PAGEN_1=3 , начиная с комментария № 145.
TGB написал: https://cloud.mail.ru/public/5iZb/2NSAPmJem - ссылка на мою тестовую программу (с кодами и инструкцией по ее запуску). Старая ссылка удалена. При запуске этой программы дампы возникают быстро (у меня в течении 5 минут), но в произвольные моменты. Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5. Одна из функций данной программы, которая включена сейчас по умолчанию, это тестирование автоматического управления памятью в QLua. Особенностью теста является высокая нагрузка (1500 обращений в секунду) на управление автоматической памятью QLua в условиях многопоточности. Можете также посмотреть обсуждение по ссылке https://forum.quik.ru/forum10/topic5119/?PAGEN_1=3 , начиная с комментария № 145.
Не очень понятно, что вы делаете за тест и результаты теста. Вероятно вам нужно упростить скрипт и выложить простой тестовый пример, избавившись от лишнего. Тогда станет более понятно. Изучать такой объем информации скорее всего никто не будет. Если вы хотите, чтобы быстрее исправили ошибку.
TGB написал: https://cloud.mail.ru/public/5iZb/2NSAPmJem - ссылка на мою тестовую программу (с кодами и инструкцией по ее запуску). Старая ссылка удалена. При запуске этой программы дампы возникают быстро (у меня в течении 5 минут), но в произвольные моменты. Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5. Одна из функций данной программы, которая включена сейчас по умолчанию, это тестирование автоматического управления памятью в QLua. Особенностью теста является высокая нагрузка (1500 обращений в секунду) на управление автоматической памятью QLua в условиях многопоточности. Можете также посмотреть обсуждение по ссылке https://forum.quik.ru/forum10/topic5119/?PAGEN_1=3 , начиная с комментария № 145.
А Ваше решение только под qlua? Тесты на vanilla lua 5.3 не пробовали запускать? Тогда бы было понятно, что проблема именно в реализации qlua.
Да. Нативный Lua однопоточный. QLua многопоточный. Так же можете посмотреть пояснения по выше приведенной ссылке.
Честное слово. Вы написали некоторый черный ящик, который что-то там делает. Что делает не ясно? Что за тест - не ясно? Проверить правильность реализации теста мы конечно же не можем, потому что нет кода. И вы требуете, чтобы поправили ошибку и обвиняете разработчиков. Разработчики не должны разбираться в ваших тестах. Выложите исходники, а еще лучше напишите простой тестовый пример с исходниками, чтобы было понятно, что вы делаете. У меня есть чувство, что вы просто сами себе выстрелили в ногу и теперь бегаете и всем говорите, что вам очень больно. Почему то у меня ни одна программа, написанная на QLua не валится.
По ссылке https://forum.quik.ru/messages/forum10/message48046/topic5119/#message48046 вы можете прочитать, что пишет по этому поводу поддержка QUIK. Приведу от туда лишь короткую цитату: "По указанным номерам зафиксированных нами и указанных Вами инцидентов (CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006) мы ведём активную работу и на момент данного ответа, вопрос о причинах утечки памяти и падения рабочего места остаётся открытым."
TGB написал: "По указанным номерам зафиксированных нами и указанных Вами инцидентов (CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006) мы ведём активную работу и на момент данного ответа, вопрос о причинах утечки памяти и падения рабочего места остаётся открытым."
Там также написано: "Из перечисленных проблем: CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006 открытыми остаются CQ02802279, CQ02809006, по остальным не найдены ошибки на стороне рабочего места QUIK." Подождем увидим.
Цитата
TGB написал: Почему простой тест не получится объясняется в тексте также по приведенной выше ссылке.