smilingcheater

При использовании postman ничего проксировать не надо, он делает запросы без ограничений. Т.о. ошибки у вас возникают не по этой причине, а из-за кривых запросов и\или кривого сервера. Пытайтесь дальше.

P.S. Ограничения есть в браузере, если вы будете писать клиентское приложение то изучить, что такое CORS вам придётся в любом случае.

Процессор отличный , видеокарта отличная , память и ssd здесь вообще не причём .
А вот материнская плата может дать проблемы . У неё зона VRM без охлаждения . На плате 8 кубиков - это дроссели а рядом с ними по 3 штуки - это полевые транзисторы , вот им нужно охлаждение , у вас они без радиаторов , а рассколятся они могут больше 100градусов при бусте процессора 4200гц.и проц ведёт себя не стабильно .
Есть комплекты для самостоятельной установки охлада , или поменяйте процессорный куллер с башенного типа на обычный , который будет обдувать зону VRM питания процессора.

Как всегда, в заголовке одно, а в тексте вопроса совсем другое. И никакое кэширование автору делать на самом деле неохота - это же переделывать всё придется.

При этом чего именно нужно автору, из вопроса непонятно. То ли проблема с потреблением памяти, то ли скорость запросов, то ли вообще никаких проблем нет, а просто поговорить на с кем.

Ускорение запросов решается за счет создания индексов. Не "есть индексация", а конкретные осмысленные индексы для каждого используемого запроса. Если конкретный запрос тормозит, ему надо сделать explain, и на основе полученного результата подумать и реализовать индексы.
При этом нормально индексы работают только если все они помещаются в памяти. А это значит, что по поводу "7 гигов занято" надо не плакать а радоваться.
Существование "таблиц" для новых и старых сообщений в рамках одной таблицы - это партиционирование, например по дате. Но опять же, сначала надо определиться задачей, которую мы решаем.

Мне постоянно советуют rsync

Неужели такая странная хотелка, что нет готового решения?

Так тебе и советуют готовое отличное решение.

, но это же просто продвинутая замена scp. Там даже для обратной синхронизации надо его запускать второй раз с другим направлением.

Нет, это не замена scp. То, что используется тот же протокол не значит что работает одинаково. rsync умеет обновлять файлы частично, экономит трафик.

Вот пишу я какой-то код на ноуте. А запускаю на сервере. Как мне самым простым способом синхронизировать две директории — локальную и серверную?

Обычно для таких вещей используют систему контроля версий, что гораздо лучше чем просто синхронизация директорий.

В твоих требованиях противоречия.
То тебе нужно, чтоыб какие-то файлы не синкались. То есть уже нужно поддерживать список исключений и возможно настраивать его на каждом сервере.
Потом у тебя день поработать на каком-то сервере, а завтра на другом. То есть ситуация, когда у тебя 5-10 серверов и ноут будут синкаться друг с другом?
Потом ты хочешь "готовое решения", но не хочешь ставить его на каждый сервер/ноут и настраивать. Ну вот есть какой-нить unison, который синкает в обе стороны за один запуск, но его нужно будет и ставить и настраивать как и synthing, который ты не хочешь ставить или настраивать.

Я бы не парился, а просто юзал приватный git репозиторий, который легко поставить везде. И в гите не обязательно сотни веток и даже коммит можешь просто ребейзить постоянно, чтобы был один.
Или rsync который уже обычно есть почти везде и который понятно как работает.

Или уж настрой тот же synthing, а настройку добавь себе в гитхаб, чтобы можно было скриптом скачать готовый сетап и все.

Да, странная. Обычно бэкапы делаются по расписанию, а для этих целей rsync хватает.
А твой скрипт после написания и отладки как раз и превратится в неполное подобие syncthing, nextcloud и т.п.

используй на сервере базовую аутентификацию

Зачем привязка к бутстрапу, если на css вам хватит двух-трех строк кода для описания желаемого?

мобильники - вообще ничего не делаете. Блоки и так уже идут в столбик.

Дальше простой запрос

@media (min-width: 768px) /* ширина по вашему хотению */ {
  .block {  
    display: grid;
    grid-template-columns: repeat(3, 1fr);
  }
  .yellow {
    grid-column: span 3;
  }
}

Вы вообще не в ту сторону шагаете.Какие тут скрипты??

Утечки памяти это не проблема операционной системы (ну разве что утечки именно в ней).

Утечки памяти, это проблемы конкретных приложений, которые запрашивают память для создания какой-то переменной или массива переменных, чтобы разместить в них данные. Затем, когда переменные больше не нужны, забывают их удалить. И в следующий раз снова запрашивают еще память. так потихоньку приложение растет и растет.
При этом никто не может сказать со стороны - ни скрипты, ни операционная система, какую именно память приложение использует активно, а про какую уже "забыло".

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

Тут нужно разбираться с вашими приложениями, с теми кто их писал.
Иначе - ну ребутать разросшиеся приложения регулярно, если этот вариант возможен.

я сейчас думаю о покупке видеокарты(бюджет +- 80к)

Можно на эти деньги найти RTX 4070ti

и материнской платы(+-20к)

что-нибудь на B550 с нормальным питанием ищи, что будет у тебя в наличии.
Обзоров достаточно.

чтобы все было совместимо и было на одинаковом уровне если так можно сказать

Что такое "одинаковый уровень"?

Никак.

Ловите своих DBA, архитектора, безопасников, начальство и совместно вникаете, существует ли вообще вектор атаки, от которого вы так пытаетесь защититься.
Один постоянный универсальный ключ шифрования зашитый в приложении и открыто передающийся по сети - это больше профанация чем безопасность. И хорошо ещё, если ключ не сохраняется в логах базы вовсе в открытом виде.

Если начальство решает, что да, такое шифрование необходимо и от чего-то защищает - то это будет прямым ответом на задачу: поскольку необходимо шифрование parent_iin, то быстрый поиск по этому полю невозможен.

Единственное возможное исключение: если ваша функция шифрования обязуется быть immutable в терминах postgresql, т.е. на один и тот же ключ и исходные данные генерировать всегда один и тот же бинарно идентичный результат. Тогда делаете индекс по parent_iin и ищете по условию where parent_iin = функция_шифрования(данные, ключ) то есть по зашифрованному представлению данных.

Перед тем, как пытаться подключиться к серверу MySQL, его надо запустить.
Если вы понятия не имеете, что такое сервер MySQL, то ищите нужную кнопочку в своей панельке управления, которая за вас решает, какие программы вам нужны.