0003458: Льется память при перепроверке кэша в Беркли\SQLite

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 (2369x), VMatveev (1x), vdemidov (87x), waledresi (1x), zloyboy79 (13x), zed (15x), nnngrach (1x), Garl (1x), Shurik (1x), kalakotkas (2x), gma (1x), Parasite (72x), saldek (1x), goodzon (1x), Tolik (6x), noxicus (2x), RedRat (1x), MontoyaSat (1x), aflexus (2x), kosmos_b (2x), rass (1x), fa_14 (1x), sergeyka (1x), Robbi (1x)
Total Views	2584
Last View	21-11-2024 13:09

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	=> 211230
19-11-2019 12:39	Parasite	Note Added: 0019481
26-11-2019 05:52	Parasite	Summary	Льется память при перепроверке кэша в Беркли => Льется память при перепроверке кэша в Беркли\SQLite
02-12-2020 22:03	zed	Relationship added	has duplicate 0003728
30-12-2021 08:58	zed	Target Version	211230 => 26xxxx

SASGIS