Memory leaks on the server side are also a consequence of long-running single-process server software. What was traditionally run as a CGI (eg. Apache creating a fresh process for each request) or was started from inetd is now frequently implemented in a multi-threaded or evented fashion, so that using the O/S as garbage collector for memory and temp files doesn't work anymore. Not only does this put additional strain on getting memory management 100% right, it also creates memory fragmentation when done naively. While the consensus and narrative seems to be that evented I/O is more performant because the O/S doesn't have to schedule loads that have "nothing to do anyway most of the time" so to speak, I've yet to see a benchmark comparing traditional process-per-request vs. multithreaded and/or evented approaches; it's not that user-space memory management doesn't introduce additional overhead.

My suspicion is that in many cases memory management strategies of desktop software have been used for server-side software without evaluation, or out of a habit because Java introduced GC into server software. But OTOH even OpenBSDs "new" (3-5 years old) httpd integrates traditional CGIs via the so-called "slowcgi" bridge, and uses evented I/O and asynchronous APIs natively so maybe I'm wrong on this one. If even OpenBSD developers themselves don't use ASLR and other techniques of OpenBSD to ensure non-deterministic memory allocation and go to great length to get equivalent protection within single-process request processing containers, they sure must be on to something.