In maintenance, sometimes the dumb solution is the best. The servers that ran amazon.com had a memory leak and were subsequently restarted. This hack continues for years because it was the most cost-effective thing to do.

Put another way, if they didn’t turn it off and on again, I would think less of them because that’s the first thing you should always do unless you know better

▲

jimmaswell a day ago | parent | next [-]

I suppose you might want to first rule out a break-in, and if there is one, recover evidence that won't survive a reboot.

▲

jamesfinlayson 20 hours ago | parent | prev [-]

Yeah, a place I worked at years ago had a cron job to restart some critical service at midnight because it leaked memory all day. That was there for years.

▲

ninalanyon 13 hours ago | parent | next [-]

We had a mail server that ran on an old DEC minicomputer. I rebooted it every six months because it had a slow memory, or possibly resource, leak somewhere.

It was the only thing running on that box so it wasn't a big deal to reboot.

▲

Rantenki 19 hours ago | parent | prev [-]

Another real world example: to this day, it's a good idea to limit requests per PHP process using the MaxRequestsPerChild(apache)/max_requests(php-fpm) config option to some sane limit. After that configured number of requests, the PHP worker is terminated and restarted to... "fix" memory leaks. I remember setting that in the late 90s on Apache...

I am happy to no longer use PHP for anything.

	▲	jamesfinlayson 19 hours ago \| parent [-]
		Oh, it's been a while but I remember that. I've used PHP in two previous jobs and certainly the stuff that I was in control of had it set to 0 because we made sure we didn't leak memory. Other departments... I'm sure at least one had the limit set to something non-zero.