I've tried to use memprof to see what is allocated from where, but it see=
ms=20
like memprof fails to see some memory frees and overestimates memoru usag=
e=20
greatly. I dont know why it happens. In particular, it doesn't see delete=
=20
operator in hash tables.
> Worst structures look like:
> - MGnuHash. 24-byte allocations, and lots and lots of =8Cem. 8,9K c=
alls
> to malloc from __builtin_new in MGnuHash::Insert, actually, from the
> HandlePacket chain alone. 28k in total, compared to 33k allocations wi=
thin
> the heartbeat =AD so consider that class critical path for optimization=
=2E
>
There are 4 hash tables, 10000 elements each, so in total there should be=
~40K=20
allocations. Quite a lot, but not that much.
> - MGnuNode ForceDisconnect calls are at 524.6k =AD they do flush, bu=
t not
> as regularly as one might think. And I=B9m not sure what does it =AD a=
nywayhs,
> the calling conventions that wipe these out aren=B9t working when we th=
ink
> they should be, I=B9m sure of that. It=B9s possible that ForceDisconne=
ct will
> then end up waiting for ManageConnects in MGnuDirector to kill it off o=
n a
> timeout... This is where our single-threaded metaphor starts to look
> pretty ugly, to be honest, without us actually switching to an event mo=
del
> =AD which we pretty much should do.
>
Good point. I'll try to check what's happening there as well.
> - 59K worth of map in MGnuSearch, for a small number, in addition to=
the
> 180K which end up in a list, and it=B9s all wee little allocations tha=
t make
> me think trouble. We=B9re so fragging memory. Sure, it won=B9t matte=
r once
> the kernel coalesces, but we=B9re making that happen more often than we
> should if these numbers are right.
>
I dont think we can reduce dramatically amount of memory used by searches=
=2E=20
They do store the information we actually need.
> That=B9s gone up, hasn=B9t it. Want to bet it=B9s fragmentation?
>
Me either. Is there way to check it it's true?
Regards,
Max
|