I've tried to use memprof to see what is allocated from where, but it see=
like memprof fails to see some memory frees and overestimates memoru usag=
greatly. I dont know why it happens. In particular, it doesn't see delete=
operator in hash tables.
> Worst structures look like:
> - MGnuHash. 24-byte allocations, and lots and lots of =8Cem. 8,9K c=
> to malloc from __builtin_new in MGnuHash::Insert, actually, from the
> HandlePacket chain alone. 28k in total, compared to 33k allocations wi=
> the heartbeat =AD so consider that class critical path for optimization=
There are 4 hash tables, 10000 elements each, so in total there should be=
allocations. Quite a lot, but not that much.
> - MGnuNode ForceDisconnect calls are at 524.6k =AD they do flush, bu=
> as regularly as one might think. And I=B9m not sure what does it =AD a=
> the calling conventions that wipe these out aren=B9t working when we th=
> they should be, I=B9m sure of that. It=B9s possible that ForceDisconne=
> then end up waiting for ManageConnects in MGnuDirector to kill it off o=
> timeout... This is where our single-threaded metaphor starts to look
> pretty ugly, to be honest, without us actually switching to an event mo=
> =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=
> 180K which end up in a list, and it=B9s all wee little allocations tha=
> me think trouble. We=B9re so fragging memory. Sure, it won=B9t matte=
> 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=
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?