SASGIS - SAS.Планета
View Issue Details
0003458SAS.ПланетаРефакторингpublic23-06-2019 15:4730-12-2021 08:58
Parasite 
 
urgentblockalways
confirmedopen 
Windows7Enterprise
190707 
26xxxx 
0003458: Льется память при перепроверке кэша в Беркли\SQLite
Судя по всему, где-то в САСе дико льется память при перепроверке кэша, сохраненного в беркли.
При 100% тайлов в кэше, и попытке просто перекачки данного участка - в окошке скачки наблюдаются обычные строки "Тайл уже в кэше" (что нормально), но при этом дико течет свободная память в системе. См.аттач. По достижении предела физической памяти - начинает дико свопиться.

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

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

Проверяемо\повторяемо в текущей ночнушке \~5M тайлов в беркли, 100% заполнение.
1. Накачать много кэша в Беркли со 100% доступностью.
2. Попробовать проверить скачанный кэш.
No tags attached.
has duplicate 0003728closed zed Ошибка can't allocate the dib handle при скачивании и конвертации 
jpg 123.jpg (163,045) 23-06-2019 15:47
http://www.sasgis.org/mantis/file_download.php?file_id=2304&type=bug
jpg

jpg good.jpg (94,335) 01-09-2019 17:31
http://www.sasgis.org/mantis/file_download.php?file_id=2355&type=bug
jpg

jpg bad.jpg (93,838) 01-09-2019 17:31
http://www.sasgis.org/mantis/file_download.php?file_id=2356&type=bug
jpg

txt good.txt (107,743) 02-09-2019 14:40
http://www.sasgis.org/mantis/file_download.php?file_id=2357&type=bug
txt bad.txt (109,790) 02-09-2019 14:40
http://www.sasgis.org/mantis/file_download.php?file_id=2358&type=bug
txt before.txt (108,349) 21-09-2019 08:01
http://www.sasgis.org/mantis/file_download.php?file_id=2365&type=bug
txt after.txt (110,155) 21-09-2019 08:01
http://www.sasgis.org/mantis/file_download.php?file_id=2366&type=bug
txt start2.txt (104,814) 17-11-2019 18:41
http://www.sasgis.org/mantis/file_download.php?file_id=2391&type=bug
txt end2.txt (107,714) 17-11-2019 18:41
http://www.sasgis.org/mantis/file_download.php?file_id=2392&type=bug
Issue History
23-06-2019 15:47ParasiteNew Issue
23-06-2019 15:47ParasiteFile Added: 123.jpg
24-06-2019 06:41vdemidovNote Added: 0018746
24-06-2019 06:41vdemidovStatusnew => feedback
28-06-2019 14:56ParasiteNote Added: 0018765
28-06-2019 14:56ParasiteStatusfeedback => new
28-06-2019 14:56ParasiteNote Edited: 0018765bug_revision_view_page.php?bugnote_id=18765#r7421
28-06-2019 14:57ParasiteNote Edited: 0018765bug_revision_view_page.php?bugnote_id=18765#r7422
08-07-2019 09:37vdemidovProduct Version.Nightly => 190707
01-09-2019 17:31ParasiteFile Added: good.jpg
01-09-2019 17:31ParasiteFile Added: bad.jpg
01-09-2019 17:38ParasiteNote Added: 0019310
01-09-2019 18:53vdemidovNote Added: 0019311
01-09-2019 18:53vdemidovStatusnew => feedback
02-09-2019 14:40ParasiteFile Added: good.txt
02-09-2019 14:40ParasiteFile Added: bad.txt
02-09-2019 14:41ParasiteFile Added: bad2.jpg
02-09-2019 14:46ParasiteNote Added: 0019312
02-09-2019 14:46ParasiteStatusfeedback => new
02-09-2019 15:45vdemidovNote Added: 0019313
02-09-2019 15:45vdemidovFile Deleted: bad2.jpg
02-09-2019 16:07ParasiteNote Added: 0019314
02-09-2019 16:08ParasiteNote Edited: 0019314bug_revision_view_page.php?bugnote_id=19314#r7472
02-09-2019 16:27vdemidovNote Added: 0019315
02-09-2019 16:35vdemidovNote Added: 0019316
02-09-2019 17:07ParasiteNote Added: 0019317
02-09-2019 17:54vdemidovNote Added: 0019318
03-09-2019 16:54vdemidovNote Added: 0019319
21-09-2019 08:00ParasiteNote Added: 0019329
21-09-2019 08:01ParasiteFile Added: before.txt
21-09-2019 08:01ParasiteFile Added: after.txt
23-09-2019 09:36vdemidovNote Added: 0019330
23-09-2019 17:18ParasiteNote Added: 0019331
23-09-2019 17:18ParasiteSeveritymajor => block
23-09-2019 17:25ParasitePriorityhigh => urgent
26-09-2019 08:20vdemidovNote Added: 0019336
26-09-2019 16:37ParasiteNote Added: 0019344
26-09-2019 19:07vdemidovNote Added: 0019347
26-09-2019 23:55ParasiteNote Added: 0019348
27-09-2019 07:36vdemidovNote Added: 0019351
15-11-2019 07:10ParasiteNote Added: 0019441
15-11-2019 09:54vdemidovNote Added: 0019442
15-11-2019 09:54vdemidovStatusnew => feedback
15-11-2019 11:28ParasiteNote Added: 0019445
15-11-2019 11:28ParasiteStatusfeedback => new
15-11-2019 12:38vdemidovNote Added: 0019446
17-11-2019 18:40ParasiteNote Added: 0019452
17-11-2019 18:41ParasiteFile Added: start2.txt
17-11-2019 18:41ParasiteFile Added: end2.txt
18-11-2019 10:05vdemidovNote Added: 0019462
18-11-2019 10:05vdemidovAssigned To => zed
18-11-2019 10:05vdemidovStatusnew => assigned
18-11-2019 10:07zedAssigned Tozed =>
18-11-2019 10:07zedStatusassigned => confirmed
18-11-2019 11:44vdemidovNote Edited: 0019462bug_revision_view_page.php?bugnote_id=19462#r7530
18-11-2019 11:45vdemidovNote Edited: 0019462bug_revision_view_page.php?bugnote_id=19462#r7531
19-11-2019 07:38vdemidovTarget Version => 211230
19-11-2019 12:39ParasiteNote Added: 0019481
26-11-2019 05:52ParasiteSummaryЛьется память при перепроверке кэша в Беркли => Льется память при перепроверке кэша в Беркли\SQLite
02-12-2020 22:03zedRelationship addedhas duplicate 0003728
30-12-2021 08:58zedTarget Version211230 => 26xxxx

Notes
(0018746)
vdemidov   
24-06-2019 06:41   
Поставь Process Explorer и добавь сюда скриншоты вкладки Performance информации о процессе САС до начала проверки и когда память уже заметно выросла. Ну хотя бы до 4-5 гигов. Еще на всякий случай уточни кэш лежит чисто локально или где-то на сетевом диске.
(0018765)
Parasite   
28-06-2019 14:56   
(edited on: 28-06-2019 14:57)
1. Пока что нет технической возможности ставить\перепроверять (территориально вдали от любого кэша). Но вангую, что должно быть репродуцируемо на любой стороне, включая твою.
В моем случае было ВСЕГДА повторяемо на ~ 5.6M тайлов в Беркли, ~ 80 Гб общим файловым размером.

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

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

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

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

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

5. >не останавливая закачек
На всякий уточню: закачек НЕТ - идет перепроверка кэша с винта, со 100% доступностью оного локально. В инет прожка не ходит, закачек как таковых нет.
(0019313)
vdemidov   
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   
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   
02-09-2019 16:27   
>Воспроизводимо И с Berkeley, И с SQLite в одинаковой мере и с одинаковыми эффектами.
>Я с тому, что проблема явно не только в "библиотеке работы с SQLite".
Ну, реализовывал оба тайлохранилища один и тот же человек, мог просто одинаковые, но при этом не очень корректные для какого-то режима параметры задать или алгоритмы применить :) Всякое бывает.

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

>PS: а может ли проблема быть на стадии функционала "Разбить закачку на 4 процесса"? Надо будет попробовать в один поток на досуге....
Вряд ли, но если попробуешь, то о любом результате отпишись тут. Вдруг пригодится.
(0019316)
vdemidov   
02-09-2019 16:35   
>Я слегка озадачен количеством созданий и удалений объектов TEnumDoublePointBySingleProjectedLine:
Проверил, таки все правильно. Оно на каждый тайл должно проверить попадает ли он в полигон. А для этого нужно перебрать все отрезки образующие полигон. Так что тут все правильно, разве что крышу сносит у дельфовского менеджера памяти. Но тогда оно так же должно работать и на файловом тайлохранилище.
(0019317)
Parasite   
02-09-2019 17:07   
>оно так же должно работать и на файловом тайлохранилище.
Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия...
(0019318)
vdemidov   
02-09-2019 17:54   
>Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия...
Больше никак. По крайней мере готовых вариантов я не знаю.
(0019319)
vdemidov   
03-09-2019 16:54   
Как соберется следующая ночная версия попробуй ее погонять. Я убрал там создание TEnumDoublePointBySingleProjectedLine на каждую проверку попадание тайла в прямоугольник. Но думаю, все же дело в реализации конкретных тайлохранилищ. Где-то там есть кэширование излишнее или фрагментация памяти.
(0019329)
Parasite   
21-09-2019 08:00   
>Как соберется следующая ночная версия попробуй ее погонять
Визуально различий нет. Всё как и раньше (процесс пухнет в памяти).
Аттачу свежие before.txt при запуске САСа/after.txt при памяти процесса ~1.2Gb

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

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

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

На всякий случай повышу приоритет тикета.
(0019336)
vdemidov   
26-09-2019 08:20   
>В данном конкретном - кэш тайлов карты https://map.nostramap.com.
Мне это ни о чем не говорит. Глянь какой там в среднем размер тайла.

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

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

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

>А смысл?
Для статистики. :)
(0019347)
vdemidov   
26-09-2019 19:07   
Ну, в общем это к Zed'у, автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь.
(0019348)
Parasite   
26-09-2019 23:55   
>автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь.
Это было только мое личное предположение. Там по факту может быть что угодно еще.
(0019351)
vdemidov   
27-09-2019 07:36   
> Там по факту может быть что угодно еще.
Ой, вряд ли. Но можно проверить на файловом тайлохранилище вместо sqlite или беркли.
(0019441)
Parasite   
15-11-2019 07:10   
>можно проверить на файловом тайлохранилище вместо sqlite или беркли.
Вот опять руки дошли до этого бага. Докладаюсь:

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

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

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

Как распакует всё в файловый - проверю на нем, будет ли пухнуть (что-то подсказывает, что не будет, ибо никогда ранее на нём не пух). Распаковка займет пару суток - кэш таки большой...Сообщу по этому пункту, как оно разродится.
(0019442)
vdemidov   
15-11-2019 09:54   
>2. Экспорт этого кэша SQLite в обычный тайловый кэш - процесс идет, уже >500К тайлов обработано, САС токи НЕ пухнет.
Экспорт через операцию с выделенной областью или в менеджере кэша?
Если в менеджере кэша, то там совсем другой механизм обработки баз, чем при обычной работе.

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

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

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

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

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

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

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

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

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

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

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

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

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