0002735: "Out of memory" при экспорте меток в Debug версии

Notes
(0015966) vdemidov (manager) 29-05-2015 12:30	Ну что я могу сказать Out of memory оно и есть. До перехода на 64-битный компилятор (а это даже не планируется) вряд ли что-то изменится. Все данные программы должны влезать в 2 гигабайта.

(0015967) Fetser (reporter) 29-05-2015 12:33	Categorymarks.sml + marks.sml = 140 Мб это уже так критично?

(0015968) zed (manager) 29-05-2015 12:33	Просто экспорт нужно делать по-умнее. Не строить дерево в памяти, а сделать итератор.

(0015969) vdemidov (manager) 29-05-2015 12:36	Само дерево в памяти жрет совсем не много. Жрет и падает на создании XML при помощи парсера.

(0015970) vdemidov (manager) 29-05-2015 12:40	> Categorymarks.sml + marks.sml = 140 Мб это уже так критично? Возможно. Грубо 140 * 2 = 280 Мб так как хранится в двух экземплярах в памяти - в виде датасета и объектов. Еще 140 Мб а то и больше на результат текста kml. И думаю где-то 140 * 2 Мб на представление xml дерева в виде парсера. Итого 700 Мб. Заметная часть от 2-х Гб. Плюс советую проверить настройки кэша в памяти для тайлов. Он тоже может съедать дофига памяти.

(0015971) zed (manager) 29-05-2015 12:48	А, в этом дело. Ну, может тогда переделать запись в kml без всяких там XMLDocument? Получится, конечно, не очень красиво, зато не будет отжирать память.

(0015972) Fetser (reporter) 29-05-2015 12:53	Немного цифр версия SAСSPlanet 141221 при открытии этой базы заняла оперативки 224 Мб при экспорте в KMZ оперативки слопала 600 Мб с работой справилась версия SASPlanet 150528 при открытии 365 Мб оперативки при экспорте потребление возросло до 1600 Мб после этого упала

(0015973) vasketsov (manager) 29-05-2015 13:28 edited on: 29-05-2015 13:30	>До перехода на 64-битный компилятор (а это даже не планируется) Если это та же самая база, на которой игрался я, а скорее всего так оно и есть, то в kml там всё залетает отлично, после того как я сегодня подчистил ссылку на MemStream для корректной смерти IBinaryData - и в kmz нормально экспортируется. EXE-ха x32 даже при сборке на Win 8.1 x64 XE2. Экспорт в kml/kmz у нас идентичный (через Al). >Итого 700 Мб >оперативки слопала 600 Мб с работой справилась Оценки вполне соответствуют друг другу, плюс-минус пол-лаптя. >при экспорте потребление возросло до 1600 Мб Упс. >Не строить дерево в памяти, а сделать итератор Есть подозрение, что в принципе не надо пытаться класть в kml то, что не влазит в 2 гига памяти даже за вычетом уже использованного пространства. Лучше сразу использовать правильный целевой формат. Но здесь проблема где-то рядом, около этого самого Упс.

(0015974) vasketsov (manager) 29-05-2015 14:26	>сделать итератор Это конечно было бы совсем замечательно, если бы нашёлся доброволец, который бы сделал миграцию меток между двумя БД меток по типу менеджера кэша.

(0015975) zed (manager) 29-05-2015 17:56 edited on: 29-05-2015 17:59	>после того как я сегодня подчистил ссылку на MemStream Ну, в SAS оно там давно подчищалось. >даже при сборке на Win 8.1 x64 XE2 Имею мнение, что важна только версия компилятора, но никак ни ОС, на которой происходит сборка. >при экспорте потребление возросло до 1600 Мб после этого упала А вот у меня такого не наблюдается. Экспортирует нормально, пиковое использование памяти ~ 750Мб. В простое около 300 Мб. При экспорте в kml, в пике было ~ 650Мб.

(0015976) zed (manager) 29-05-2015 18:08	А, понял в чём причина. Во всём виновата Eurekalog. Релизная версия и дебажная версия без эврики работают нормально, а вот с эврикой идёт перерасход памяти. То ли там утечка, то ли это так много надо служебной информации для эврики, чтобы всё контролировать, но ноги растут оттуда.

(0015977) vasketsov (manager) 30-05-2015 09:50	>виновата Eurekalog Пришло время 7.2.3 Ent?

(0015978) zed (manager) 30-05-2015 10:09	Если SACS не падает с той же эврикой, то надо разобраться. Не факт, что переход на новую версию тут поможет.

(0015980) zed (manager) 31-05-2015 18:31	Да нет, и SACS ведёт себя аналогично - дебажной версии не хватает памяти, релизная работает нормально. И самое интересное, что апгрейд эврики до версии 7.2.3 так же не помогает. Всё падает с Out of memory. Если у эврики отключить слежение за утечками памяти, то всё это безобразие прекращается. Вот что пишут в доках (для 7.x): This technique generating the following limitations: 1. Enabling memory leak detection has little performance penalty (no more than about 5% for memory operations), because EurekaLog needs to build call stack for each memory allocation; 2. Enabling memory leak detection has little memory usage penalty (about 200 bytes for each memory allocation on x86-32 and about 400 bytes on x86-64); 3. Memory leak report automatically hides Assembler and CPU sections; 4. EurekaLog will not execute standard events during processing memory leak reports (this is because required resources was freed); 5. Call stack for memory leak is limited to 35 entries; 6. Memory leaks detection works only for standard Delphi's heap / memory manager (i.e. GetMem/FreeMem/ReallocMem); it can not find leaks with other memory managers (like HeapAlloc/HeapFree or VirtualAlloc/VirtualFree). Use resource leaks ability for that. 7. EurekaLog is unable to show human-readable call stack if DLL which created leak has been unloaded (this limitation is applicable only for applications with installed shared memory manager). 8. If you use shared memory manager - you must compile all modules with same memory manager settings. If you don't use shared memory manager - there is no additional limitations. 9. (C++ Builder only) "Dynamic RTL" is not supported in C++ Builder. If you enable "Dynamic RTL" option - EurekaLog's memory features will be disabled.

(0016238) vdemidov (manager) 29-07-2015 13:32	Увы за диагностику в дебажной версии нужно платить.

Users who viewed this issue
User List	Anonymous (2881x), zed (2x), vdemidov (3x), Parasite (2x), aflexus (1x)
Total Views	2889
Last View	23-04-2024 10:35

Issue History
Date Modified	Username	Field	Change
29-05-2015 12:03	Fetser	New Issue
29-05-2015 12:03	Fetser	File Added: SASPlanet.Debug KML.elf
29-05-2015 12:04	Fetser	File Added: SASPlanet.Debug KMZ.elf
29-05-2015 12:30	vdemidov	Note Added: 0015966
29-05-2015 12:33	Fetser	Note Added: 0015967
29-05-2015 12:33	zed	Note Added: 0015968
29-05-2015 12:36	vdemidov	Note Added: 0015969
29-05-2015 12:40	vdemidov	Note Added: 0015970
29-05-2015 12:48	zed	Note Added: 0015971
29-05-2015 12:53	Fetser	Note Added: 0015972
29-05-2015 13:28	vasketsov	Note Added: 0015973
29-05-2015 13:30	vasketsov	Note Edited: 0015973	View Revisions
29-05-2015 14:26	vasketsov	Note Added: 0015974
29-05-2015 17:56	zed	Note Added: 0015975
29-05-2015 17:59	zed	Note Edited: 0015975	View Revisions
29-05-2015 18:08	zed	Note Added: 0015976
30-05-2015 09:50	vasketsov	Note Added: 0015977
30-05-2015 10:09	zed	Note Added: 0015978
31-05-2015 18:31	zed	Note Added: 0015980
31-05-2015 18:41	zed	Summary	SAS.Planet.Nightly.150528.8771 ошибка при экспорте => "Out of memory" при экспорте меток в Debug версии
31-05-2015 18:41	zed	Description Updated	View Revisions
11-06-2015 12:55	zed	Relationship added	related to 0002745
29-07-2015 13:32	vdemidov	Note Added: 0016238
29-07-2015 13:32	vdemidov	Status	new => resolved
29-07-2015 13:32	vdemidov	Resolution	open => not fixable
29-07-2015 13:32	vdemidov	Assigned To	=> vdemidov
29-07-2015 13:32	vdemidov	Status	resolved => closed

SASGIS