Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Perl Memory problem ...

by sundialsvc4 (Abbot)
on May 12, 2020 at 23:52 UTC ( #11116733=note: print w/replies, xml ) Need Help??

in reply to Perl Memory problem ...

Here is something to also think about:   "exactly what? is the system monitor reporting to you ... and, why do you care ... and, from "a 'system' point of view," should you care?

Allow me to explain.

For the most part, the runtime memory-management behavior of any programming language system, old or new, has absolutely zero impact upon the operating system ... except for the simple fact that The Implementors™ of every such system have been very-keenly aware of it and have in fact very much designed the runtime behavior of their memory-managers completely around it.

Again, allow me to explain.

"Virtual memory," this being the linchpin of every operating system designed since the late 1960's, is predicated upon an idea that did earn a PhD: "locality of reference." The idea that the memory-reference patterns exhibited by any running computer program are decidedly not random, and that these differences could be very-usefully exploited. No longer did operating systems have to concern themselves with "the individual running program's" (Perl, or otherwise ...) "view of 'reality,'" because the operating system could create its own 'reality' for each of them.

Today, every running program perceives (incorrectly) that it is running in its own memory-world, when in fact the underlying operating system is simply observing which so-called "pages" of memory the process has referenced "recently." The operating system does not care in the slightest how the process's chosen programming-language "manages its own little world:   it only cares about the actual physical memory-access pattern that the process is – in this particular millisecond – exhibiting.

Programming-language designers are of course very aware of this perspective, so they consciously design their systems so that the addresses returned by "the next" memory-allocation request are numerically close[st] to ones that have occurred recently, and/or to blocks that have recently been released.

But, I digress.   The key point is that there are two entirely-different worlds:   the (virtual) one that is seen by the programming-language environment of any running program, and the (purely physical) one that actually matters to the (agnostic ...) operating system.

And so to this long-winded final important point: "laziness." At this moment, is there pressure on the memory-management subsystem, or not? In these ridiculously-memory-generous days and times, the answer is very often "no," in which case the operating system does not bother ...

... which is all-too-often why systems that "run just fine" on the developer's machines run into tremendous problems "in production!"

... but which can also lead to "false alarms," also in production. When you are trying to diagnose production process slowdowns, the first thing that you need to look at is the physical reasons why any process is "waiting," and the distribution of sources.

Replies are listed 'Best First'.
Re^2: Perl Memory problem ...
by Anonymous Monk on May 13, 2020 at 11:32 UTC
    After a toddler tantrum you told us you'd never come back, here you are, same nonsense. Answer the question or shut up.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11116733]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (11)
As of 2020-09-29 14:59 GMT
Find Nodes?
    Voting Booth?
    If at first I don’t succeed, I …

    Results (146 votes). Check out past polls.