Re: help with huge memory consumption??

On 6 Mar 2007 01:53:02 -0800 David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Mar 4, 12:09 pm, phil-news-nos...@xxxxxxxx wrote:
|
|> One problem with threads is they are more likely to fragment the memory.
|> One reason is the concurrency where multiple threads are entangling in
|> time and interleaving their allocations (if in the same arena). If some
|> threads go away but others stay, then you have a jumbled collection of
|> allocated and free spaces in the heap. Compare that to a simple process
|> that extinguishes the whole virtual memory when it is done. And programs
|> designed with threads tend to be those that are long lived (a major desk
|> application) as opposed to really short ones (simple web CGI).
|
| I don't buy this for three reasons:
|
| 1) The fragmentation is largely a result of the workload, now how you
| handle it. For example, consider an instant messaging server. You
| allocate memory for things like clients, messages, file transfers, and
| the like when they happen in the outside world. You free them when
| they're finished. This will fragment the same whether it's handled by
| one thread or one hundred.

It does depend on the type of work. An IM server is typically doing
the same thing over and over, with mostly similar structures, and not
too much on a per-thread basis (lots on a shared-between-threads basis).

A web browser, however, can see a significant effect. Browsers that
force the same process to handle new browser starts (e.g. Firefox does
this) mean you really are viewing all your web sites in the same VM.
I find this fragments horribly, and is at least one factor in bloat.
Amazingly, after defeating the effort by Firefox to try to run everything
in one process, and actually getting truly distinct processes to run in
each new instance I create (per web site I visit), the result I see is
that the total of all processes is only slightly more than the one big
process the other way. But this has the advantage that I can exit the
browser after finishing one site and completely extinguish its VM and
lighten the load. With everything in one big browser that is not possible
and with many pages having some allocations not freed when a given window
to a given site being closed, VM is now full of sub-page-size holes. Of
course a lot of those holes can be re-used for the next site. But what
I end up with is a long running browser bloated to the peak of what I was
doing.

It would be possible, but hard, to program around this problem.


| 2) You claim the increased concurrency causes this fragmentation. If
| so, this is not a cost of threads but a cost of increased concurrency.
| Nothing about choosing to use threads requires you to increase
| concurrency, and you would only do so if the benefits outweighed the
| costs. There are many benefits to using threads other than making it
| easier to increase concurrency should it be beneficial to do so, for
| example, your whole server won't stall should your program experience
| some unexpected blocking on file access or a page fault. (In
| comparison to a poll-loop server. See point three if you're comparing
| it to lots of little processes.)

Processes clean up better than threads. This is because memory resource
released by a process is available for re-use by other processes whereas
memory resource released by a task or work unit within a process may not
completely clear every page size unit, leaving pages still mapped to the
big process. Greater concurrency results in greater intermingling of
memory allocations.


| 3) It is very rare that one has a choice to write a long-lived
| application or a short-lived one. For applications that are naturally
| short-lived, it doesn't matter. For applications that are naturally
| long-lived, you don't have a choice. I agree that if you can solve a
| problem with short-lived (or intermediate-lived) processes, that is
| often preferable to long-lived ones.

The real issue I see is people choosing to use threads as the programming
methodology du jour, without fully understanding the implications of how
the resources are managed ... in addition to the widening of risks due to
a memory corruption. For example, Firefox still has bugs (surprise!) that
can crash the whole thing. Without my hack to let me truly run each new
instance in a truly separate process, one bug hit would take out _all_ of
my web windows (and sometimes I have a lot of them). FYI, I currently
have 11 Firefox process instances running. This also helps logging in to
multiple different accounts on the same web site (e.g. 5 different users
on my domain hosted by Gmail).

Programmers should choose to use threads _only_ when they fully understand
_why_ their application benefits from threads at a level greater than the
risks that threads pose to their application, whatever size it might be.
They should also consider process separation where possible (and I believe
it is more possible than commonly done today). Making processes talk to
each other, of course, does involve more work, and using less efficient
methods that can have an impact when there is a higher volume of data to
go between tasks and work units (e.g. an IM or IRC server). What I have
found is that the majority of programmers who are asking questions in one
or more forums about programming issues related to their use of threads
simply have not considered the design choices in the first place that
would have helped them make a wiser choice, probably because they just do
not know those issues. Beginning programmers probably should avoid the
things that are best done with threads. Unfortunately, programmers too
often do like to do the things that really do call for threads, such as
"yet another IM server". I hope they learn to swim in the deep end fast.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-03-06-0825@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Relevant Pages

  • Re: Determine calling function
    ... to encourage programmers to escape from following dogma mindlessly. ... ad absurdem of an insistence on checking malloc(), ... I don't know how much memory starting at ... Obviously a *hard* setrlimit() cannot be employed for throttling ...
    (comp.lang.c)
  • Re: Confused about gcnew and object lifetime
    ... It's a different story when those programmers later go to an unmanaged environment, ... Being sloppy there means scarce system resources may remain locked indefinitely. ... In fact, in ..NET you can't deallocate memory, only the system can, but you still MUST deallocate resources. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: OT: C++ overloading operators
    ... use of memory, at the cost of a somewhat slower execution. ... dynamic allocation, no matter how many "clever tricks" are used... ... I don't think you will find many programmers outside the ... "big" number and very generous overhead allocation. ...
    (comp.dsp)
  • Re: How does this make you feel?
    ... > [listing system programmers, app programmers, end users] ... bug and feature since they are sometimes synonymous. ... > Bugs that are visible all the way up to the end user: ... > 1% because the big limiter is memory latency. ...
    (comp.arch)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... of dirty memory so that when we desperately need memory on the ... any incoming packets. ... So suppose we forgot about all the allocation tracking (that doesn't ... A packet is received, it can be a fragment, it will be placed in the ...
    (Linux-Kernel)