MongoDB v5.0 requires CPU AVX instructions

[JedMeister]

I was just testing our MongoDB v17.0 release and Mongo wouldn't start. In fact i can't even read it's help or check it's version...:

root@mongodb ~# mongod --help
Illegal instruction
root@mongodb ~# mongod --version
Illegal instruction

After a bit of searching, I discovered a bug that sums up the situation. A comment from one of the devs notes that v5.0+ has specific CPU requirements.

Apparently, it could be recompiled to allow v5.0 to run on older x86_64 CPUs, although I'm not keen on doing that.

Another option is to stick with v4.4 for now?

I guess another option would be to provide 2 appliances, but 2 things; firstly I don't ahve a compatible CPU and I don't think that mongodb is popular enough for that. My inclination is to stick with v4 for now. We could perhaps have a script to upgrade?

FWIW on Linux to check if your CPU can run v5:

grep flags -m1 /proc/cpuinfo | grep avx

(FWIW, that will only check the first CPU core, but AFAIK, that's enough).

[qq7]

Apparently, I have AVX available with my CPU, so I couldn't notice this while testing.

I don't think that 5.0 is conceptually different from 4.4, although there were code compatibility changes. So, I think that sticking with 4.4 could actually be better for now, especially for those who would upgrade from 16.0.

Maybe there's a non-AVX-compatible official build released later on?

[JedMeister]

Apparently, I have AVX available with my CPU, so I couldn't notice this while testing.

Totally understandable mate.

Actually, I've just had a closer look and realised that AVX has been around for quite a while and is pretty common (I was under the impression that it was newish). It turns out that my 10 year old laptop supports AVX. Just not my (much newer, but low power Atom based) server...

I think that sticking with 4.4 could actually be better for now, especially for those who would upgrade from 16.0.

Yep, I think that might be best for v17.0.

Maybe there's a non-AVX-compatible official build released later on?

Maybe. But even if there isn't, we will move to it at some point (maybe v18?). And I'll either need to just test it on my laptop, or get a new server! 😄

[blastbeng]

I don't understand why mongo moved on a "model" that requires AVX, this breaks so many installations of mongo

In my noobish and honest opinion, mongo must have a "cheap, slow and potato" version built without AVX that allows it to be runned under a potato cpu, like the one on my udoo x86 ultra (a 6/7 years old server).

udoo x86 ultra is still powerfull enough to be used as an home server.

[JedMeister]

We might look at packaging it ourselves (without the AVX requirement). I'm sure it runs a bit better/faster/more efficiently when it uses AVX, but at least then it'd run "everywhere".

[OnGle]

It depends though whether AVX is required because it's being passed via -mavx + optimizations or because specific assembly/intrinsics are used that require those exact instructions. The former is easy to handle, the later is not.

[JedMeister]

It's been a while since I researched this, but IIRC the rationale for requiring AVX is that it's more performant and whilst they're open source, they're very much a business (so targets business customers). I'm not sure if you recall, but the reason why we need to use the upstream package is because Debian dropped support for it once upstream changed the licence (Debian consider the current MongoDB licence "non-free"). We moved to the upstream package because by our (looser) position on licensing means it's still open source enough for us (their updated licence discourages 3rd parties from providing MongoDB as SaaS).

I haven't delved any deeper into this recently, but I do hope to look a bit closer sometime soon. I am thinking that building it ourselves (without AVX) could be a workable solution. Although for that to work and remain reliable, we'll need to automate the package building - otherwise it will create undue overhead and risk users being stranded on an insecure version in the future (until I update the package). So that would need to be in place prior to releasing a MongoDB app with a version built by us.

[OnGle]

To expand on the context of my previous comment, if it's only required, because it's compiled with -mavx + optimizations we only need to remove -mavx and then it'll "just work" which we could probably automate easy enough.

If it's been done with intrinsics or assembly then it'd just need to be re-written, either to avoid vectorization entirely or to port AVX vectorization to SSE family extensionss which may not even be possible depending on which functionality it uses explicitly but even if it is, it's entirely unrealistic for us to maintain.

[OnGle]

Bigger issue than AVX is it requiring a newer C compiler & linker than we have available currently. Defering to next major release (we'll provide older mongodb until then)

[GermanAizek]

@JedMeister easiest solution is manually fix SConstruct, change ['+sandybrige'] to [] or take my patch ready here and build.
https://github.com/GermanAizek/mongodb-without-avx

@blastbeng I agree with you. The strangest decision mongo maintainers is that there are no AVX instructions on modern Tremont microarchitecture, but it has servers and is used in cellular base stations.
https://en.wikipedia.org/wiki/Tremont_(microarchitecture)