Здесь вы присваиваете алиас команде /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 запись.

То нужно что-то что позволит с ним работать, по нужному протоколу. Например, если это smtp, то это может быть и https://www.drupal.org/project/smtp, и https://www.drupal.org/project/symfony_mailer с smtp транспортом и наверняка ещё есть что-то.

Если не используется внешний почтовый сервер, конечно нужно - чем-то посылать-то всё равно нужно.

Всё что ставится на стороне Drupal, требует чего-то внешнего:

• это может быть и внешний сервис
• почтовый сервер на стороне той же виртуалки
• почтовый сервер на стороне хостера

Модули просто дают разные дополнительные возможности, например, делать атачи, использовать не только php mail(), использовать какие-то не smtp сервисы для отправки и.т.п. Т.е. расширяют возможности взаимодействия с почтой, но не доставляют её клиентам непосредственно.

Так она чаше всего и будет в спаме - этого мало.
Как минимум, надо настроить SFP запись, DKIM, например с помощью opendkim, и PTR соответствующий имени хоста почтовика.

С минимальными знаниями внешний сервис. Их много.

Чтобы доставлялось как-то со своего сервера, минимально надо проверить и настроить SPF, DKIM, PTR. А также пробить ip виртуалки по спам листам.

Sendmail такое себе решение, сложное и устаревшее.
Лучше и проще настроить postfix или exim.
Чтобы настроить почтовик надо немало знать, на самом деле о том, как это всё работает, чтобы настроить его для своей задачи. Брать какой-то пошаговый howto довольно бесполезно в любых ситуациях, а в этой и подавно... Даже если будет работать, доставляемость чаще всего будет никакая. Без этих знаний куда разумнее будет использовать готовый внешний сервис.

Аpache + mod_php быстрее чем apache + php-fpm, на самом деле. Apache не ставят не из-за скорости обработки отдельных запросов, а из-за ресурсоёмкости излишней на каждый запрос, даже к статике.

Конечно нет, надо создать новый конфиг из этого шаблона, заменив там часть данных, например домен и путь до webroot.

Надо было запускать друш с нужной версией php просто.
Как-то так:
/path/to/fresh/php-cli /path/to/drush
Пути конечно могут быть разными, но скорее всего для php что-нибудь вроде /usr/bin/php8.1

drush uli если есть доступ из консоли.

Будет работать только из корня проекта.

Какая-то каша. /vendor/bin/drush это абсолютный путь, он может быть только один и явно странный.
Под каким пользователем ведётся разработка?
Чтобы было удобнее, можно делать отдельных пользователей для отдельных сайтов, например.

Лучше делать как предлагает @yaro, но если хочется через $database->query(), то надо не пытаться запихнуть аргументы прямо в текст запроса, а использовать плейсхолдеры для аргументов, а их передавать в массиве вторым аргументом qurey():

VasyOK wrote: Или мне .bashrc для каждого сайта создавать?

Для каждого пользователя, скорее...

На самом деле, просто не под рутом это надо сделать, а под пользователем, который работает с сайтом, и соответственно не в /root/.bashrc, а в таком же файле в домашней папке этого пользователя.

Боюсь, что для drush arb не добавили нужного аргумента.
Можно не пользоваться drush для архивирования, вообще говоря. Или только дамп им снимать, чтобы не задумываться о пароле к базе, а файлы нужные паковать tar, например.

А что именно делать в вашей конкретной ситуации, зависит от задачи. Например, для резервного копирования, обычно достаточно снять дамп и сохранить /sites/, или даже sites/*/files, если используется система контроля версий для кода, и это лучше делать специализированными инструментами автоматически и регулярно.