Не понимая основ и не имея возможности оценить корректность предложения, крайне опасно надеяться что ИИ даст разумный ответ на заданный вопрос, и он будет верным. И совершенное безумие такой ответ вставить как команду в консоли на сервере, например...

Зачем вам Monjaro? Это совсем не праздный вопрос, и не вопрос вкуса даже.
По какому-нибудь Ubuntu будет в разы больше информации, больше народу наступившего на грабли и.т.п. Т.е. решить любую проблему будет проще. Крайне советую развернуть именно его, особенно для новичка.

riaron986 wrote: Не знаю в каких файлах по каким директория менять содержание по пункту 3,

Для начала, надо с помощью top(htop, btop, atop и.т.п.) определить, какой процесс создаёт эту нагрузку.
Вообще, весьма возможно, прав @marassa, и там какая-нибудь вирусня, она чаше всего запущена от пользователя сайта, но может прикидываться системными процессами.

Вам надо работать не с базой, а с сущностями Drupal: нодами их полями и.т.п. Он сам будет куда надо в нужном формате всё записывать в базу уже.
Вероятно, ваш модуль так и работает, собственно.

Наверное, самый правильный вариант для вашего сценария, создать свою drush command в своём модуле и вызывать её через drush в системном cron с нужной периодичностью.

VasyOK wrote: После этого он работает по адресу:
http://:8983/solr/

В этом случае, возможно лучше повесить его на 127.0.0.1:8983

VasyOK wrote: Couldn't index items. Check the logs for details.

Что я сделал не так?

Надо почитать логи, как предлагают, и станет понятнее...

Всё потому, что кешированием должно заниматься приложение, а не веб сервер или ещё что-то стороннее.
Соответственно, решать что кешировать, и что ещё важнее, что и когда инвалидировать правильно там, где есть данные для этого. С varnish это ещё теоретически возможно, с nginx fastcgi microcache каким-нибудь или кешом на стороне apache, и вовсе нет.

В общем, нет какого-то лучшего кеша для drupal(или чего-то ещё), есть более или менее подходящие хранилища для разных случаев.

Вот только нафига при этом, иметь хотьт одну версию Apache на машине, я не знаю.

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

Потому что в nginx они есть. Fastsocket например

Это не о том. Это о работе с клиентами по сети.

Естественно - mod_php экономит на межпроцессном взаимодействии запускаясь внутри процесса apache.
Но это всё ничтожно на фоне выполнения сколько-то сложных скриптов.

А зачем вообще сетевые сокеты использовать, если php-fpm и apache на одной машине? Unix сокеты имеют меньший оверхед, и когда говорят о сокетах, в данном случае, имеют в виду именно их.

Это просто не нужно никому. Чаще всего используют в таких сценариях другие web серверы.

Есть group, но это больше о доступе к контенту групп, не о пользователях.
Но может задача такова, что этого будет достаточно.

Здесь вы присваиваете алиас команде /opt/php8.2/bin/php -d memory_limit=500M ~/composer.phar. Если она у вас в таком виде нормально работает, и с алиасом должно быть всё ок.

Очень зависит от запроса. До этого могут происходить разные join и сортировки, которые и составят основную нагрузку которую создаёт запрос...

Советую познакомиться поближе с отладкой sql запросов, начиная с EXPLIAN.

дубль

Крайне не рекомендую слепо следовать этим рекомендациям не понимая, что меняется и зачем.
Это совсем не кнопка "сделай хорошо". А как и различные pagespeed, и подобные инструменты, это набор общих рекомендаций, исполнение которых, в определённых условиях, может помогать, может не помочь вообще в конкретной ситуации, а может сделать даже хуже в определённых ситуациях.

Например, такой здоровый innodb_log_file_size не часто нужен в принципе. innodb_buffer_pool_size делать такого объёма, возможно, тоже не нужно в вашем случае, даже если базы суммарно в вас и больше и.т.п.

Автоматизацию работающую не на паре тройке простых случаев будет _очень_ сложно написать...

Так это не техническая проблема - если клиент не хочет оплачивать реботу, вероятно её не стоит вообще делать.

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

Ну во-первых, надо наверное почитать документацию о логе медленных запросов, установить нужный лимит на длительность запроса и.т.п.
Также в realtime можно посмотреть что происходит в mysql/mariadb с помощью утилиты mytop.

При этом, надо смотреть ещё потребление ресурсов. Там куда интереснее будет картина - потребление памяти в случае apache должно быть заметно больше, и больше зависеть от количества подключений. А именно в скорости разница не велика, собственно всё время почти в php-fpm, который тут одинаков.

Ну и сравнивать имеет смысл c apache + mod php. Apache + php-fpm в принципе довольно странная связка.

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

Я, вот, всё это неплохо умею, но почта моих доменов обслуживается одним из хостеров за мелкую копеечку, а не на одном из моих серверов.

Вообще-то не совсем всё так плохо. Часть адресов действительно находится в блек листах, если на них были кривые почтовики, или ими пользовались спамеры, но это решаемая проблема.

SPF это просто TXT запись, и она должна быть просто правильно указана. Т.е. указано откуда можно принимать вашу почту.
А вот с DKIM, всё куда сложнее. Это криптографическая подпись письма на стороне отправителя. Оно не только в DNS, оно и на сервере, собственно, подписывать должен какой-то софт, который надо настроить, сгенерировать пару ключей, и публичный ключ поместить в ту самую DNS запись.