ArangoDB container will not start due to CPU instruction set not supporting AVX

[fl0wc0ntr0l]

I'm trying to install YETI on my old-as-dirt Proxmox server that runs Intel Xeon X5680 CPUs and I've figured out that the reason I'm getting these errors is because ArangoDB v3.11.x requires the AVX instruction set - something this CPU doesn't have.

yeti-arangodb  | using NUMA numactl --interleave=all
yeti-arangodb  | Initializing root user...Hang on...
yeti-arangodb  | Illegal instruction (core dumped)
yeti-arangodb  | Initializing database...Hang on...

I noticed that a recent commit pins the ArangoDB docker image version at 3.11.x, and I know ArangoDB offered an image of 3.9.x that did not rely on AVX instructions. Can someone offer some guidance as to whether or not I can run YETI on the older version of ArangoDB or if I have to upgrade my hardware?

[tomchop]

I think the best way to do it is to try it :) We've fixed the problem we were running into with 3.12 (which had forced us to pin it to 3.11.x), other than that we don't really know whether you'll run into issues using 3.9.x. Definitely worth a try!

[fl0wc0ntr0l]

I'll give it a shot - worst case scenario is that I'm back where I started from. I just wasn't certain if there was YETI code that required v3.11.x or not. Thanks! I'll let you know how it goes.

[fl0wc0ntr0l]

Nope, it did NOT like that...

yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [e52b0] {general} ArangoDB 3.9.12 [linux] 64bit, using jemalloc, build tags/v3.9.12-0-gf829585e5ee-dirty, VPack 0.1.35, RocksDB 6.27.0, ICU 64.2, V8 7.9.317, OpenSSL 1.1.1v  1 Aug 2023
yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [75ddc] {general} detected operating system: Linux version 6.5.11-8-pve (build@proxmox) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-8 (2024-01-30T12:27Z)
yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [25362] {memory} Available physical memory: 101318144000 bytes, available cores: 2
yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [3bb7d] {cluster} Starting up with role SINGLE
yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [f6e0e] {aql} memory limit per AQL query automatically set to 60790886400 bytes. to modify this value, please adjust the startup option `--query.memory-limit`
yeti-arangodb  | 2024-04-26T15:55:42Z [1] INFO [a1c60] {syscall} file-descriptors (nofiles) hard limit is 524288, soft limit is 524288
yeti-arangodb  | 2024-04-26T15:55:43Z [1] INFO [fe333] {engines} RocksDB recovery starting, scanning WAL starting from sequence number 128, latest sequence number: 202, active log files: 4, files in archive: 0
yeti-arangodb  | 2024-04-26T15:55:43Z [1] INFO [a4ec8] {engines} RocksDB recovery finished, WAL entries scanned: 75, recovery start sequence number: 128, latest WAL sequence number: 202, max tick value found in WAL: 112, last HLC value found in WAL: 0
yeti-arangodb  | 2024-04-26T15:55:43Z [1] INFO [c1b63] {arangosearch} ArangoSearch maintenance: [1..1] commit thread(s), [1..1] consolidation thread(s)
yeti-arangodb  | 2024-04-26T15:55:43Z [1] INFO [6ea38] {general} using endpoint 'http+tcp://0.0.0.0:8529' for non-encrypted requests
yeti-arangodb  | 2024-04-26T15:55:43Z [1] INFO [cf3f4] {general} ArangoDB (version 3.9.12 [linux]) is ready for business. Have fun!
yeti-arangodb  | 2024-04-26T15:55:45Z [1] FATAL [a7902] {crash} 💥 ArangoDB 3.9.12 [linux], thread 12 [RocksDBThread] caught unexpected signal 4 (SIGILL): signal handler invoked - image base address: 0x0000000000400000 - CPU context: rip: 0x0000000003993a8d, rsp: 0x00007fac94b79e10, efl: 0x0000000000010246, rbp: 0x00007fac94b79e80, rsi: 0x00007facaa891dc9, rdi: 0x00007facaa8a0c40, rax: 0x0000000000000000, rbx: 0x0039c00000000000, rcx: 0x0000000000000000, rdx: 0x00007facaa868b43, r8: 0x0000000000000002, r9: 0x0000000000000004, r10: 0x00007facaa8a0c40, r11: 0x00007facaa89ddf2, r12: 0x00007facaa891dc9, r13: 0x00007facaa891dc9, r14: 0x00007facaa891dca, r15: 0x0000000000003fff
yeti-arangodb  | 2024-04-26T15:55:45Z [1] INFO [c962b] {crash} Backtrace of thread 12 [RocksDBThread]
yeti-arangodb  | 2024-04-26T15:55:45Z [1] INFO [308c3] {crash} frame  1 [+0x00000000016555f5] (anonymous namespace)::crashHandlerSignalHandler(int, siginfo_t*, void*) (+0x35)
yeti-arangodb  | 2024-04-26T15:55:45Z [1] INFO [308c3] {crash} frame  2 [+0x00000000039288b5] sigprocmask (+0x21)
yeti-arangodb  | 2024-04-26T15:55:45Z [1] INFO [308c3] {crash} frame  3 [+0x00000000035941fd] snappy::Compress(snappy::Source*, snappy::Sink*) (+0x14d)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  4 [+0x0000000003594611] snappy::Compress(char const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (+0x81)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  5 [+0x000000000112f3ed] arangodb::RocksDBMetadata::serializeMeta(rocksdb::WriteBatch&, arangodb::LogicalCollection&, bool, arangodb::velocypack::Builder&, unsigned long&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (+0x6cd)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  6 [+0x00000000011537f3] arangodb::RocksDBSettingsManager::sync(bool) (+0x563)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  7 [+0x0000000001174953] arangodb::RocksDBBackgroundThread::run() (+0x1a3)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  8 [+0x0000000001667a6d] arangodb::Thread::startThread(void*) (+0x6d)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame  9 [+0x00000000016b6dda] ThreadStarter(void*) [clone .lto_priv.0] (+0xaa)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [308c3] {crash} frame 10 [+0x000000000392f6ec] start (+0x70)
yeti-arangodb  | 2024-04-26T15:55:46Z [1] INFO [ded81] {crash} available physical memory: 101318144000, rss usage: 214056960, vsz usage: 824516608, threads: 31

It's a shame but this is pretty old hardware and maybe I can convince my wife to let me upgrade it under the guise of electrical efficiency. ;)

[tomchop]

Thanks for looking into this! Good to know. That's a nasty stacktrace, I'm sure it will make a compelling reason to upgrade 😉