Привет всем !
Никто не сталкивался с фрагментацией памяти ? Я по-моему наблюдаю впервые в жизни.
Создается в куче и удаляется большое кол-во достаточно мелких объектов. Проверил,
все объекты удаляются.... Тем не менее память кушает, мама-не-горюй..
Куда капнуть ? Как проверить ? Или это может быть точный диагноз — фрагментация ?
Здравствуйте, _kostet_, Вы писали:
__>Привет всем ! __>Никто не сталкивался с фрагментацией памяти ? Я по-моему наблюдаю впервые в жизни. __>Создается в куче и удаляется большое кол-во достаточно мелких объектов. Проверил, __>все объекты удаляются.... Тем не менее память кушает, мама-не-горюй..
__>Куда капнуть ? Как проверить ? Или это может быть точный диагноз — фрагментация ?
Если объекты маленькие, и их много, в любом случае стоит попробовать Small Object Allocator из Loki.
Ну а там видно будет...
Здравствуйте, Alex_Avr, Вы писали:
B>>Если объекты маленькие, и их много, в любом случае стоит попробовать Small Object Allocator из Loki. B>>Ну а там видно будет...
A_A>Можно также посмотреть boost::pool
а для начала позапускаться под valgrindом с включенным leak check'ером
описанное тобой сжирание памяти всетки более похоже на течь чем на фрагментацию... при фрагментации такое конечно тоже может быть но я в своей жизни видел подобное только на _специально_ сфабрикованном примере -- в обычных прогах такое мегаредкость (должно быть)...
Здравствуйте, _kostet_, Вы писали:
__>Привет всем ! __>Никто не сталкивался с фрагментацией памяти ? Я по-моему наблюдаю впервые в жизни. __>Создается в куче и удаляется большое кол-во достаточно мелких объектов. Проверил, __>все объекты удаляются.... Тем не менее память кушает, мама-не-горюй..
__>Куда капнуть ? Как проверить ? Или это может быть точный диагноз — фрагментация ?
а где вы смотрите, сколько памяти она кушает???
возможен такой вариант:
при выделении памяти в программе, виндовс сопоставляет выделенной памяти физические страницы (он может делать это при выделении или при первом обращении) из-за чего растет количество памяти занимаемое программой. при освобождении памяти, программа лиш подправляет таблицы занятых и свободных блоков, но при этом не освобождает физические страницы (этого не делает и виндовс, так как считает что эти страницы пригодятся в программе в будущем). Поэтому освобождение страниц нужно делать вручную.
Hello _kostet_,
_> Привет всем ! _> Никто не сталкивался с фрагментацией памяти ? Я по-моему наблюдаю _> впервые в жизни. _> Создается в куче и удаляется большое кол-во достаточно мелких _> объектов. Проверил, _> все объекты удаляются.... Тем не менее память кушает, _> мама-не-горюй.. _> Куда капнуть ? Как проверить ? Или это может быть точный диагноз - _> фрагментация ?
было дело как-то... я тогда пускал потоки, но не делал им join.
и тоже в топ'е сидел и удивленно так смотрел куда мир катится... помню
даже написал счетчик выделенной и освобожденной памяти, все точно
совпадало, потом сделал пулы — одно выделение и одно освобождение,
в общем повеселился неподецки
Здравствуйте, _kostet_, Вы писали:
__>Куда капнуть ? Как проверить ? Или это может быть точный диагноз — фрагментация ?
Как уже сказали — valgrind. Конкретно, memcheck оттуда.
Ругани верить, отсутствию ругани, как обычно, нет. 8))
PS: Во всех более-менее современных unix-like OS, с которыми я сталкивался, фрагментация памяти — это что-то из серии ненаучной фантастики. Аллокаторы нынче достаточно умные.
_kostet_ wrote: > > Pushkoff wrote: >> > [] > > сорри, что забыл уточнить — linux suse 9.2 > смотрю в топе, его информативности мне достаточно.
free() на линукс никогда не возвращает ядру память.
malloc.h
/* mallopt options that actually do something */#define M_TRIM_THRESHOLD -1
malloc.c
/*
M_TRIM_THRESHOLD is the maximum amount of unused top-most memory
to keep before releasing via malloc_trim in free().
Automatic trimming is mainly useful in long-lived programs.
Because trimming via sbrk can be slow on some systems, and can
sometimes be wasteful (in cases where programs immediately
afterward allocate more large chunks) the value should be high
enough so that your overall system performance would improve by
releasing this much memory.
The trim threshold and the mmap control parameters (see below)
can be traded off with one another. Trimming and mmapping are
two different ways of releasing unused memory back to the
system. Between these two, it is often possible to keep
system-level demands of a long-lived program down to a bare
minimum. For example, in one test suite of sessions measuring
the XF86 X server on Linux, using a trim threshold of 128K and a
mmap threshold of 192K led to near-minimal long term resource
consumption.
If you are using this malloc in a long-lived program, it should
pay to experiment with these values. As a rough guide, you
might set to a value close to the average size of a process
(program) running on your system. Releasing this much memory
would allow such a process to run in memory. Generally, it's
worth it to tune for trimming rather tham memory mapping when a
program undergoes phases where several large chunks are
allocated and released in ways that can reuse each other's
storage, perhaps mixed with phases where there are no such
chunks at all. And in well-behaved long-lived programs,
controlling release of large blocks via trimming versus mapping
is usually faster.
However, in most programs, these parameters serve mainly as
protection against the system-level effects of carrying around
massive amounts of unneeded memory. Since frequent calls to
sbrk, mmap, and munmap otherwise degrade performance, the default
parameters are set to relatively high values that serve only as
safeguards.
The trim value It must be greater than page size to have any useful
effect. To disable trimming completely, you can set to
(unsigned long)(-1)
Trim settings interact with fastbin (MXFAST) settings: Unless
TRIM_FASTBINS is defined, automatic trimming never takes place upon
freeing a chunk with size less than or equal to MXFAST. Trimming is
instead delayed until subsequent freeing of larger chunks. However,
you can still force an attempted trim by calling malloc_trim.
Also, trimming is not generally possible in cases where
the main arena is obtained via mmap.
Note that the trick some people use of mallocing a huge space and
then freeing it at program startup, in an attempt to reserve system
memory, doesn't have the intended effect under automatic trimming,
since that memory will immediately be returned to the system.
*/
/*
malloc_trim(size_t pad);
If possible, gives memory back to the system (via negative
arguments to sbrk) if there is unused memory at the `high' end of
the malloc pool. You can call this after freeing large blocks of
memory to potentially reduce the system-level memory requirements
of a program. However, it cannot guarantee to reduce memory. Under
some allocation patterns, some large free blocks of memory will be
locked between two used chunks, so they cannot be given back to
the system.
The `pad' argument to malloc_trim represents the amount of free
trailing space to leave untrimmed. If this argument is zero,
only the minimum amount of memory to maintain internal data
structures will be left (one page or less). Non-zero arguments
can be supplied to maintain enough trailing space to service
future expected allocations without having to re-obtain memory
from the system.
Malloc_trim returns 1 if it actually released any memory, else 0.
On systems that do not support "negative sbrks", it will always
rreturn 0.
*/
Однажды тоже так же обжегся с потоками, была у меня в идеале такая же история.
Но сейчас все в одном потоке крутится. Тем не менее, утечка налицо. Спасибо
Тем не менее память кушает, мама-не-горюй.. 
