|
Тема
|
Странно управление на паметта
|
|
Автор | nmm (Нерегистриран) |
Публикувано | 20.05.09 16:25 |
|
Здравейте,
Приложението е под Д7, и доста често след повечко работа ми се случва да ми изплюе "Out of memory" по време на изпълнение на различни операции.
Днес забелязах на Windows XP нещо което ме изненада:
При зареждане програмата заема в паметта (в таск менажера го гледам) 36 мб
След известно време работа набъбва до 50.
Като го минимизирам на лентата паметта да пада до под 2мб
Като го ресторна заетата памет вече е 10 мб и колкото и да го мъча не става повече от 20мб.
Не съм си играл да го мъча дали ще ми изкара (и кога) out of memory, защото на моя комп рядко го прави
На Vista не прави така - заема си 36 мб на старт и си ги увеличава полека, независимо дали го минимизарам или не.
Принципно самото екзе е към 18 мб, но е пакетирано с UPX - 5 мб.
Имате ли идея как мога да го накарам да сi освободи паметта, както се получава след минимизиране в XP?
В програмата се ползват доста контроли, някои без сорс и не е задължително да е в моя код проблема. Въпроса е мога ли някак да освобадя паметта през делфито. Ама малко съм скаран със АПИ-тата
| |
Тема
|
Re: Странно управление на паметта
[re: nmm]
|
|
Автор |
Pechenia (нема лабаво ;-) |
Публикувано | 26.05.09 21:31 |
|
Добре е да се пробваш с някакъв инструмент за memory leaks, понеже причините може да са много. Инструмента ще даде насока откъде идва проблема, а след това ще помагаме с API-тата
Все пак пробвай се да пускаш EXE-то без пакетиращи програми - за 13 меги не си струва да имаш още една причина за тревога (освен ако не го ползваш за защита ;-)))
Един линк - http://delphi.about.com/od/toppicks/tp/aatpmemleak.htm
Но принципно бай Гугъл с "delphi memory leaks" е доста щедър, и си струва да пробваш тестово някой платен инструмент.
чети и дишай по-леко
| |
|
Това, което ти казва печения е напълно вярно, но при тебе ситуацията според мен не се дължи на memory leaks (не казвам, че няма, а че и да няма - пак ще се държи по подобен начин ). Първо трябва да си изясниш какво означава "заета памет". Има много видове памет. Поне за два със сигурно трябва да си чувал - виртуална и физическа. Пиша ти това, защото попаднах на един постинг точно по темата. Прочети . Горещо ти препоръчвам да прочетеш и двете цитирани статии от Марк Русинович (а и целия му блог - това е нещо безценно за мене). Това би трябвало да ти поизясни малко нещата.
Linux isn't free, it's worthless.
| |
Тема
|
Re: Странно управление на паметта
[re: Pechenia]
|
|
Автор | nmm (Нерегистриран) |
Публикувано | 15.12.09 22:59 |
|
Така....
Мина доста време, мога смело да кажа че leaks вече няма. Използвах първо Eureka, после (и за постоянно останах) с MemCheck.
За съжаление проблема почти не се реши.
Основните гърмежи "Out of memory" идват от TIB компонентите, по специално TIbDataset и TIBQuery. Проблема идва при зареждане на много или малко записи, с често close/open на датасетите. Не знам уСера колко записа иска да дръпне, за да мога да упралявам динамично единствената настройка на компонента за паметта(BufferChunks).
Ситуациите са две:
1. отваряне на големи датасети ( с по 50к записи вътре) за да успея да ги отворя увеличавам BufferChunks na 20000 (ако е дефаултното 1000 директно гърми с OOM). На второто или третото отваряне на датасета ООМ е на лице, дори и с тази стойност 20000 за BufferChunks.
2. Също така, ако вдигна BufferChunks, когато отварям малки датасети, пак ми гърми с ООМ, да речем сетвам го на 5000 защото искам да отворя датасета веднъж с много записи (с 10000 записа) и 10 пъти с малко (20) записа. При така увеличения BufferChunks, дори и да не зареждам много записи, на 5-6 отваряне отича работата.
Предполагам най смислено е да сменя компонентите с FIBplus, но проекта е голям а автоматичнота "подменячка" GReplace не може да се справи да замени TIB s FIB. Така че това автоматично отпада ако трябва да се сменят ръчно, е равносилно на пренаписване.
Мисля си няма ли начин за "заграбя" много памето още на отваряне, за да намалят проблемите от този род. Реално windowsa има още свободна памет, нещо delphi-то(аз) не се справя с преалокацията.
| |
|
Мда, прав си за IBX компонентите. Проблема в твоя случай не е memory leak, заради който да нямаш свободна памет, а това, че паметта ти е фрагментирана. В този случай можеш да имаш гигабайт свободна памет, но да няма 1 мегабайт последователна (т.е. едно цяло непрекъснато парче).
При IBX-а BufferChunks указва един вид с колко да се увеличи буфера (с памет за колко на брой записа) след като се изчерпа стария. Тъпото в случая (а и от embracadero си е, че след изчерпване на буфера не се заделя нов такъв от XXXX BufferChunks, който да допълни текущия, а се заделя един нов буфер с размер на текущия плюс BufferChunks и съдържанието на стария се прехвърля в новия. Това именно води до фрагментацията на паметта.
Имаш два варианта за борба с този проблем (без да броим преминаването към FIB Plus ). Първият е, където е възможно да включиш UniDirectional пропъртито да е True. По този начин няма да можеш да се разхождаш из дейтасета, а ще може да се обхожда само напред. В този случай не се прави такъв голям буфер, а се пази памет само за текущия запис. Подходящо е, ако ще правиш някакви сметки с данните или просто искаш да извлечеш резултат (и например да го напълниш после в някакъв друг in-memory dataset, с който да работиш). Вторият вариант е да си смениш memory manager-а. Препоръчвам ти . Новите версии на Делфи (от 2006 май) използват него. Това може да подобри донякъде ситуацията с фрагментирането на паметта. А и като цяло е по-добър и можеш да забележиш дори и значително подобрение в производителността на приложението ти само с подмяната на memory manager-а.
Малко объркано стана. Нещо не съм в час напоследък. Имам нужда от една хубава коледна ваканция, но се надявам да съм ти бил полезен със словоизлиянията си
Linux isn't free, it's worthless.
| |
Тема
|
Re: Странно управление на паметта
[re: andrew_nikoloff]
|
|
Автор | nmm (Нерегистриран) |
Публикувано | 21.12.09 18:06 |
|
Човече,ти ми спаси живота
Сложих FastMM и резултата е налице !!!
Вече получавам Out Of Memory само когато отварят големи дейтасети (с по над 20к записа- зависи от наличното количеството RAM). Това нещо ми беше голям дерт. Имам да черпя
ПС: остана ми засега само един личен въпрос към тебе и той е свързан с подписа ти
| |
|
В един от предишните постове спорихме кой SQL сървър е за предпочитане, и ти разбира се предложи Firebird
Едно време работих с Delphi/Interbase/Firebird и се налагаше да правя уеб кроулер/спайдър. Това налагаше непрекъснати update/insert операции с блоб полета, от приложения в един сървър. Оттогава и не харесвам този сървър (въпреки че в момента пак работя с него по задължение )
Та идеята ми беше не да се заяждам, а да повторя мисълта си че в един сървърен компонент най-важното свойство е стабилност. Стабилност в един софтуер се постига след дълга употреба/поддръжка/подобрения. Това предполага голям брой потребители които ползват интензивно продукта, намират дефекти в него и съответната голяма компания която има съответен ресурс.
Стабилността е особенно важна когато човек гради нещо с този или онзи сървър - така може да разчита че в продукта единствения източник на глупости е самия автор.
И накрая, като се замислих - мани всички сървъри, компоненти и прочее и кажи кога ще се съберем с Краси да се напием и да пеем песни за доброто старо Борландско време?
чети и дишай по-леко
| |
|
Чакай сега! Недей да ми хулиш любимия DB сървър, когато гореспоменатия проблем всъщност е в IBX-а
Математиците имат един готин лаф:
-Кой е най-често споменаваният мъж сред математиците?
-Коши. Има теореми почти за всичко. Много често го споменават.
-А коя е най-често споменаваната жена сред математиците?
-Майка му на Коши. Много често я споменават.
Та ако мога да го попроменя малко - същото може да се каже и за програмистите на Delphi + IB/FB и Jeff Overcash.
Иначе ползвай FIBPlus и се радвай на живота...
А за пиенето... Много сложни въпроси задаваш
В момента съм на тема "домашен майстор", че сме в процес на местене в нова къща и идея дори си нямам кога ще имам път да намина към вашия вилает....
Linux isn't free, it's worthless.
| |
|
|
|
|