|
Notes |
|
|
|
|
Поставь Process Explorer и добавь сюда скриншоты вкладки Performance информации о процессе САС до начала проверки и когда память уже заметно выросла. Ну хотя бы до 4-5 гигов. Еще на всякий случай уточни кэш лежит чисто локально или где-то на сетевом диске. |
|
|
|
(0018765)
|
|
Parasite
|
28-06-2019 14:56
(edited on: 28-06-2019 14:57) |
|
1. Пока что нет технической возможности ставить\перепроверять (территориально вдали от любого кэша). Но вангую, что должно быть репродуцируемо на любой стороне, включая твою.
В моем случае было ВСЕГДА повторяемо на ~ 5.6M тайлов в Беркли, ~ 80 Гб общим файловым размером.
2. Кэш проверялся\лежал на локальном диске.
|
|
|
|
|
1. Скрины с PE докинул. Good.jpg - сразу после старта САСа, bad.jpg - когда вылезло сообщение "Out of memory" - см.ниже.
2. Проблема повторяется и на кэше SQLite в той же мере (скрины с него, соббсно).
Проверялся БОЛЬШОЙ кэш в SQLite, тип файлов - PNG, 100% заполнение (все тайлы - в кэше). Проверка шла в 4 потока (стоит галка "Разбить закачку....4 потока") + галка "Закрывать окна по окончании загрузки". Примерно через час работы занятая САСом память доросла до 4х гигов (см.скрин), в окнах загрузки побежали сообщения "Недостаточно памяти для завершения операции" и затем процесс в окнах остановился. При попытке выйти с САСа - вылезло окно "Out of memory", в итоге - выход по 3м кнопкам. |
|
|
|
|
Так. Каких 4 Гб занятых САС? Ты помнится писал:
> При этом размер самого саса как процесса - вполне нормален, и не растет.
Это же две большие разницы? И запросы на доп информацию совсем другие.
Нужна дебажная версия САС и примерно через пол часа, не останавливая закачек, зайти в окошко "View\Debug Info" и нажать "Save to file...". Сам файл прицепить сюда.
В идеале проверить на обычном файловом кэше. Но то уже такое дело. |
|
|
|
|
1. Приаттачил 2 файла - моментально после запуска, и тот же процесс - после часа работы проверки кэша (размер в памяти был примерно полтора гига).
2. На тайловом кэше такого ни разу не замечал за всё время, иначе давно бы сообщил.
3. При выходе с дебажки - вылез мессидж bad2.jpg. Elf при этом не создался - прикладывать нечего.
4. >Так. Каких 4 Гб занятых САС? Ты помнится писал:
То было в TaskManager - в нем размер саса примерно 50...70Мб, но ты сказал в него больше не смотреть. Гигабайты на скрине - не из TaskManager, а из ProcessExlorer.
5. >не останавливая закачек
На всякий уточню: закачек НЕТ - идет перепроверка кэша с винта, со 100% доступностью оного локально. В инет прожка не ходит, закачек как таковых нет. |
|
|
|
|
> 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 процесса"? Надо будет попробовать в один поток на досуге....
|
|
|
|
|
>Воспроизводимо И с Berkeley, И с SQLite в одинаковой мере и с одинаковыми эффектами.
>Я с тому, что проблема явно не только в "библиотеке работы с SQLite".
Ну, реализовывал оба тайлохранилища один и тот же человек, мог просто одинаковые, но при этом не очень корректные для какого-то режима параметры задать или алгоритмы применить :) Всякое бывает.
> Может, дело в скорости обращения к хранилищу, где перепроверка в разы быстрее скачки - и при оной что-то где-то открывается много быстрее, чем успевает закрываться?
Все может быть. Может даже быть такое, что на файловом тайлохранилище проблема не воспроизводится просто потому, что оно медленнее работает.
>PS: а может ли проблема быть на стадии функционала "Разбить закачку на 4 процесса"? Надо будет попробовать в один поток на досуге....
Вряд ли, но если попробуешь, то о любом результате отпишись тут. Вдруг пригодится. |
|
|
|
|
>Я слегка озадачен количеством созданий и удалений объектов TEnumDoublePointBySingleProjectedLine:
Проверил, таки все правильно. Оно на каждый тайл должно проверить попадает ли он в полигон. А для этого нужно перебрать все отрезки образующие полигон. Так что тут все правильно, разве что крышу сносит у дельфовского менеджера памяти. Но тогда оно так же должно работать и на файловом тайлохранилище. |
|
|
|
|
>оно так же должно работать и на файловом тайлохранилище.
Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия... |
|
|
|
|
>Как можно БЫСТРО разобрать SQLite в тайловый кэш, для перепроверки уже на нем? Встроенный конвертор будет 99млн тайлов\200Гб в один поток пилить до второго пришествия...
Больше никак. По крайней мере готовых вариантов я не знаю. |
|
|
|
|
|
Как соберется следующая ночная версия попробуй ее погонять. Я убрал там создание TEnumDoublePointBySingleProjectedLine на каждую проверку попадание тайла в прямоугольник. Но думаю, все же дело в реализации конкретных тайлохранилищ. Где-то там есть кэширование излишнее или фрагментация памяти. |
|
|
|
|
>Как соберется следующая ночная версия попробуй ее погонять
Визуально различий нет. Всё как и раньше (процесс пухнет в памяти).
Аттачу свежие before.txt при запуске САСа/after.txt при памяти процесса ~1.2Gb
PS: при проверке кэша в один проход (без юзания фичи "Разбить закачку на N потоков") - всё как и прежде. Пухнет в памяти примерно так же, разве что возможно чуть медленнее (но это неточно). |
|
|
|
|
Ну, все так и ожидалось. Но проверить стоило, чтобы исключить окончательно.
Обработано прмерно 2.6 миллиона тайлов. Утекло грубо говоря 1 гиг. Получается до 500 байт на тайл.
Странно. Для рапакованных точно мало, для самих файлов, вроде бы, тоже маловато.
А какого там тайлы размера в среднем? |
|
|
|
|
>А какого там тайлы размера в среднем?
В данном конкретном - кэш тайлов карты https://map.nostramap.com (но от карты сий бажик не зависит, таки проверено). Кэша примерно 200Гб, САСом успешно проверяется едва ли 25%, и потом его начинает дико глючить (с разнообразными эффектами, но одним финалом ака "три кнопки") по OOM. В итоге успешно скачанный ранее тем же САСом кэш нет никакой возможности проверить даже на дырки.
На всякий случай повышу приоритет тикета. |
|
|
|
|
>В данном конкретном - кэш тайлов карты https://map.nostramap.com.
Мне это ни о чем не говорит. Глянь какой там в среднем размер тайла.
> Кэша примерно 200Гб, САСом успешно проверяется едва ли 25%
Тоесть гиг 50 таки проверяется. Значит это точно не сами тайлы. Нужно думать.
>На всякий случай повышу приоритет тикета.
А смысл? |
|
|
|
|
>Глянь какой там в среднем размер тайла.
"Там" - где конкретно?
Если в кэше - то на диске тайлов нет (а есть базы SQLITE), а если на сервере - то надо перекачивать условно-большой кусок в стандартный кэш сугубо для сбора достоверной статистики. Но в любом случае - тайлы там PNG, и карта таки обычная (именно что карта, не полноцветные снимки) - так что размер тайлов должен быть небольшим, вполне сравнимым с гугломаповским.
>Тоесть гиг 50 таки проверяется. Значит это точно не сами тайлы.
Да, непохоже на сами тайлы. И при тайловом кэше я такого поведения никогда не замечал - всё ж не первый день с САСом...
Может, какие-нибудь хэндлеры открываем к базоводам, но не закрываем? Вот они и копятся, пока всё не упадет в OOM. Помнится, где-то в Беркли в свое время неск.лет назад мы мучались с закрытием баз по таймауту - там тоже кучи открытых баз дико открывались и висели, особенно при перепроверке уже готового...
>А смысл?
Для статистики. :) |
|
|
|
|
|
Ну, в общем это к Zed'у, автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь. |
|
|
|
|
>автору тайлохранилищ. Я туда в ближайшие годы лезть не собираюсь.
Это было только мое личное предположение. Там по факту может быть что угодно еще. |
|
|
|
|
> Там по факту может быть что угодно еще.
Ой, вряд ли. Но можно проверить на файловом тайлохранилище вместо sqlite или беркли. |
|
|
|
|
>можно проверить на файловом тайлохранилище вместо sqlite или беркли.
Вот опять руки дошли до этого бага. Докладаюсь:
1. Просмотр карты заполнения - САС пухнет, причем очень быстро (>600Мб в памяти за меньше чем минуту работы по построению карты заполнения на глубоком зуме со 100% заполнением там). Кэш - SQLite.
2. Экспорт этого кэша SQLite в обычный тайловый кэш - процесс идет, уже >500К тайлов обработано, САС токи НЕ пухнет.
Сдается мне, где-то утечка в многопоточном доступе к кэшу в базоводе ("Операции с кэшем" - вроде как однопоточная задача, судя по всему? И в ней не пухнет).
Как распакует всё в файловый - проверю на нем, будет ли пухнуть (что-то подсказывает, что не будет, ибо никогда ранее на нём не пух). Распаковка займет пару суток - кэш таки большой...Сообщу по этому пункту, как оно разродится. |
|
|
|
|
>2. Экспорт этого кэша SQLite в обычный тайловый кэш - процесс идет, уже >500К тайлов обработано, САС токи НЕ пухнет.
Экспорт через операцию с выделенной областью или в менеджере кэша?
Если в менеджере кэша, то там совсем другой механизм обработки баз, чем при обычной работе.
>1. Просмотр карты заполнения - САС пухнет, причем очень быстро
Значит точно утечка или проблема внутри кода конкретного типа тайлохранилища.
> Сообщу по этому пункту, как оно разродится.
Ждем.
ЗЫЖ На всякий случай вопрос. Ты когда САС обновляешь, не забываешь все dll свежие подкладывать? А то там движок SQLite уже пару раз обновлялся. |
|
|
|
|
>Экспорт через операцию с выделенной областью или в менеджере кэша?
Через менеджер кэша.
>то там совсем другой механизм обработки баз, чем при обычной работе.
Ну вот с ним как раз всё ОК, судя по всему. САС сейчас стоит в памяти как влитой уже который час (экспорт - идет, пара десятков миллионов тайлов - уже обработано ОК).
>Значит точно утечка или проблема внутри кода конкретного типа тайлохранилища.
Проверено на Беркли и SQLite - на обоих проблема в наличии. Судя по всему, льется где-то еще ДО конкретного движка базовода (но скорее всего уже ПОСЛЕ собственно операций с тайлами - попробую на тайловом кэше как завершится, скажу точно). И в менеджере кэша (с теми же движками базоводов, теми же ДЛЛками и прочих равных) проблема не наблюдается.
>Ты когда САС обновляешь, не забываешь все dll свежие подкладывать? А то там движок SQLite уже пару раз обновлялся.
Обновлял прошлый раз всю папку - переносил только инишник. И проблема не только с SQLite, но и с Беркли тоже в той же мере. Таки где-то в самом САСе подливает... |
|
|
|
|
>Через менеджер кэша.
Ну, так там нет полноценной работы тайлохранилища. Просто идет обход всех баз в файловой иерархии, и обработка каждой из них в отдельности. А при работе тайлохранилища, приходится кэшировать открытие баз, что бы не открывать их ради каждого тайла. Вот там похоже и беда.
>Проверено на Беркли и SQLite - на обоих проблема в наличии.
Ну, так оно ж написано одним человеком, SQLite на основе Беркли, так что все логично. Похоже проблема даже не с утечкой, а с излишним кэшированием открытых баз. На малых объемах это не заметно, а вот с большим кэшем уже появляются проблемы.
> И проблема не только с SQLite, но и с Беркли тоже в той же мере. Таки где-то в самом САСе подливает...
Ну, то я на всякий случай спросил. |
|
|
|
|
>> Сообщу по этому пункту, как оно разродится.
>Ждем.
Сообщаю:
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 =>
|
|
|
|
|
>Ну, похоже, можно не надеятся.
Так наше дело - зарепортить. Значит, так и будем жить с критическим багом в проде, проявляемом при значениях САСа по умолчанию (кэш в БД), где наступление на эти же грабли другими - вопрос лишь времени и размера их кэша. |
|
123.jpg (163,045) 23-06-2019 15:47
good.txt (107,743) 02-09-2019 14:40