View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003458SAS.ПланетаРефакторингpublic23-06-2019 15:4726-11-2019 05:52
ReporterParasite 
Assigned To 
PriorityurgentSeverityblockReproducibilityalways
StatusconfirmedResolutionopen 
PlatformWindowsOS7OS VersionEnterprise
Product Version190707 
Target Version20xxxxFixed in Version 
Summary0003458: Льется память при перепроверке кэша в Беркли\SQLite
DescriptionСудя по всему, где-то в САСе дико льется память при перепроверке кэша, сохраненного в беркли.
При 100% тайлов в кэше, и попытке просто перекачки данного участка - в окошке скачки наблюдаются обычные строки "Тайл уже в кэше" (что нормально), но при этом дико течет свободная память в системе. См.аттач. По достижении предела физической памяти - начинает дико свопиться.

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

Судя по всему - где-то на уровне драйвера Беркли то ли что-то не освобождается, то ли просто при проверке тупо открываются кучи файлов базы - и не успевают [либо забываются] закрываться, то ли что-то в этом роде.

Проверяемо\повторяемо в текущей ночнушке \~5M тайлов в беркли, 100% заполнение.
Steps To Reproduce1. Накачать много кэша в Беркли со 100% доступностью.
2. Попробовать проверить скачанный кэш.
TagsNo tags attached.
Attached Filesjpg file icon 123.jpg [^] (163,045 bytes) 23-06-2019 15:47


jpg file icon good.jpg [^] (94,335 bytes) 01-09-2019 17:31


jpg file icon bad.jpg [^] (93,838 bytes) 01-09-2019 17:31


txt file icon good.txt [^] (107,743 bytes) 02-09-2019 14:40 [Show Content]
txt file icon bad.txt [^] (109,790 bytes) 02-09-2019 14:40 [Show Content]
txt file icon before.txt [^] (108,349 bytes) 21-09-2019 08:01 [Show Content]
txt file icon after.txt [^] (110,155 bytes) 21-09-2019 08:01 [Show Content]
txt file icon start2.txt [^] (104,814 bytes) 17-11-2019 18:41 [Show Content]
txt file icon end2.txt [^] (107,714 bytes) 17-11-2019 18:41 [Show Content]

- Relationships

-  Notes
(0018746)
vdemidov (manager)
24-06-2019 06:41

Поставь Process Explorer и добавь сюда скриншоты вкладки Performance информации о процессе САС до начала проверки и когда память уже заметно выросла. Ну хотя бы до 4-5 гигов. Еще на всякий случай уточни кэш лежит чисто локально или где-то на сетевом диске.
(0018765)
Parasite (administrator)
28-06-2019 14:56
edited on: 28-06-2019 14:57

1. Пока что нет технической возможности ставить\перепроверять (территориально вдали от любого кэша). Но вангую, что должно быть репродуцируемо на любой стороне, включая твою.
В моем случае было ВСЕГДА повторяемо на ~ 5.6M тайлов в Беркли, ~ 80 Гб общим файловым размером.

2. Кэш проверялся\лежал на локальном диске.

(0019310)
Parasite (administrator)
01-09-2019 17:38

1. Скрины с PE докинул. Good.jpg - сразу после старта САСа, bad.jpg - когда вылезло сообщение "Out of memory" - см.ниже.
2. Проблема повторяется и на кэше SQLite в той же мере (скрины с него, соббсно).

Проверялся БОЛЬШОЙ кэш в SQLite, тип файлов - PNG, 100% заполнение (все тайлы - в кэше). Проверка шла в 4 потока (стоит галка "Разбить закачку....4 потока") + галка "Закрывать окна по окончании загрузки". Примерно через час работы занятая САСом память доросла до 4х гигов (см.скрин), в окнах загрузки побежали сообщения "Недостаточно памяти для завершения операции" и затем процесс в окнах остановился. При попытке выйти с САСа - вылезло окно "Out of memory", в итоге - выход по 3м кнопкам.
(0019311)
vdemidov (manager)
01-09-2019 18:53

Так. Каких 4 Гб занятых САС? Ты помнится писал:
> При этом размер самого саса как процесса - вполне нормален, и не растет.
Это же две большие разницы? И запросы на доп информацию совсем другие.
Нужна дебажная версия САС и примерно через пол часа, не останавливая закачек, зайти в окошко "View\Debug Info" и нажать "Save to file...". Сам файл прицепить сюда.
В идеале проверить на обычном файловом кэше. Но то уже такое дело.
(0019312)
Parasite (administrator)
02-09-2019 14:46

1. Приаттачил 2 файла - моментально после запуска, и тот же процесс - после часа работы проверки кэша (размер в памяти был примерно полтора гига).

2. На тайловом кэше такого ни разу не замечал за всё время, иначе давно бы сообщил.

3. При выходе с дебажки - вылез мессидж bad2.jpg. Elf при этом не создался - прикладывать нечего.

4. >Так. Каких 4 Гб занятых САС? Ты помнится писал:
То было в TaskManager - в нем размер саса примерно 50...70Мб, но ты сказал в него больше не смотреть. Гигабайты на скрине - не из TaskManager, а из ProcessExlorer.

5. >не останавливая закачек
На всякий уточню: закачек НЕТ - идет перепроверка кэша с винта, со 100% доступностью оного локально. В инет прожка не ходит, закачек как таковых нет.
(0019313)
vdemidov (manager)
02-09-2019 15:45

> 1. Приаттачил 2 файла - моментально после запуска, и тот же процесс - после часа работы проверки кэша (размер в памяти был примерно полтора гига).

Именно то что надо.

> 2. На тайловом кэше такого ни разу не замечал за всё время, иначе давно бы сообщил.
Всякое бывает. Может ты это на старой версии в файловом кэше гонял, а на новой только SQLite юзал.

> 3. При выходе с дебажки - вылез мессидж bad2.jpg. Elf при этом не создался - прикладывать нечего.
Забей. Известный баг, связанный с обновлением используемых библиотек, но как исправлять пока не знаем.

> То было в TaskManager - в нем размер саса примерно 50...70Мб, но ты сказал в него больше не смотреть. Гигабайты на скрине - не из TaskManager, а из ProcessExlorer.

Вот потому я и говорил, что TaskManager какашка.

> На всякий уточню: закачек НЕТ - идет перепроверка кэша с винта, со 100% доступностью оного локально. В инет прожка не ходит, закачек как таковых нет.

Пофигу. С моей точки зрения это операция закачки выделенной области. Точнее 4 паралельные, но это уже мелочи.

По файлам. В принципе ничего предосудительного не видно, так что похоже дело именно в реализации конкретного тайлохранилища или вообще в библиотеке работы с SQLite. Еще вариант, что получается дикая фрагментация памяти. Я слегка озадачен количеством созданий и удалений объектов TEnumDoublePointBySingleProjectedLine:

/Objects/TEnumDoublePointBySingleProjectedLine/Create 206792552
/Objects/TEnumDoublePointBySingleProjectedLine/Destroy 206792726

Это очень странно.
Вот теперь информация для размышления получена. Нужно думать.
(0019314)
Parasite (administrator)
02-09-2019 16:07
edited on: 02-09-2019 16:08

>похоже дело именно в реализации конкретного тайлохранилища или вообще в библиотеке работы с SQLite
Воспроизводимо И с Berkeley, И с SQLite в одинаковой мере и с одинаковыми эффектами.
Я с тому, что проблема явно не только в "библиотеке работы с SQLite".

>Я слегка озадачен количеством созданий и удалений объектов >TEnumDoublePointBySingleProjectedLine:
>/Objects/TEnumDoublePointBySingleProjectedLine/Create 206792552
Для статистики: число тайлов к проверке по данному выделению: 99.185.164, на момент снятия дебаг-дампа было пройдено процентов 10...15 от этого числа (в каждом из 4х потоков). До 20...25и процентов в каждом - сас никогда не доживал, крэшился с OOM.
А вот при СКАЧКЕ с интернетов в тот самый кэш - всё было ОК, и работало сутками. Проблемы возникают именно что только при перепроверке уже готового. Может, дело в скорости обращения к хранилищу, где перепроверка в разы быстрее скачки - и при оной что-то где-то открывается много быстрее, чем успевает закрываться?

PS: а может ли проблема быть на стадии функционала "Разбить закачку на 4 процесса"? Надо будет попробовать в один поток на досуге....

(0019315)
vdemidov (manager)
02-09-2019 16:27

>Воспроизводимо И с Berkeley, И с SQLite в одинаковой мере и с одинаковыми эффектами.
>Я с тому, что проблема явно не только в "библиотеке работы с SQLite".
Ну, реализовывал оба тайлохранилища один и тот же человек, мог просто одинаковые, но при этом не очень корректные для какого-то режима параметры задать или алгоритмы применить :) Всякое бывает.

> Может, дело в скорости обращения к хранилищу, где перепроверка в разы быстрее скачки - и при оной что-то где-то открывается много быстрее, чем успевает закрываться?
Все может быть. Может даже быть такое, что на файловом тайлохранилище проблема не воспроизводится просто потому, что оно медленнее работает.

>PS: а может ли проблема быть на стадии функционала "Разбить закачку на 4 процесса"? Надо будет попробовать в один поток на досуге....
Вряд ли, но если попробуешь, то о любом результате отпишись тут. Вдруг пригодится.
(0019316)
vdemidov (manager)
02-09-2019 16:35

>Я слегка озадачен количеством созданий и удалений объектов TEnumDoublePointBySingleProjectedLine:
Проверил, таки все правильно. Оно на каждый тайл должно проверить попадает ли он в полигон. А для этого нужно перебрать все отрезки образующие полигон. Так что тут все правильно, разве что крышу сносит у дельфовского менеджера памяти. Но тогда оно так же должно работать и на файловом тайлохранилище.
(0019317)
Parasite (administrator)
02-09-2019 17:07

>оно так же должно работать и на файловом тайлохранилище.
Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия...
(0019318)
vdemidov (manager)
02-09-2019 17:54

>Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия...
Больше никак. По крайней мере готовых вариантов я не знаю.
(0019319)
vdemidov (manager)
03-09-2019 16:54

Как соберется следующая ночная версия попробуй ее погонять. Я убрал там создание TEnumDoublePointBySingleProjectedLine на каждую проверку попадание тайла в прямоугольник. Но думаю, все же дело в реализации конкретных тайлохранилищ. Где-то там есть кэширование излишнее или фрагментация памяти.
(0019329)
Parasite (administrator)
21-09-2019 08:00

>Как соберется следующая ночная версия попробуй ее погонять
Визуально различий нет. Всё как и раньше (процесс пухнет в памяти).
Аттачу свежие before.txt при запуске САСа/after.txt при памяти процесса ~1.2Gb

PS: при проверке кэша в один проход (без юзания фичи "Разбить закачку на N потоков") - всё как и прежде. Пухнет в памяти примерно так же, разве что возможно чуть медленнее (но это неточно).
(0019330)
vdemidov (manager)
23-09-2019 09:36

Ну, все так и ожидалось. Но проверить стоило, чтобы исключить окончательно.

Обработано прмерно 2.6 миллиона тайлов. Утекло грубо говоря 1 гиг. Получается до 500 байт на тайл.

Странно. Для рапакованных точно мало, для самих файлов, вроде бы, тоже маловато.
А какого там тайлы размера в среднем?
(0019331)
Parasite (administrator)
23-09-2019 17:18

>А какого там тайлы размера в среднем?
В данном конкретном - кэш тайлов карты https://map.nostramap.com (но от карты сий бажик не зависит, таки проверено). Кэша примерно 200Гб, САСом успешно проверяется едва ли 25%, и потом его начинает дико глючить (с разнообразными эффектами, но одним финалом ака "три кнопки") по OOM. В итоге успешно скачанный ранее тем же САСом кэш нет никакой возможности проверить даже на дырки.

На всякий случай повышу приоритет тикета.
(0019336)
vdemidov (manager)
26-09-2019 08:20

>В данном конкретном - кэш тайлов карты https://map.nostramap.com.
Мне это ни о чем не говорит. Глянь какой там в среднем размер тайла.

> Кэша примерно 200Гб, САСом успешно проверяется едва ли 25%
Тоесть гиг 50 таки проверяется. Значит это точно не сами тайлы. Нужно думать.

>На всякий случай повышу приоритет тикета.
А смысл?
(0019344)
Parasite (administrator)
26-09-2019 16:37

>Глянь какой там в среднем размер тайла.
"Там" - где конкретно?
Если в кэше - то на диске тайлов нет (а есть базы SQLITE), а если на сервере - то надо перекачивать условно-большой кусок в стандартный кэш сугубо для сбора достоверной статистики. Но в любом случае - тайлы там PNG, и карта таки обычная (именно что карта, не полноцветные снимки) - так что размер тайлов должен быть небольшим, вполне сравнимым с гугломаповским.

>Тоесть гиг 50 таки проверяется. Значит это точно не сами тайлы.
Да, непохоже на сами тайлы. И при тайловом кэше я такого поведения никогда не замечал - всё ж не первый день с САСом...
Может, какие-нибудь хэндлеры открываем к базоводам, но не закрываем? Вот они и копятся, пока всё не упадет в OOM. Помнится, где-то в Беркли в свое время неск.лет назад мы мучались с закрытием баз по таймауту - там тоже кучи открытых баз дико открывались и висели, особенно при перепроверке уже готового...

>А смысл?
Для статистики. :)
(0019347)
vdemidov (manager)
26-09-2019 19:07

Ну, в общем это к Zed'у, автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь.
(0019348)
Parasite (administrator)
26-09-2019 23:55

>автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь.
Это было только мое личное предположение. Там по факту может быть что угодно еще.
(0019351)
vdemidov (manager)
27-09-2019 07:36

> Там по факту может быть что угодно еще.
Ой, вряд ли. Но можно проверить на файловом тайлохранилище вместо sqlite или беркли.
(0019441)
Parasite (administrator)
15-11-2019 07:10

>можно проверить на файловом тайлохранилище вместо sqlite или беркли.
Вот опять руки дошли до этого бага. Докладаюсь:

1. Просмотр карты заполнения - САС пухнет, причем очень быстро (>600Мб в памяти за меньше чем минуту работы по построению карты заполнения на глубоком зуме со 100% заполнением там). Кэш - SQLite.

2. Экспорт этого кэша SQLite в обычный тайловый кэш - процесс идет, уже >500К тайлов обработано, САС токи НЕ пухнет.

Сдается мне, где-то утечка в многопоточном доступе к кэшу в базоводе ("Операции с кэшем" - вроде как однопоточная задача, судя по всему? И в ней не пухнет).

Как распакует всё в файловый - проверю на нем, будет ли пухнуть (что-то подсказывает, что не будет, ибо никогда ранее на нём не пух). Распаковка займет пару суток - кэш таки большой...Сообщу по этому пункту, как оно разродится.
(0019442)
vdemidov (manager)
15-11-2019 09:54

>2. Экспорт этого кэша SQLite в обычный тайловый кэш - процесс идет, уже >500К тайлов обработано, САС токи НЕ пухнет.
Экспорт через операцию с выделенной областью или в менеджере кэша?
Если в менеджере кэша, то там совсем другой механизм обработки баз, чем при обычной работе.

>1. Просмотр карты заполнения - САС пухнет, причем очень быстро
Значит точно утечка или проблема внутри кода конкретного типа тайлохранилища.

> Сообщу по этому пункту, как оно разродится.
Ждем.

ЗЫЖ На всякий случай вопрос. Ты когда САС обновляешь, не забываешь все dll свежие подкладывать? А то там движок SQLite уже пару раз обновлялся.
(0019445)
Parasite (administrator)
15-11-2019 11:28

>Экспорт через операцию с выделенной областью или в менеджере кэша?
Через менеджер кэша.

>то там совсем другой механизм обработки баз, чем при обычной работе.
Ну вот с ним как раз всё ОК, судя по всему. САС сейчас стоит в памяти как влитой уже который час (экспорт - идет, пара десятков миллионов тайлов - уже обработано ОК).

>Значит точно утечка или проблема внутри кода конкретного типа тайлохранилища.
Проверено на Беркли и SQLite - на обоих проблема в наличии. Судя по всему, льется где-то еще ДО конкретного движка базовода (но скорее всего уже ПОСЛЕ собственно операций с тайлами - попробую на тайловом кэше как завершится, скажу точно). И в менеджере кэша (с теми же движками базоводов, теми же ДЛЛками и прочих равных) проблема не наблюдается.

>Ты когда САС обновляешь, не забываешь все dll свежие подкладывать? А то там движок SQLite уже пару раз обновлялся.
Обновлял прошлый раз всю папку - переносил только инишник. И проблема не только с SQLite, но и с Беркли тоже в той же мере. Таки где-то в самом САСе подливает...
(0019446)
vdemidov (manager)
15-11-2019 12:38

>Через менеджер кэша.
Ну, так там нет полноценной работы тайлохранилища. Просто идет обход всех баз в файловой иерархии, и обработка каждой из них в отдельности. А при работе тайлохранилища, приходится кэшировать открытие баз, что бы не открывать их ради каждого тайла. Вот там похоже и беда.

>Проверено на Беркли и SQLite - на обоих проблема в наличии.
Ну, так оно ж написано одним человеком, SQLite на основе Беркли, так что все логично. Похоже проблема даже не с утечкой, а с излишним кэшированием открытых баз. На малых объемах это не заметно, а вот с большим кэшем уже появляются проблемы.

> И проблема не только с SQLite, но и с Беркли тоже в той же мере. Таки где-то в самом САСе подливает...
Ну, то я на всякий случай спросил.
(0019452)
Parasite (administrator)
17-11-2019 18:40

>> Сообщу по этому пункту, как оно разродится.
>Ждем.

Сообщаю:
1. Конвертация всего кэша (ок 100Гб/70M тайлов) из SQLite в классический тайловый кэш через Менеджер кэша - ОК, конвертация успешна, САС в памяти не пухнет.
2. Проверка сконвертированного тайлового кэша картой заполнения - ОК, САС в памяти не пухнет.
3. Проверка сконвертированого кэша перекачкой по выделению (100% заполнение кэшем - кача как такового нет, есть только строки "Данный файл имеется в кэше") в 4 параллельных потока - ОК, САС в памяти не пухнет.
4. Условно-длительная работа с просмотром карты\перемещением экрана\сменой зумов - ОК, САС в памяти не пухнет.

ИТОГО: проблема только с большим кэшем типа "база данных".

Прилагаю логи, собранные дебажной версией при холодном старте и после успешного завершения всего процесса на тайловом кэше перекачкой (п.3 выше) - то, что гарантированно валилось в OOM на кэше типа "база данных": 2 файла, start2.txt + end2.txt.
(0019462)
vdemidov (manager)
18-11-2019 10:05
edited on: 18-11-2019 11:45

Ну, тогда остается только надеятся, что Zed обратит внимание и займется.

ЗЫЖ Ну, похоже, можно не надеятся.
 18-11-2019 12:07 zed Assigned To zed =>

(0019481)
Parasite (administrator)
19-11-2019 12:39

>Ну, похоже, можно не надеятся.
Так наше дело - зарепортить. Значит, так и будем жить с критическим багом в проде, проявляемом при значениях САСа по умолчанию (кэш в БД), где наступление на эти же грабли другими - вопрос лишь времени и размера их кэша.

- Users who viewed this issue
User List Anonymous (458x), goodzon (1x), vdemidov (84x), Parasite (71x), Tolik (6x), zed (14x), noxicus (2x), RedRat (1x), MontoyaSat (1x), kalakotkas (1x), aflexus (2x), kosmos_b (2x), rass (1x), fa_14 (1x), sergeyka (1x), Robbi (1x)
Total Views 647
Last View 15-12-2019 21:25

- Issue History
Date Modified Username Field Change
23-06-2019 15:47 Parasite New Issue
23-06-2019 15:47 Parasite File Added: 123.jpg
24-06-2019 06:41 vdemidov Note Added: 0018746
24-06-2019 06:41 vdemidov Status new => feedback
28-06-2019 14:56 Parasite Note Added: 0018765
28-06-2019 14:56 Parasite Status feedback => new
28-06-2019 14:56 Parasite Note Edited: 0018765 View Revisions
28-06-2019 14:57 Parasite Note Edited: 0018765 View Revisions
08-07-2019 09:37 vdemidov Product Version .Nightly => 190707
01-09-2019 17:31 Parasite File Added: good.jpg
01-09-2019 17:31 Parasite File Added: bad.jpg
01-09-2019 17:38 Parasite Note Added: 0019310
01-09-2019 18:53 vdemidov Note Added: 0019311
01-09-2019 18:53 vdemidov Status new => feedback
02-09-2019 14:40 Parasite File Added: good.txt
02-09-2019 14:40 Parasite File Added: bad.txt
02-09-2019 14:41 Parasite File Added: bad2.jpg
02-09-2019 14:46 Parasite Note Added: 0019312
02-09-2019 14:46 Parasite Status feedback => new
02-09-2019 15:45 vdemidov Note Added: 0019313
02-09-2019 15:45 vdemidov File Deleted: bad2.jpg
02-09-2019 16:07 Parasite Note Added: 0019314
02-09-2019 16:08 Parasite Note Edited: 0019314 View Revisions
02-09-2019 16:27 vdemidov Note Added: 0019315
02-09-2019 16:35 vdemidov Note Added: 0019316
02-09-2019 17:07 Parasite Note Added: 0019317
02-09-2019 17:54 vdemidov Note Added: 0019318
03-09-2019 16:54 vdemidov Note Added: 0019319
21-09-2019 08:00 Parasite Note Added: 0019329
21-09-2019 08:01 Parasite File Added: before.txt
21-09-2019 08:01 Parasite File Added: after.txt
23-09-2019 09:36 vdemidov Note Added: 0019330
23-09-2019 17:18 Parasite Note Added: 0019331
23-09-2019 17:18 Parasite Severity major => block
23-09-2019 17:25 Parasite Priority high => urgent
26-09-2019 08:20 vdemidov Note Added: 0019336
26-09-2019 16:37 Parasite Note Added: 0019344
26-09-2019 19:07 vdemidov Note Added: 0019347
26-09-2019 23:55 Parasite Note Added: 0019348
27-09-2019 07:36 vdemidov Note Added: 0019351
15-11-2019 07:10 Parasite Note Added: 0019441
15-11-2019 09:54 vdemidov Note Added: 0019442
15-11-2019 09:54 vdemidov Status new => feedback
15-11-2019 11:28 Parasite Note Added: 0019445
15-11-2019 11:28 Parasite Status feedback => new
15-11-2019 12:38 vdemidov Note Added: 0019446
17-11-2019 18:40 Parasite Note Added: 0019452
17-11-2019 18:41 Parasite File Added: start2.txt
17-11-2019 18:41 Parasite File Added: end2.txt
18-11-2019 10:05 vdemidov Note Added: 0019462
18-11-2019 10:05 vdemidov Assigned To => zed
18-11-2019 10:05 vdemidov Status new => assigned
18-11-2019 10:07 zed Assigned To zed =>
18-11-2019 10:07 zed Status assigned => confirmed
18-11-2019 11:44 vdemidov Note Edited: 0019462 View Revisions
18-11-2019 11:45 vdemidov Note Edited: 0019462 View Revisions
19-11-2019 07:38 vdemidov Target Version => 20xxxx
19-11-2019 12:39 Parasite Note Added: 0019481
26-11-2019 05:52 Parasite Summary Льется память при перепроверке кэша в Беркли => Льется память при перепроверке кэша в Беркли\SQLite



Copyright © 2007 - 2019 SAS.Planet Team