poige

Для начала, vm.overcommit_memory поставить в 1, если там 0.

Через консоль работает, с помощью cron нет?

Из консоли, небось, в нужном каталоге работает, а cron-то его не в оном запускает.

Поставить можно, но с 2 GB смысла маловато, поскольку код архитектуры x86 использует пространство ОЗУ эффективнее где-то в 1.3—1.5 раза — просто потому, что размер указателей в x86_64 больше в 2 раза. Это касается, в том числе, и разделяемых библиотек. Понятно, что если оба процесса выделят 1 GB, это будет один и тот же гигабайт и там, и там, но если говорить про накладные расходы — сколько памяти нужно задействовать чтобы развернуть исполняемый код в оперативку, например, то x86 скромней. Есть небольшой проигрыш в производительности (у x86 меньше оперативных регистров), но этим часто можно пренебречь, а вот тормозами из-за swap'а пренебрегать, как правило, сложнее.

Был проект получить лучшее от «2-х миров» — x32, но, критической массы, чтобы всё завертелось, он, увы, не набрал.

Правильный ответ — агрегация. Ни одна файловая система POSIX-семантики не будет нормально работать с таким кол-вом файлов.

В качестве знакового примера можно привести переход Ceph на использование RocksDB — в storage backend "BlueStore".

P. S. Скорее всего, за прошедший год, topic starter в этом убедился. :)