Quik 8.8.1.5 Ребят, ну что за дела, а? Ну объясните вот, ну как так можно писать софт, что у вас постоянно то утечка памяти сжирает всю раму, то ему блин свап нужен размером с раму. Ну а если у меня 128 гиг, вы реально предлагаете мне файл подкачки еще 128 гиг создавать? Ну серъезно, что за хрень то??? Ну выделяете вы руками память, ну блин, неужели сложно прибить объект? За такое в приличном опыте просто по рукам бьют. Когда уже нормальная версия выйдет, чтобы я не думал о том, что сейчас обновлюсь и меня какой-нибудь очередной сюрприз будет ожидать.
Правильно понимаем, что связываете утечку памяти именно с тем, что после обновления до версии 8 рабочее место стало потреблять примерно 2ГБ ОЗУ, а до обновления, на версии 7 и старее - <1ГБ? Если так, то сам повышенный объём потребления памяти является нормальное ситуации при переходе от x32 архитектуры программы к x64. Сам объём потребляемой при этом ОЗУ лежит в пределах нормы и не даёт оснований считать его аномальным в текущей формулировке Вашего вопроса. Наиболее вероятно, в результате обновления были переопределены некоторые настройки получения и сохранения данных, которые привели к неоптимальной работе терминала и, как следствие, повышенному объёму используемой ОЗУ. Для оптимизации рабочего места предлагаем выполнить следующую инструкцию.
1. Система/Настройки/Основные настройки/Программа/Получение данных: 1) включите настройку "Запрашивать данные раз в" и установите хотя бы 1 секунду обновления данных; 2) включите настройку "Исходя из открытых пользователем таблиц".
2. Система/Настройки/Основные настройки/Программа/Сохранение данных: 1) если включена настройка "Данные, отражающие текущее состояние и всю историю изменений" и "Получать пропущенные данные" - отключите опцию "Получать пропущенные данные" и выполните перезаказ данных с указанием только данных текущей торговой сессии (Система/Заказ данных/Перезаказать данные); проверьте объём потребляемой ОЗУ; 2) если п 2.1 не дал результата - включите опцию "Только данные, отражающие текущее состояние" и выполните перезаказ данных с указанием только данных текущей торговой сессии (Система/Заказ данных/Перезаказать данные); проверьте объём потребляемой ОЗУ;
Вместе с тем, если при низком объёме используемой ОЗУ (например, 30% ) Вы получаете приведённое Выше предупреждение Windows - предлагаем проинспектировать Ваши текущие настройки управления памятью Вашего ПК и при необходимости скорректировать их. Необходимые инструкции и рекомендации по данному вопросу Вы можете получить у технической поддержки Microsoft, или в каких-либо иных открытых источниках информации.
В общем, настройки проблему не решают. Временное решение проблемы - дать системе возможность выбирать размер файла подкачки автоматически. В итоге винда отожрала помимо 24 гиг рамы еще и 24 гига свопа. Это #%$ец...... просто свинство. Получается на кой хрен ставить 24 гига, чтобы еще 24 отожралось на SSD? Бред. Это единственный случай с такой ошибкой на моей практике. У меня даже вегас, жрущий раму сколько найдет - такого себе не позволял делать... Я вот хоть убейте не понимаю КАК и главное ЗАЧЕМ так выделять память в приложении...
Это не утечка же ж, физическая память 30% (внизу на скрине). Я б в первую очередь подумал, что у вас своп отключен или квоты какие-то стоят.
Ну подобное поведение мягко говоря настораживает. :) Я сам пишу, поэтому о выделении памяти зачем и сколько представление имею. Своп 4 гига фиксированно. Не вижу смысла увеличивать. Наоборот, при 24 гигах рамы своп объективно не нужен. Либо чисто символически пару гиг - для особо принципиальных программ. ;)
Брокер сбер. Обновился до 8.3.1.38. Теперь квик постоянно крашит систему из-за утечки памяти. Вплоть до невозможности запуска других приложений. Win 7 x64 Pro, 24 оперативы. Это жесть, товарищи... вы чего там наделали с ним?
AndyJOKER написал: Весело. Я правильно понимаю, что фактически в индикаторах можно использовать только данные O, H, L, C, V, T , Size ?
Нет, категорически не верно, можно и другие данные, зависит от того что Вам нужно. Если Вам нужно получить данные в индикаторе из другого скрипта, то почему бы не воспользоваться обменом через файлы? Один сприпт пишет в файл, другой читает.
Эммм, несколько странно слышать это от Вас, как от разработчика. Разумеется, у меня большая часть подобного "обмена" реализована. Не не через файлы, а через mysql. Но это же костыль... Некошерно такое делать. Согласитесь, что намного быстрее и удобнее обращаться к таблицам внутри памяти квика (не важно "стандартные" или созданные юзером) через getcell или getitem, чем вешать индикатор ожидая обращения к файлу или запроса от БД? Интересно, в чем проблема в реализации? Много обработчиков писать?
Всем доброго! Суть: скрипт создает и постоянно обновляет произвольную таблицу с данными. Индикатор обращается по t_id к таблице и забирает оттуда данные. Например, пусть заполняется так:
Код
t_id = AllocTable()
AddColumn(t_id, 1, "1", true, QTABLE_DATE_TYPE, 15)
AddColumn(t_id, 2, "2", true, QTABLE_TIME_TYPE, 15)
AddColumn(t_id, 3, "3", true, QTABLE_INT_TYPE, 15)
AddColumn(t_id, 4, "4", true, QTABLE_INT_TYPE, 15)
t = CreateWindow(t_id)
for f = 0, 99 do
InsertRow(t_id, -1)
a = math.random(1000, 3000)
SetCell(t_id, f, 3, tostring(a), a)
a = math.random(1000, 3000)
SetCell(t_id, f, 4, tostring(a), a)
end
Индикатор, например, пусть будет так:
Код
Settings={
Name="TEST",
t_id=14,
line=
{
{
Name = "Val",
Type =TYPE_LINE,
Width = 1,
Color = RGB(255,0,0)
}
}
}
function Init()
return 3
end
function OnCalculate(index)
local val
if index == 1 then
val = GetCell(Settings.t_id, 1, 3).value
end
return nil
end
Валится с ошибкой "attempt to call global 'GetCell' (a nil value)". Я что-то страшное делаю или просто руки кривые?
Александр Копяткевич написал: Графики строятся по данным таблицы "Обезличенные сделки", поэтому не стоит сравнивать данные графика с данными из стакана котировок.
Тогда могу лишь предположить, что завис какой-то из индюков...
По приложенному Вами видео не видно, что есть какая-то проблема. Так как график у Вас с интервалом 5 минут, и на последней свечке время 10:40, то, следующая свечка должна появиться только в 10:45.
Внимательно еще раз посмотрите видео. Цена в стакане меняется, а на графике нет. Причем тут М5 или М1?
Здравствуйте! QUIK 7.19.3.1 Брокер Сбер. На ровном месте просто перестал обновляться график инструмента, в то время как в стакане котировок и таблице торгов всё вполне себе работало. Что самое фиговое - перестал срабатывать OnAllTrade в скрипте. Т.е. по сути состояние OnConnected, но как будто сделок то и нет. Это ладно я был за терминалом. И как теперь с этим вот всем жить... https://youtu.be/ENYyBdm19Xs
Приветствую! QUIK 7.14.1.7 В фильтре инструментов в получении данных потока обезличенных сделок были: RIM8, SiM8, BRM8. BRM8 сменился на BRN8. Подтвердил замену в системе. Он взял и нафиг повыкидывал из фильтра RIM и SiM, оставивив лишь BRN. Это прикол такой чтоли? Спасибо.
Вторая проблема также решена. Пример для таблицы обезличенных сделок:
Код
CRE ATE TABLE `temp` (
`id` int(10) UNSIGNED NOT NULL,
`t_date` char(10) NOT NULL,
`t_time` time NOT NULL,
`t_price` decimal(6,2) UNSIGNED NOT NULL,
`t_val` int(11) NOT NULL,
`t_op` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;
CRE ATE TABLE `tick` (
`id` int(10) UNSIGNED NOT NULL,
`t_d` date NOT NULL,
`t_t` time NOT NULL,
`t_p` decimal(6,2) UNSIGNED NOT NULL,
`t_v` int(10) UNSIGNED NOT NULL,
`t_op` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;
Триггер:
Код
CREATE TRIGGER `temp` BEFORE INSERT ON `temp`
FOR EACH ROW BEGIN
INS ERT IN TO tick VALUES(NEW.id, STR_TO_DATE(NEW.t_date,'%d.%m.%Y'), NEW.t_time, NEW.t_price, NEW.t_val, NEW.t_op);
END
CREATE TRIGGER `trig` BEFORE INSERT ON `temp`
FOR EACH ROW BEGIN
INS ERT IN TO ticks (`tick_date`,`tick_time`,`tick_price`,`tick_val`) VALUES (NEW.dat, NEW.tim, NEW.price, NEW.val);
END
Ни так:
Код
CREATE TRIGGER `trig` BEFORE INSERT ON `temp`
FOR EACH ROW BEGIN
INS ERT IN TO ticks (`tick_date`,`tick_time`,`tick_price`,`tick_val`) VALUES (STR_TO_DATE(NEW.dat,'%d.%m.%Y'), NEW.tim, NEW.price, NEW.val);
END
Ни так:
Код
CREATE TRIGGER `trig` BEFORE INSERT ON `temp`
FOR EACH ROW BEGIN
INS ERT IN TO ticks (`tick_date`,`tick_time`,`tick_price`,`tick_val`) VALUES (DATE_FORMAT(NEW.dat,'%d.%m.%Y'), NEW.tim, NEW.price, NEW.val);
END
Ни так:
Код
CREATE TRIGGER `trig` BEFORE INSERT ON `temp`
FOR EACH ROW BEGIN
INS ERT IN TO ticks (`tick_date`,`tick_time`,`tick_price`,`tick_val`) VALUES (CONVERT(NEW.dat,DATE), NEW.tim, NEW.price, NEW.val);
END
Неужели я первый, кто выбрал связку QUIK -> ODBC -> MySQL...
Еще одна проблема. Формат даты в MySQL по-умолчанию имеет вид 'YYYY-DD-MM', и, насколько мне известно изменить его нельзя. Т.е. работать приходится через:
Код
INS ERT IN TO `table` (`dat`) VALUES (STR_TO_DATE('13.12.2017','%d.%m.%Y'))
Поэтому в итоге получаем: В обмене данными через ODBC не специалист, поэтому вопрос: самостоятельно руками в QUIK можно где-нибудь добавить для всех INSERT STR_TO_DATE или это всё hard-coded? Попутно просьба ткнуть носом где удалось подружить QLUA и MySQL - пока в качеств временного решения проблемы. Благодарю.
Здравствуйте! При выборе сопоставляемого поля MySQL таблицы для параметра "Инструмент" доступны почему-то только типы: DATE, TIME, DATETIME. Все остальные доступные типы (TEXT, CHAR, VARCHAR) в выпадающем списке просто отсутствуют, хотя это самый что ни на есть TEXT. ЧЯДНТ?
Приветствую! Пытаюсь разобраться почему разъезжаются мои расчетные данные %K от QUIKовских на стохастике. Беру дефолтные значения: %K периодов: 5. Сглаживание: 3 Тип сглаживания как я понимаю simple moving average. Далее шаги на примере экселя: 1. Начиная с 5го отсчета считаем минимумы (MIN) и максимумы (MAX) значений LOW и HIGH за предыдущие 4 периода и 1 текущий. 2. Начиная с 5го отсчета считаем %K=(CLOSE-MIN)/(MAX-MIN)*100. На данном шаге значение %K полностью соответствует квиковскому со сглаживанием %K равным 1. 3. Начиная с 7го отсчета считаем SMA %K со сглаживанием 3 как среднее значение %K предыдущих 2 периодов и 1 теукщего. На этом шаге, собственно, данные и разнятся.