"High water" Memory fragmentation still a thing?

[Chris Angelico]

On Tue, Oct 7, 2014 at 3:21 AM,
<bryanjugglercryptographer at yahoo.com.dmarc.invalid> wrote:
> Chris Angelico wrote:
>> This is why a lot of long-duration processes are built to be restarted
>> periodically. It's not strictly necessary, but it can be the most
>> effective way of solving a problem. I tend to ignore that, though, and
>> let my processes just keep on running... for 88 wk 4d 23:56:27 so far,
>> on one of those processes. It's consuming less than half a gig of
>> virtual memory, quarter gig resident, and it's been doing a fair bit [...]
>
> A shipping product has to meet a higher standard. Planned process mortality is a reasonably simple strategy for building robust services from tools that have flaws in resource management. It assumes only that the operating system reliably reclaims resources from dead processes.
>

Sure, and that's all well and good. But what I just cited there *is* a
shipping product. That's a live server that runs a game that I'm admin
of. So it's possible to do without the resource safety net of periodic
restarts.

> For an example see the Apache HTTP daemon, particularly the classic pre-forking server. There's a configuration parameter, "MaxRequestsPerChild", that sets how many requests a process should answer before terminating.
>

That assumes that requests can be handled equally by any server
process - and more so, that there are such things as discrete
requests. That's true of HTTP, but not of everything. And even with
HTTP, if you do "long polls" [1] then clients might remain connected
for arbitrary lengths of time; either you have to cut them off when
you terminate the server process (hopefully that isn't too often, or
you lose the benefit of long polling), or you retain processes for
much longer.

Restarting isn't necessary. It's like rebooting a computer: people get
into the habit of doing it, because it "fixes problems", but all that
means is that it allows you to get sloppy with resource management.
Working under the constraint that your one process will remain running
for at least a year forces you to be careful, and IMO results in
better code overall.

ChrisA

[1] https://en.wikipedia.org/wiki/Push_technology#Long_polling