Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The TLDR:

The biggest difference was memory usage: "FreeBSD is just too good at managing memory. My server earlier used to consume over 1 GB of memory for running PHP, MySQL and Nginx. Now, it doesn’t even touch 500 MB! It’s always less than 500 MB. Everything is just same, configuration, etc. Only OS changed"

Later in the article, a recount of desktop memory shortage issues under Linux and much improvement under FreeBSD. He even reports single applications like Chromium performing better and with no swapping.



One has to be careful when looking at memory usage to judge these kinds of things, though. Linux has a tendency to use memory unused by applications for its own purposes, because it's not being used anyway and it might as well do something useful with it.

Oftentimes this ends up being something like aggressively caching file data so that it doesn't have to write to disk very often. While this does get labeled as "used" memory, it can very quickly be freed up by the operating system by evicting this cached data back to disk if that memory is needed elsewhere.

This can make Linux appear more memory-hungry, but in actuality a better description might be that Linux is more effectively using the resources at its disposal. I'm not saying that this is what's happening in this case, but it's a possibility.


Agreed. Compare that with http://www.linuxatemyram.com/


The main thing that matters is when I execute a command it runs fast. and OS is fast... As far as I am concerned os could be sending all my free memory to /dev/null. As long as performance and stability stay up; it can do whatever it wants...


You think Linux is alone in acting like that?


No, but maybe others don't report such memory as used, which seems unfortunate to me.


FreeBSD has many labels for how it uses memory. Active, Inactive, Cache etc, to specify the purpose. See this question and answer: http://unix.stackexchange.com/questions/134862/what-do-the-d...


They're less labels for purpose and more labels for lifecycle - data you'd consider "cached" can appear just about anywhere. From what I remember (corrections more than welcome):

Active is fully-fledged in use memory, mapped into one or more processes

Inactive is where Active goes when it's less in-use. Cheap to reactivate, but relatively costly to free: can still be mapped into processes, and may be dirty (modified) and thus require writing to disk before being unmapped and cleared for reuse.

Cached is where lesser used Inactive cached data goes before it dies. More costly to reactivate, but cheap to free: No longer mapped directly into any process, and strictly consists of only clean (unmodified) pages that don't need writing back to disk before clearing.

Wired is pinned-down memory that can't be swapped out. ZFS's data and metadata caches are counted here, since it maintains its own (known as the ARC - Adaptive Replacement Cache, after the algorithm it's based on) instead of just relying on the traditional VM page cache.


At least Windows Servers do. Administrators are often confused about why all memory is being used, when it's used by disk cache. (memory mapped files)


You can use 'free -m' to view the actual amount of memory being used.


Or:

    free -h
h for human, so it converts to KiB, MiB or GiB depending on which one is the most suitable.


The TL;DR is really: No idea what I'm doing here, so I might as well blog about it.

An application doesn't magically allocate less memory when running under a different kernel. The underlying idea must be that LLVM wins over gcc in a real world scenario, which certainly would be interesting, but there is really nothing to suggest it here.


It's definitely not a deep technical analysis as it's not written by a kernel engineer, but it's also plausible. VM management and swapping can and do have implementation quality differences on this scale.

The kernel VM is all about heuristics. In a memory pressure situation, it's constantly discarding cached pages that it thinks are better used for other data, making decisions about whether to swap out some data to make room for more cache, etc.

If you remember/look at the history of Linux VM and swap behaviour tuning and algorithms, there have been large improvements and regressions in this area historically.


Absolutely, but the claim here is entirely different, "my application used less memory when running on FreeBSD". While within the realm of the possible, it is more likely it is running on a completely different configuration, or "memory used" changed meaning, or both.


The explicit swapping part was there in the desktop section.

But even the server part, due to vague phrasing, could mean that his VMs are doing OK with 500MB under FreeBSD and needed more with Linux.

But yeah, it might be due to different configurations or misinterpretation of memory stats too.


> An application doesn't magically allocate less memory when running under a different kernel.

Different default allocator can make a difference, though - FreeBSD defaults to jemalloc iirc.


I'm sure FreeBSD is probably better at memory management than Linux (considering his Desktop issues) but wouldn't it make sense for the OS to nearly max out memory usage as long as applications can make use of it?


> wouldn't it make sense for the OS to nearly max out memory usage as long as applications can make use of it?

Yes, Linux uses spare memory extensively as caches which can be dumped immediately as applications need the memory for usage.

Unfortunaltely, he didn't mention how he measured memory usage on both OSes.


Oh come on! This is the second comment in this thread that seem to claim Linux is so special and glorious. FreeBSD definitely does this, maybe even 3BSD or 4BSD did this.

Functionality like this is basic OS design knowledge.


Oh come on! This is the second comment in this thread that seem to claim Linux is so special and glorious. FreeBSD definitely does this, maybe even 3BSD or 4BSD did this.

The modern VM architecture was definitely introduced after 3BSD or 4BSD, since NetBSD only introduced a unified buffer cache in 2000 and is also derived from 4.4BSD.

[1] https://www.usenix.org/legacy/publications/library/proceedin...


Yes, exactly right - so it makes his conclusions sound fishy.

I don't think anyone's trying to say that Linux is so special and glorious (beyond BSD).


I did exclude the cache part when measuring the memory usage. And they were measured using standard tools like top, ps, etc.

Most likely I'd have used the system monitor that comes with KDE.


While I respect other people's option for FreeBSD (I tried it several times), in my ~3 years experience using Ubuntu Unity (from 11.04-14.10) I never had low memory or unreasonable swapping (swap is zero 99% of the time I check). My laptop has 3GB of RAM and I was always impressed with how little memory my usual session (1-5 apps + Firefox/Chrome with 5-10 open tabs max) consumed compared to windows: the average memory load was around 33% of the 2.7GB available = ~1GB. For some time I was using virtualbox with 1.5GB RAM allocated to it and I still didn't use all the RAM available and the swapping was minimal if not 0. My conclusion: I'm highly sceptical that Linux memory management is bad enough to justify giving up the ease of installation and the minimal configuration & tweaking Ubuntu needs after install.


To give a counterpoint, I frequently get into trouble with Linux 3.12.6. If I open more than a few tabs (70 say, with FF I can do an order of magnitude more) in Chrome it maxes out on memory to the point of the system becoming useless. Funnily enough it actually maxes out on swap space even though there is RAM available and then starts thrashing like crazy. Setting swappiness alleviates this somewhat but not entirely. Its a box with 1 GB ram + 1 GB swap. Not big by current standards, but has more than plenty RAM in my opinion if it werent for the tendency to write bloatware these days.

Yeah I could get some more RAM, but this box is a good testbed for software with a leaner streak, bloat does not excite me as much, sorry. Funnily enough this seems to offend a whole lot of people, as if I owe it to them to have more RAM on my m/c. It is probably worth it just for that amusement.

Definitely interested in giving *BSD a shot. The thing that has stopped me so far is the difficulty in sharing data between them.

EDIT @DanBC

> 70 tabs is not normal and 700 is just, well, weird.

So I have been told :)

Firefox manages it well enough though, I would assume Dillo would too. Dont want to hijack the thread with why I abuse tabs so, but I still contend that 1 GB is enough if the code is tight. 1 GB is a huge freaking load of memory if you think about it.


70 tabs is not normal and 700 is just, well, weird. It's great to run a machine with "low" amounts of RAM but you shouldn't then complain if it does weird things.

I'd be interested in what happens if you run 700 Dillo instances?


70 tabs is normal. I actually have exactly 71 right now, and that's because I opened a new tab to view this discussion.


Sidebar, but everyone mistakenly thinks things that they do are therefore normal. I think the difference between "normal" and "common" is a little vague. If you define "normal" the same as "common" then we could do a study and see if it is normal or not (my guess is that it is not). However "normal" can also be defined as "not unreasonable", in which case I would agree, 71 tabs is normal.


70 tabs is only normal in the group of people reading HN. Other normal things for that group of people would be having a compiler installed on their OS. Would you describe having an installed compiler as normal for the general computer-using population?

I'm willing to bet that the vast majority of computer users don't ever have more than 5 tabs open at any time.


I'm willing to bet that some non-trivial percentage of computer users are unaware that tabs exist, and do not use them period.


"Would you describe having an installed compiler as normal for the general computer-using population?"

Totally off-topic, but Yes :-)

.Net has a compiler built-in (you may need the SDK to get the command-line version), many systems have a compiler for a shader language, and your packet filter may ship with one.


70 tabs is perfectly normal.


Probably the userland allocator, doesn't FreeBSD use jemalloc by default?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: