smilingcheater

все упирается в бд, на ум сразу пришло вынести эту часть в микросервис

Какой ещё микросервис? Микросервис, который делает что?

В-нулевых, нужно конкретизировать что значит "упирается в БД". Тормозят какие-то конкретные запросы? СУБД не хватает ресурсов? Слишком медленный диск? Или, может, под "упирается в БД" вы понимаете всю бизнес-логику приложения, которую вы называете "берет из бд нужные данные" (и тогда становится понятно про микросервис)?
Во-первых, нужно вынести СУБД на отдельную машину, желательно на голое железо (если речь про реальный хайлоад, а не про кривой код и конфиги).
В-третьих, под это железо нужно СУБД корректно сконфигурировать.
В-четвёртых, нужно добавить кэширование.
В-пятых, нужно проверить алгоритмы и пофиксить узкие места (на последнем месте, потому что это самое трудоёмкое).

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем)

Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах. Есть достаточно проектов, написанных на Джанго, которые вывозят большие нагрузки.
Вы, в принципе, правильно сделали, что попытались поначалу закидать проблему железом - оно обычно дешевле, чем время разработчиков. Но параллельно надо и оптимизацией заниматься, и это требует системности, которой в вопросе не очень-то видно. Ну и компетенций разных - если тормозят алгоритмы - это одно, если конкретные SQL-запросы - это другое, если СУБД задыхается в принципе - это третье.

https://obsidian.md/

Идея двоично-десятичного представления не нова. Как минимум, 60 лет назад (а вероятно, что и ещё раньше) она имела практическую реализацию, как в аппаратной части (например, на IBM System/360), так и на языке высокого уровня (Cobol, 65 лет назад). https://ru.wikipedia.org/wiki/Двоично-десятичный_код
Поскольку Cobol до сих пор немножко жив (в США есть спрос на опытных программистов на Cobol, в основном в финансовом секторе), то при желании можете его использовать вместе с его реализацией двоично-десятичной арифметики.
Но скорость вычислений может быть меньше на порядок по сравнению с двоичным кодированием.

ради точных вычислений

арифметика с плавающей точкой в принципе не может быть точной. Например, в вашей любимой десятичной системе вы не сможете точно записать 1/3, 1/6, 1/7, 1/9, 1/11, 1/12, 1/13, 1/14, 1/15,.. (вам для этого потребуется бесконечно много разрядов, так же как в двоичной системе для ваших примеров 2,1;3,4;45,9). Проблему можно решить арифметикой с рациональными числами, но это будет ещё на порядок медленнее даже по сравнению с двоично-десятичной арифметикой. Реализации (библиотеки) тоже существуют - можете их найти и использовать, если готовы ради точности потерять в скорости в 100, а то и в 1000 раз (иногда точность на самом деле настолько важна, спору нет, но таких задач мало). Кстати, сравните возможности арифметики рациональных чисел с возможностями длинной арифметики. :) Тут не всё так однозначно.
https://ru.wikipedia.org/wiki/Длинная_арифметика

В целом вопрос хороший в плане вашей любознательности.

используй rewind() после ftruncate()

Чтобы попытаться стать РНР разработчиком (а не бабкой-гадалкой из соседнего ответа), надо открыть для себя волшебный мир отладки.
И для начала научиться получать от РНР сообщения об ошибках.
Во-первых, надо убедиться, что никакие ошибки не подавляются. Для этого в коде всегда должна быть строчка

error_reporting(E_ALL);

В-вторых, если для работы с БД используется mysqli, то не лишне добавить настройку ошибок и для неё.

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

В-третьих, возникающую ошибку надо, собственно, увидеть.
Для этого служат ещё две настройки. На локальном/тестовом сервере включаем вывод ошибок прямо на экран.

ini_set('display_errors',1);

На боевом - наоборот, выключаем вывод на экран и включаем вывод в лог

ini_set('display_errors', 0);
ini_set('log_errors', 1);

После этого запускаем свой код и смотрим, что написано в сообщении об ошибке.

В спящем режиме система не выключается и оперативная память ещё работает.

Решил сделать переход с MD5 на SHA256

Первая ошибка.
Переходить нужно сразу на password_hash
На переходный период реализовать две системы аутентификации. Сначала пробуете по старой (md5), если неудача, то password_verify
После удачной аутентификации хешируете пароль новым алгоритмом.

первый раз работаю с git

В первую очередь вам надо почитать учебник. Git это не та программа, с которой вы сходу можете начать работать. Он конечно простой, но вообще не интуитивно понятный.

выдает 10000 файлов в каталоге

Причина проста — вы инициализировали репозиторий находясь в корне вашего домашнего каталога. Нельзя так делать, если не хотите потерять свои файлы, бездумно вбивая команды типа stash.

Что мне делать

Удалить (или переименовать) подкаталог .git в котором хранится репозиторий. Затем создать его в правильном месте — в каталоге вашего проекта.

Let`s Encrypt , очевидно. Я вообще не понимаю, кому сейчас нужны покупные сертификаты, кроме банков и подобных структур, где наличие покупного сертификата вписано в регулятивные правила отрасли.

Вы сами процитировали причину:

Нельзя начать пересборку ветки (cannot rebase), пока есть незакоммиченные изменения в рабочем каталоге (You have unstaged changes).

Гит будет пересоздавать заново коммиты, а для этого нужен свободный рабочий каталог, в который распаковываются промежуточные состояния проекта.

Поэтому гит предлагает закоммитить или спрятать несохраненное (Please commit or stash them)

Команда git stash по факту тоже создает коммит, но он не привязан ни к какой ветке и рабочий каталог становится чистым. Затем вы делаете свои нехорошие дела и восстанавливаете stash обратно в рабочий каталог.