Линии на графике являются индикаторами. Когда линия находится сильно высоко от графика, к примеру на 40% выше цены, я бы хотел её не рисовать. Должен быть пропуск, индикатор не рисуется. Но это будет не красиво, потому что КВИК попытается все же соединить последнее значение перед дыркой и первое значение после дырки. Можно ли этого избежать? Можно ли одну линию сделать разноцветной? один участок красный, другой, например, зелёный?
Алексей написал: Здравствуйте, скрипт не хочет отправлять транзакцию на сервер, скрипт запускается, работает, но нечего не происходит, запуск функции для проверки записан в OnInit код транзакции ниже
Код
function test ()
local Transaction = {
[ 'TRANS_ID' ] = tostring(trans_id), -- Номер транзакции
[ 'ACCOUNT' ] = TorShet, -- Код счета
[ 'CLASSCODE' ] = KodClass, -- Код класса
[ 'SECCODE' ] = InstrumentKod, -- Код инструмента
[ 'ACTION' ] = 'NEW_ORDER' , -- Тип транзакции ('NEW_ORDER' - новая заявка)
[ 'OPERATION' ] = 'B' , -- Операция ('B' - buy, или 'S' - sell)
[ 'TYPE' ] = 'L' , -- Тип ('L' - лимитированная, 'M' - рыночная)
[ 'QUANTITY' ] = '1' , -- Количество
[ 'PRICE' ] = tostring(tekPrice) -- Цена
}
local Res = sendTransaction (Transaction)
end
функция OnInit вызывается один раз и как правило при ее работе еще нет соединения с сервером. В этой функции надо выполнять инициализацию переменных и загрузку библиотек. ----------------------------------- Торговые действия надо исполнять либо в main либо в колбеках.
Николай Камынин написал: На графике свеча всегда отобразится на значении 00 но это отображение будет сделано в момент появления первой сделки после 00.
сие очевидно
Цитата
Николай Камынин написал: Конец свечи тоже отобразится в момент 00
а вот тут - навряд ли если времена свечей заявлены по открытию, но тогда это противоречит вашему первому параметру - по началу в 00 скорее в качестве значения Close будет последняя сделка до времени 00 начала следующей свечи
Цитата
Николай Камынин написал: Т е как я написал ранее свечи всегда отображаюся с запаздыванием но это запаздывание не показано на графиках.
показаны, но не отображаются : звучит вполне тафталогично
Цитата
Николай Камынин написал: Поэтому закрывшиеся свчи всегда точно синхронизированы на графиках по времени точно в 00.
это в случае если свечи формируются по времени окончания периода. и это уже воля авторов, как их рисовать но начинаться в 00 и заканчивать в 00, перемешивая моменты для соседних, навряд ли правильно.
Время свечи задает всемирное время. Я вообще-то не гадаю, а объясняю Вам как формируются свечи. Свеча формируется от 00 часов 00 минут 00 секунд по Гринвичу. алгоритм следующий. Время открытия свечи - оно же время закрытия всегда точно равно всемирному а квант дискретности равен тайму. Т е время свечи никаким образом не синхронизировано с временем сделок. Именно для этого и придуманы свечи чтобы уйти от тиков к реальным часам. Т е свеча это значение четырех индикаторов, взятых на интервале свечи. Цена открытия - это цена сделки которая была первой после 00 для новой свечи Цена закрытия - это цена сделки которая была последней после открытия этой свечи и до времени 00 - открытия следующей т е цена закрытия предыдущей свечи и цена открытия следующей - это цены двух различных сделок которые совершены в различное время но стоят рядом вокруг 00.
валерий написал: Если два графика расположены в двух областях одной диаграммы, то нужно ли бары обязательно синхронизировать по времени баров или можно быть уверенным, что если индексы совпадают, то и время тоже?
если брать вопрос шире, но проще, то: - бары, свечи и любые другие визуальные способы представления статистических данных - это просто способ визуализации, удобный для восприятия человеком. - у этих способов есть правила, по которым они реализуются: время начала - момент когда надо нарисовать Open, время окончания - Close, между этими событиями нарисовать Hi & Lo и т.д. В наше время в ядре биржи происходят сотни сделок в секунду, но вовсе не факт, что для начала каждой минуты во время 00.000 сек будет существовать сделка для отрисовки начала свечи в точно заданное время Поэтому любая "графика" зависит от авторов: при соблюдении правил два чарта будут синхронно нарисованы, тк они формируются по единому правилу - это теоретически. Практически возможен некий программно-аппаратный лаг при рендеринге разных оконных фреймов, который может быть микросекунды - для текущей свечи. Если в квик окно обновляется в пределах 1-0.5 сек, то это не имеет значения даже для текущей свечки и не повлияет на ваши входные данные и выходные сигналы соответственно. (При использовании индикатора-упростителя из 80-х гг прошлого века - свечи, бары и т. д.)
На графике свеча всегда отобразится на значении 00 но это отображение будет сделано в момент появления первой сделки после 00. Конец свечи тоже отобразится в момент 00 но последняя сделка при этом может быть и за полчаса до 00, если это тайм час. Т е как я написал ранее свечи всегда отображаюся с запаздыванием но это запаздывание не показано на графиках. Поэтому закрывшиеся свчи всегда точно синхронизированы на графиках по времени точно в 00.
валерий написал: Понятно, что свечи на одном графике синхронизированы. Но можно ли быть уверенным, что и индексы у свечек с одинаковым временем всегда одинаковые (тогда можно искать соответствующую свечу на втором графике по индексу, а не таймстампу)? Мало ли как Арка их считает... Хочу знать наверняка от авторов.
Если я Вас правильно понял, то речь идет о различных инструментах(бумагах) Свечи у них синхронизированы по началу тайма. Но возможно отсутствие свечи при отсутствии сделок в этом интервале для данного инструмента. Поэтому просто по номеру свечи не синхронизированы.
валерий написал: Если два графика расположены в двух областях одной диаграммы, то нужно ли бары обязательно синхронизировать по времени баров или можно быть уверенным, что если индексы совпадают, то и время тоже?
Не свосем понятно что и с чем хотите синхронизировать. На графиках свечи всегда отображаются синхронизированными , но в действительности свечи - это индикаторы экстремумов на заданном тайме. Тайм синхронизирован. Свечи это индикаторы, которые считаются всегда с запаздыванием. .
есть два варианта ускорить прием ответа. 1) отказаться от onParam 2) во всех колбеках поставить запуск новых потоков и выход из колбека В этом случае будет максимально быстро выходить из OnParam и др колбеков.
Александр Правилов написал: Николай Камынин , в этом то самая и большая проблема, в невозможности получить ответ, пока не закончится OnParam или не подождать в OnParam, к примеру через event.timer или event.pull, могу ошибаться. Ну да ладно, что-нибудь придумаю, благо для текущего алгоритма, скорость не является приоритетной.
Вы очевидно не понимаете, что это в принципе невозможно в КВИК, так как принятый ответ обрабатывается в том же потоке, где работает функция OnParam. т е ядро процессора (поток) занят этой функцией и обработка новых данных будет после ее завершения. а других потоков для обработки новых данных в КВИКЕ не выделяется т е это так сделан КВИК. Поэтому, если очень хочется, то надо отказываться от КВИК и подключаться прямо к бирже.
Александр Правилов написал: Николай Камынин ,Да дело не в таблице состояний, это не то. Этот способ режет скорость. После отправки транзакции в OnParam есть ещё код и пока этот код не выполнится, не придет ответ от OnTransReply и OnOrder, а надо получить ответы еще при выполнении кода в OnParam.
Пока исполняется OnParam никакие новые данные с сервера не могут быть обработаны. Поэтому НЕВОЗМОЖНО находясь в onParam получить ответ OnTransReply и OnOrder, Полагаю Вы это поняли. ----------------------------
Александр Правилов написал: Николай Камынин , если с кодировкой что-то не то, почему остальной код работает? Николая, подскажите кучочек кода, как перевести в состояние ожидания ответа по заявке?
Общий подход работы робота на основе событийной модели следующий. ------------------------ В начале описываете таблицу возможных состояний робота. Например у меня есть таблица состояния заявок, таблица состояния стоп-заявок ну и т д. Эти таблицы в отличии от таблиц квика содержат лишь активные заявки. ------------------------------------------- Когда посылаете заявку то пишите в конец таблицы запись о том что послали заявку в систему Когда собираетесь послать заявку то проверяете состояние последней записи в таблице состояния заявок Если там указано что заявка отправлена брокеру ( т е еще нет подтверждения что она на бирже) то пропускаете отправку новой. ----------------------------- Ну и т д
Александр Правилов написал: Николай Камынин , не согласен с вами, колбэками управлять нельзя, они приходят как приходят, посмотрите мой пример выше, как разрулить эту ситуацию?
Sergey Gorokhov , Сергей, подскажите другой момент, что то не получается получить таблицу заявок, в чем может быть ошибка?
в row=getItem("orders",i) пишет - improperly formatted XML data
Код
for i = 1 , getNumberOf ( "orders" ) do
local row = getItem ( "orders" ,i)
if row ~ = nil and row[sec_code] = = sec then
local trid,ms = killOrder(row[order_num],sec,class)
if trid ~ = nil then
tbl: SetValue (line_count_table[sec],'ÅñòüÇàÿâêà', string.format ( "Cancel" ))
tbl: SetValue (line_count_table[sec],'ÖåíàÇàÿâêè', string.format ( "0" ))
end
end
end
Александр Правилов написал: Николай Камынин , не согласен с вами, колбэками управлять нельзя, они приходят как приходят, посмотрите мой пример выше, как разрулить эту ситуацию?
А где Я Вам говорил, что колбеками надо управлять(ужас какой-то). Колбеки - это функции, которые вызываются системой ( в данном случае тарминалом КВИК) при наступлении определенного события. Т е они сообщают вам о событиях в КВИКЕ и ВСЕ. --------------------- Когда робот отсылает заявку - то он переходит из состояния - "послать" в состояние - "ждать ответа". А у Вас нет этих состояний т е Вашему роботу все по... Вот он у вас и шлет кучу заявок и ничего не ждет. Ну как-то так получается...
Николай Камынин написал: Надо строить робота на основе событийной модели, тогда таких проблем не будет. Т е робот - это конечный автомат, который полностью описывается набором его состояний. Поэтому надо фиксировать эти состояния и программировать условия перехода из одного состояния в другое.
Я с Вами полностью согласен, но в lua нет событийности, всё зависит от стека функций об.вызова, как они придут и потока всего два и основной стек находится в одном потоке.
Именно библиотека QLUA и дает Вам механизм событий в виде колбеков, что принципиально отличает ее от QPILE. Состояние же робота необходимо хранить в таблице состояний - это уже особенности алгоритма. Луа позволяет все это сделать.
Надо строить робота на основе событийной модели, тогда таких проблем не будет. Т е робот - это конечный автомат, который полностью описывается набором его состояний. Поэтому надо фиксировать эти состояния и программировать условия перехода из одного состояния в другое.
Иван Ру написал: Есть открытый текстовый файл, скажем, длинной в 100 строк. Необходимо дописать данные, скажем, в 79 строку (номер известен). Возможно ли такое средствами Lua, есть ли у кого пример реализации подобной функции?
Вашу задачу можно так: 1) Все записи делаем одинаковой длины, например 128 байт 2) Если запись короче 128 то добиваем ее либо пробелом либо нулями. 3) Если надо дописать, то ищем изменяемую запись , читаем ее, добавляем и пишем на свое место.
Возможно мы друг друга недопоняли. Записи я делаю в csv (текстовый) файл с разделителями в виде ";". Затем я его читаю в эксель. По-сути надо добавить дополнительные элементы данных в отдельные строки, де-факто они всегда оказываются ближе к концу файла. Кстати, попутный вопрос. Если у меня файл находится в открытом состоянии в режиме чтения-записи и его размер велик (скажем 100 мб.) -- отнимает ли это соответствующий объем оперативной памяти? Если да - как этого избежать? Только закрытием файла и повторным открытием для записи?
память под файлы расходуется, но это не 100 мб и беспокоится не стоит. Попробую объяснить про дозапись. Есть два режима записи - бинарный и текстовый. В текстовом инфа пишется в файл последовательно запись за записью . Каждая строка пишется в формате ASCIZ, т е признак конца строки - это ноль. поэтому просто добавить в конец какой- либо, не последней, строки в файле невозможно, так как нет места для этого. Поэтому я Вам предложил сделать строки одинаковыми по длине - это ускорит поиск нужной строки и создать место для дозаписи. Т е Вы создаете пустое место на диске и пишите в это место . ---------------------------- Если Вы пишите в файл лишь для передачи в Excel, то это можно делать через протокол Dynamic Data Exchange (DDE) сразу в Excel. Но это требует знаний в написании DLL на СИ для Lua.
Николай Камынин написал: 3) Если надо дописать, то ищем изменяемую запись , читаем ее, добавляем и пишем на свое место.
Ну так-то обычно все данные после места записи обрезаются. Нельзя просто так взять и вставить запись внутрь файла ;)
Отличным решением был бы например маппинг файла в память, но, боюсь на луа это не доступно.
Цитата
Иван Ру написал: Если у меня файл находится в открытом состоянии в режиме чтения-записи и его размер велик (скажем 100 мб.) -- отнимает ли это соответствующий объем оперативной памяти?
Нет, не отнимает.
Если будете правильно писать то данные не будут обрезаться. А вот память под файлы расходуется. т е "отнимает" Более того, если Вы не делаете выгрузку, то данные будут в памяти а не на диске.
Полагаю, что у Вас установлен флаг "Исходя из настроек открытых пользователем таблиц" Надо установить флаг "С учетом настроек, выбранных через пункт меню "Система/Заказ данных/Поток котировок" в "настройки клиентского места" в окне "Получение данных"
Иван Ру написал: Есть открытый текстовый файл, скажем, длинной в 100 строк. Необходимо дописать данные, скажем, в 79 строку (номер известен). Возможно ли такое средствами Lua, есть ли у кого пример реализации подобной функции?
Вашу задачу можно так: 1) Все записи делаем одинаковой длины, например 128 байт 2) Если запись короче 128 то добиваем ее либо пробелом либо нулями. 3) Если надо дописать, то ищем изменяемую запись , читаем ее, добавляем и пишем на свое место.
Загрузка своих данных в Quik, Требуется создать индикатор который на основании еxel таблицы будет формировать гистограмма с положительных и отрицательный значениями
Из ваших ответов стало понятно как считать N. А как считать волатильность?
Ищите все на сайте ммвб, а не спрашивайте на форуме. Потому, что Вам надо не ссылки на математику для начинающих, а методики расчета на бирже и чтобы у Вас все совпала с биржей. Поэтому бесплатных решений нет, а написать решения может тот, кто не задает подобные вопросы и профессионально пишет софт. Успехов в изучении программирования.
Николай Камынин написал: Но очень сомневаюсь, что Вы ее сможете запрограммировать.
Да ладно. Самое хитрое там - функция нормального распределения N(x). Но нам в помощь численные методы. Если интересна теория: 1. Hart, J.F. (1968). Computer Approximations. Наверно, наиболее цитируемая книга по численным методам. 2. Krishnamoorthy K. Handbook of Statistical Distributions with Applications (2006). Это, в частности, в области теории вероятностей. В ней надо смотреть раздел "10.10. Computing the Distribution Function".
Ну и код функции N(x) по этому методу, перенесенный на Луа. Точность 14 знаков этого приближения устроит?
Код
function NormCDF (x)
if type(x) ~ = "number" then return end
local z = math.abs (x)
local p
if z < 7 then
p = math.exp ( - z * z / 2 ) *
((((((( 2.49338129315143e-02 * z + 0.604737992686704 ) * z + 6.81311678753268 ) * z +
46.0649519338751 ) * z + 202.102090717023 ) * z + 580.109897562909 ) * z +
1024.60809538334 ) * z + 913.167442114756 ) /
(((((((( 0.0625 * z + 1.51584331855598 ) * z + 17.1406995062578 ) * z +
116.979524577666 ) * z + 523.596091947383 ) * z + 1566.10462582845 ) * z +
3044.77121163622 ) * z + 3506.42059774909 ) * z + 1826.33488422951 )
elseif z < 32 then
p = math.exp ( - z * z / 2 ) / 2.506628274631 /
(z + 1 / (z + 2 / (z + 3 / (z + 4 / (z + 5 / (z + 6 / (z + 7 )))))))
else
p = 0
end
return (x > 0 ) and ( 1 - p) or p
end
Не так страшно? С остальным в формулах Блэка-Шоулза наверно справитесь? Вот, например, расчет дельты колл опциона:
Код
function CallDelta (f, s, v, t)
return NormCDF(( math.log (f / s) + v^ 2 * t / 2 ) / (v * t^ 0.5 ))
end
Ну,ну... ------------------------------- "..не сумлевайтесь, милые: Коль что у вас не ладится — ну, там, не тот аффект, — Мы мигом к вам заявимся с лопатами и с вилами, Денёчек покумекаем — и выправим дефект!"
Поищите на сайте ммвб. Когда-то там находил. Но очень сомневаюсь, что Вы ее сможете запрограммировать. Сомневаюсь, что есть бесплатная прога. ------------------------ Ищущий да обрящет.
Надо прочитать документацию: sendTransaction Функция предназначена для отправки транзакций в торговую систему. Формат вызова: STRING result sendTransaction(TABLE transaction) Параметры:
result – строка, содержащая текст ошибки, если она случилась при обработке транзакции;
function ms (value)
if type(value)~="table" then
message (""..tostring(value),1)
else
for k,v in pairs(value) do
message (tostring(k).." "..tostring(v),1)
end
end
end
поделюсь своим решением. обрабатываю в колбеке. В таблице пассивные заявки удаляю. в колбеке обрабатываю все приходы и мне безразлично сколько их. ----------------- обрабатывал и в майн. =================== Последний вариант - один колбек на все скрипты. т е роботов много, но колбеков по одному для каждого вида (заявки, сделки, стаканы и т д)
для колбеков поток один - это точно. но возможно, что Вы работаете с таблицами в main. Тогда будет два потока. ----------------------------------------- проблема может быть в Вашем алгоритме обработки. Чтобы ответить точно, надо видеть как (вернее где) Вы обрабатываете сигналы заявки.
Роман Родников написал: Здравствуйте. Я хочу создать советника на Qlua, который на графике цены будет проставлять метки в зависимости от условий в скрипте.И у меня, как у новичка, есть несколько вопросов: 1.Нужно ли создавать отдельную область, где будет график цены, или можно будет как-то добавить свой скрипт как индикатор в Quik к штатному графику Price и получать на нем соответствующие метки? 2.Есть набор стандартных индикаторов в Qlua, они в папке INDICATORS. Обязательно ли вызывать стандартный индикатор строкой dofile ("C:\INDICATORS\MACD.lua"), или если индикатор стандартный, то можно его и так вызвать MACD ( параметр1, параметр2,...параметрN)? 3. Есть ли у кого-то шаблон такого советника, с которого можно было-бы начать?
Попробую объяснить сущность QLUA. QLUA - это библиотека функций обращения через терминал QUIK к брокеру, написанная для стандартной VM LUA. -------------------------------- Чтобы написать советник надо. ---------------------- 1) Изучить язык программирования луа. Это можно сделать без квика. ------------------------------ 2) Изучить функции библиотеки QLUA. --------------------------- 3) Написать программу на луа с использованием библиотеки qLUA..
Иван Джеммер написал: В функцию в качестве аргумента приходит таблица data = { 'a', 'b', 'c', 'd', 'e' } Для удобства я делаю следующее:
local var1 = data[1] local var2 = data[2] local var3 = data[3] local var4 = data[4] local var5 = data[5]
Вопрос состоит в следующем: при выходе из этой функции, что случится с переменными var1-5 и таблицей data ? Будут ли они храниться в окружении данной функции или уничтожатся? Если data будут храниться, то не будет ли расточительством делать переменные var1-5 ? (т.к. это по сути копии таблицы data ). Просто мне удобно использовать var1-5 (т.к. легче обращаться к значениям по имени переменной, а не по индексу в в таблице data ), но в то же время опасаюсь, что это будет лишним засорением памяти.
// Появилась ещё идея, после ввода переменных var1-5 выполнить код: data = nil. Что скажете?
обращение через локальные переменные и через индексные в массиве отличается тем, что локальные - это копия элементов, а индексное значение - это указатель. Если Вы в функции сделаете так: var1=0 то привыходе из функцию таблица data не изменится а если сделать так data[1]=0 то при выходе в таблице первый элемент будет равен 0. --------------------------- Что касается затрат памяти, то после завершения вызова, освободившуюся память соберет сборщик мусора. --------------------------- Если Вы много раз обращаетесь к данным внутри функции, то использование локальных переменных будет быстрее. ------------------------- Резюме: Делайте как удобно.
можно так: local x="12345" -- присваиваем номер заявки _G["_"..x]={} --создаем таблицу с именем _номер заявки _12345.order_price=65 --пишем цену в таблицу _12345 под именем order_price
Еще можно сделать следующее. 1) Попробуйте еще не загружать никаких приложений, в том числе и браузер, кроме квик. 2) Если умеете, то попробуйте оптимизировать службы винды, уберите, которые не нужны, чтобы освободить память.
сделайте это (из предыдущих советов): 5) Попробуйте работать с включенным флагом "Только данные, отражающие текущее состояние" (Настройки клиентского места)
Иван Ру написал: Я все же неверно определил источник проблемы, которая, к сожалению сохраняется. Теперь уже в самом терминале появляется сообщение "Операция не может быть выполнена т.к. недостаточно памяти". При этом объем памяти используемый двумя скриптами составляет порядка 2х150 = 300 мб, а совокупный объем памяти занятой терминалом (в тот же момент смотрел через диспетчер задач) -- 1,5 Гб. Вообще последний показатель никогда не превышает 2,5 Гб, т.е. ресурс не выбран. Что у меня включено: - трансляция обезличенных сделок (около 5 полей по 160 инструментам - все фьючи). - 2 окна "Текущие торги" - все фьючи и все акции, порядка 10 полей в каждом. - 2 тиковых графика - 2 стакана - около 15 окон с графиками - 2 окна с портфелями Т2 и Т0.
Отключение тиковых графиков проблему не решает, а вот отключение трансляции обезличенных сделок -- по первым ощущения ее устраняет. Мне они категорически нужны, не понимаю что делать.
Могу дать следующие советы. 1) Удалите из ТТП те акции, которыми не торгуете и фьючерсы которыми не торгуете. Но удалять надо из заказа данных. 2) Удалите параметры, которые не используете. 3) Проверьте отключены ли у Вас опционы. 4) Посмотрите сколько в действительности у Вас выбрано инструментов и параметров (В окне выбор принимаемых параметров и инструментов) 5) Попробуйте работать с включенным флагом "Только данные, отражающие текущее состояние" (Настройки клиентского места) ----------------------------------- Пишите, какой результат.
Николай Камынин написал: Это пример очень плохого скрипта. Зачем Вы храните все bid, ask с шагом 0.5 в таблице? Вы что обрабатываете всю таблицу от начал каждую секунду? Если нет, но хотите сохранить ( аля плюшкин, выбросить жалко, а нести тяжко), то пишите в файл.
Я не думаю, что опыт позволяет написать мне качественный код, однако, не стал бы столь решительно судить о нем по отдельным по внешним признакам :-) Конечно определенный смысл именно в таком подходе для меня есть. В определенные "критические", скажем так, моменты времени, мне надо подсчитывать разнопериодные средние (не по барам, а в привязке к критической точке), при этом делать это надо максимально быстро. По последней причине запись в файл для меня неприемлема, т.к. процедура открытия/чтения занимает время. Единственный выход - работать на укороченной истории. Если Вы предложите лучшее и более качественное решение моей задачи -- буду только признателен :-)
Есть два способа написать хороший скрипт. Первый - Вы знаете. Второй - изучать существующие технологии разработки подобного класса алгоритмов. ------------------------ Есть два вида программ. один из них - это программы реального времени. К ним относятся торговые роботы, работающие в реале. Они имеют одну особенность - их скорость работы в реале определяется временем выполнения наиболее длинной операции. У Вас - это подсчитывать разнопериодные средние. Для вычисления средней в правильном алгоритме надо три арифм операции на тик вне зависимости от длины истории (N). В вашем алгоритме надо N операций. Можете посчитать время исполнения. ------------------------ Кроме того, за восемь часов торгов вы получаете примерно 60 тысяч пар bid, ask . Что-то я сомневаюсь, что Вы считаете среднее с N=60000. Но тогда зачем это все хранить? Надо делать скользящее окно по максимальному N. А еще более эффективнее это переходить от средней к скользящей или к медиане. -------------------------------- Успехов
Иван Ру написал: Спасибо всем, в особенности _sk_ , за советы! Сообщаю предварительные выводы. Особых событий перед падением скриптов нет, обычно крашу случается по истечение нескольких часов после их запуска, что наводит на мысль о постепенном заполнении памяти в ходе работы скриптов. Логгирование это подтвердило -- происходит плавный рост использования памяти с течение времени в обоих моих основных скриптах, в особенности в последнем сварганенном. Собственно, я получил то что и должен был получить -- он сохраняет в таблицу последние bid, ask два раза в секунду и данные по сделкам по ВСЕМ фьючерсам. Каждый час объем памяти используемый этим скриптом растет приблизительно на 150 мегабайт. Падает чаще всего второй скрипт, который сохраняет меньше данных, но, по-видимому, делает это (т.е. обращается к памяти) чаще. Я полагаю что ручной запуск сборщика мусора мне мало чем поможет, т.к. проблема не в большом объеме мусорных данных, а в огромных таблицах (за 10 часов набирается порядка 70 тысяч элементов). Старые куски этих таблиц надо периодически удалять ограничивая их общий объем 1- 10 тысячами элементов. Это, между прочем, оказывается определенной проблемой, -- я не вижу стандартного инструмента. Многократное удаление отдельных элементов с использование table.remove и перенумерацией массива занимает много времени. В частности, удаление половины первых элементов из массива длинной 10000 у меня заняло 6 секунд! Косые способы решения этой проблемы обсужу в новой теме.
Это пример очень плохого скрипта. Зачем Вы храните все bid, ask с шагом 0.5 в таблице? Вы что обрабатываете всю таблицу от начал каждую секунду? Если нет, но хотите сохранить ( аля плюшкин, выбросить жалко, а нести тяжко), то пишите в файл. в результате у Вас освободится 90% занятой памяти. ---------------------------- Хороший алгоритм реального времени - это тот, в котором нет обработка данных в цикле.