@dlangru

Страница 156 из 719
 
Oleg
18.04.2017
12:17:09
лучше выяснить сколько элементов нужно сохранить, а потом выделить 1 раз память под это

 
Dmitry
18.04.2017
12:17:10
Олег, а как ты считаешь в чем у меня проблема?

 
почему память не осовобождается? это из-за ГК все?

 
Oleg
18.04.2017
12:17:42
Так, нужно помощь коллективного разума. Программа в цикле выполняет обращение к БД (каждый раз читает новые данные) и кладет их в переменную. Я ожидал, что каждый раз программа будет эту переменную пеерсоздавать заново и потребление памяти будет падать. Однако у меня получается, что программа начинает есть все больше памяти пока не доходит до 1800MB RAM после чего зависает. Вопросы. 1. Почему память на каждом шаге не освобождается? 2. Как ее освобождать и это причуюды сборщика мусора или что?
ты про это?

Google
 
Dmitry
18.04.2017
12:17:52
да

 
Oleg
18.04.2017
12:18:36
я хз, у меня программа выедала под 800Mb и НЕ падала

 
но больше 800 она не ела, сборщик начинал отрабатывать

 
Pavel
18.04.2017
12:18:55
Если ты пишешь эти координаты в файл, то зачем тебе вообще накапливать это в массиве?

 
Oleg
18.04.2017
12:19:01
почему у тебя она выедает больше и падает потом я не знаю

 
Pavel
18.04.2017
12:19:10
Как только вычислил координату - записал ее в файл.

 
Oleg
18.04.2017
12:19:13
Если ты пишешь эти координаты в файл, то зачем тебе вообще накапливать это в массиве?
кстати да

 
Dmitry
18.04.2017
12:19:17
не, я их не в файл пишу, в файл я просто для теста записал

 
Pavel
18.04.2017
12:19:29
А что ты с ними делаешь?

 
Dmitry
18.04.2017
12:19:31
чтобы оценить размеры файла

 
Oleg
18.04.2017
12:20:06
шта?

 
Dmitry
18.04.2017
12:20:18
ну по идее данные из каждой обработанной таблице я буду передавать в другую БД и в ней делать некоторые операции с прилитевшими данными

 
Oleg
18.04.2017
12:20:59
и зачем тебе оценивать размер файла?

Google
 
Oleg
18.04.2017
12:21:04
текстового

 
Dmitry
18.04.2017
12:21:17
ну просто хотелось понять если прога ест 200МБ а файл весит всего 35

 
Oleg
18.04.2017
12:22:23
вообще всё не так сделал

 
первый вопрос: тебя не устраивает, что прога занимает в памяти 200Мб? второй вопрос: у тебя самый основной массив данных есть, почему ты не вывел на экран (ну или в файл на крайняк) его sizeof? третий вопрос: ты уверен, что тебе нужен полностью весь массив в памяти, если тебя запаривает занимаемая память? четвёртый вопрос: если всё парит, надо как-то оптимизировать и на производительность ты пока клал хер попробовал ли ты в цикле вызывать GC.collect?

 
arr.length * typeof(arr[0]).sizeof если быть точнее

 
пятый вопрос/момент: не устраивает падение производительности при GC.collect, что делать? ответ: выделить 1 раз память и заполнить её

 
Dmitry
18.04.2017
12:28:06
1. 200МБ еще ок, просто надо понять что будет если выборка будет к примеру в 10 раз больше, оно 2 гига захочет? 2. а что sizeof даст? 3. ну наверно да, нужен в памяти? а как еще? На диск результат писать? 4. Сейчас попробую.

 
Oleg
18.04.2017
12:28:11
вообще память можно выделить каким-нибудь ScopedAllocator'ом и оно как бы будет вообще без сборщика работать

 
2. а что sizeof даст? > arr.length * typeof(arr[0]).sizeof если быть точнее

 
и это даст тебе объём памяти, который +/- реально занимает массив именно в оперативе

 
Pavel
18.04.2017
12:29:54
1. 200МБ еще ок, просто надо понять что будет если выборка будет к примеру в 10 раз больше, оно 2 гига захочет? 2. а что sizeof даст? 3. ну наверно да, нужен в памяти? а как еще? На диск результат писать? 4. Сейчас попробую.
Кстати если данных будет много, то постгрес умеет курсоры, а mysql нет

 
Dmitry
18.04.2017
12:30:05
внутри foreach(item; getTablesGPSSensorList) { ... GC.collect } добавил сборку мусора. не помогло. Память есться так же

 
Oleg
18.04.2017
12:31:00
ну тогда значит item у тебя такой жирный)

 
что вообще делает метод getTablesGPSSensorList?

 
какой тип данных возвращает? что ты потом с этим делаешь?

 
если тебе не нужно наследование, то лучше структуры сделать если ты можешь узнать размер заранее -- лучше узнать и выделить память не все алгоритмы требуют всю выборку в памяти

 
Dmitry
18.04.2017
12:33:03
Павел, к сожалению у меня только так. У меня эти БД в разных местах находятся. Пока на локалхосте, дальше по сетке придется гонять т.к. архив весь в MySQL хранится, а это 1TB текстовых данных

 
Pavel
18.04.2017
12:33:56
Вы их портируете или придется постоянно так делать?

 
Dmitry
18.04.2017
12:34:07
Метод: GPSAndSensorTuple [] getTablesGPSSensorList() { } возвращает имена таблиц для переборки в виде кортежа

 
нет, пока партирования нет. Пока оно так. Дальше нужно будет хотя бы с MyISAM на ColumnStore перейти

Google
 
Oleg
18.04.2017
12:35:03
Метод: GPSAndSensorTuple [] getTablesGPSSensorList() { } возвращает имена таблиц для переборки в виде кортежа
tuple только в названии или это массив tuple'ов?

 
Dmitry
18.04.2017
12:36:11
просто массив кортежей с именами и все. типа таких: historysensor_10717 historyygps_10717

 
вот тут я вставляю нужные имена в запрос: sqlquery = sqlquery.replace(`historygps_10658`, item.gps).replace(`historysensor_10658`, item.sensor);

 
дальше просто для каждого кортежа из кортежей делею запрос к MySQL и выбираю оттуда данные в массив структур

 
все

 
Oleg
18.04.2017
12:39:41
смущают меня эти цифры в конце имён

 
Pavel
18.04.2017
12:40:01
Похоже на костыли ))

 
Oleg
18.04.2017
12:40:04
что-то тут не так)

 
Dmitry
18.04.2017
12:40:11
ну это просто идентификаторы. они в БД так и хранятся.

 
>что-то тут не так) Думаешь заговор?))

 
Oleg
18.04.2017
12:40:32
идентификаторы это цифры обычно в БД

 
>что-то тут не так) Думаешь заговор?))
скорее согласен с Павлом)

 
Oleg
18.04.2017
12:41:15
можешь более полно задачу рассказать? мне прям уже интересно

 
Maxim
18.04.2017
12:41:43
а зачем вообще tuple использовать?

 
Oleg
18.04.2017
12:41:54
если тебе просто данные из одной базы в другую перепаковать нужно, то тут можно либо быстро и жирно по памяти, либо медленно и экономично по памяти

 
Dmitry
18.04.2017
12:42:03
максим, мне просто удобнее было так, чисто для наглядности

 
Maxim
18.04.2017
12:43:21
у tuple под капотом же целая мешанина из шаблонов, если типы известны, не лучше ли структуру использовать?

 
Dmitry
18.04.2017
12:44:34
Есть MуSQL БД размером в 1TB. В ней хранятся кооридинаты GPS навигатора. MySQL не умеет считать пространственную геометрию. Точнее умеет, но очень плохо. Я выгрузил дамп OpenStreetMap это около 500GB в PostgreSQL. В нем есть функция поиска ближайшего объекта (точка к линии). Теперь мне нужно провести анализ точек из MySQL путем проброски их в PG и выполнения рассчетов уже в самом PG. Это если кратко.

 
Сейчас я выбираю треки из MySQL и вот уже почти готов их в PG отправлять, но не пойму почему на тестовом наборе уже какие-то пробелмы с памятью.

 
Pavel
18.04.2017
12:46:33
А в mysql постоянно льются данные новые? Нельзя их заставить литься в postgres ?

Google
 
Dmitry
18.04.2017
12:46:42
нельзя...

 
Pavel
18.04.2017
12:46:54
Эх ?

 
Dmitry
18.04.2017
12:47:04
тем более ПГ он транзакционный т.е. БД будет дико пухнуть

 
Pavel
18.04.2017
12:47:30
Да не, по объему не сильно больше мускуля будет

 
mysql и postgres в этом плане мало отличимы

 
Dmitry
18.04.2017
12:47:58
уверен?

 
Pavel
18.04.2017
12:48:17
да, мускуль же тоже транзакционный

 
Dmitry
18.04.2017
12:48:27
от движка зависит

 
MyISAM и ColumnStore (в перспективе на него будем переходить) нет

 
Pavel
18.04.2017
12:48:48
да вроде везде уже innodb а про myisam забыли

Admin
ERROR: S client not available

 
Pavel
18.04.2017
12:49:00
Вот насчет column store не знаю

 
Но в любом случае это же все равно костыль - держать данные в одной БД более компактно, а потом все равно перегонять их в другую распухающую БД и там высчитывать геоданные =\

 
Dmitry
18.04.2017
12:50:06
Согласен, но поменять ничего не получится

 
в перспективе возможно будет препроцессинг данных

 
Oleg
18.04.2017
12:51:08
> Теперь мне нужно провести анализ точек из MySQL путем проброски их в PG и выполнения рассчетов уже в самом PG.

 
какой самый длинный набор точек?

 
не весь же террабайт связан сам с собой?

 
ты же можешь загружать трэк (10, 20 или 100 точек), отправлять его в pg, производить расчёт, а потом загружать новый

 
если точки вообще не связаны можно выбрать оптимальный с разных точек зрения объём кадра обработки

Google
 
Dmitry
18.04.2017
12:53:38
Пока я выгрузил один трек. Он и съел 200RAM и 35MB места

 
Oleg
18.04.2017
12:53:55
вот тоесть как

 
ведь заранее ты можешь узнать размер трека?

 
Dmitry
18.04.2017
12:54:26
ну SELECT COUNT(*)

 
Oleg
18.04.2017
12:54:43
ну так это же не все точки, а только какой-то трек

 
и что есть точка? это 2 пространственные координаты на поверхности земли + время, когда зафиксирована эта точка?

 
Dmitry
18.04.2017
12:55:36
не, в одной сджойненной таблице: historysensor_10717 historyygps_10717 хранится один трек

 
время| точка | прочие-данные

 
Oleg
18.04.2017
12:55:53
вот откуда эти цифры...

 
сколько этих данных?

 
Dmitry
18.04.2017
12:57:11
каких именно? Всего таких тарблиц наверно около 1000 — может чуть больше.

 
Oleg
18.04.2017
12:57:27
время| точка | прочие-данные
прочих

 
Dmitry
18.04.2017
12:57:44
ну я пока взял минимум ID и DateTime

 
Oleg
18.04.2017
12:58:03
это пара байт или это прям альманах с эфемеридами?

 
ок

 
тоесть float x, float y, ulong time, ulong id?

 
ну примерно

 
Dmitry
18.04.2017
12:59:02
пример ID 1477928244022148977

 
Oleg
18.04.2017
12:59:19
ты его строкой хранишь?

 
Dmitry
18.04.2017
12:59:27
пока в ulong

 
Oleg
18.04.2017
13:01:20
и того, чтобы заполнить 200Мб нужно около 13107200 точек

 
думаю в 200Мб можно всю базу точек уложить

 
Dmitry
18.04.2017
13:02:05
ну оно 200МБ в памяти съедает, тоже самое на диске 35МБ

Страница 156 из 719