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

Эта ошибка НЕ связана с ограничением memory_limit d php, вообще никак.
Это ошибка нехватки памяти на сервере в принципе. Т.е. просто нечего физически выделять.

Ошибка при достижении лимита выделения в php вот такая:
Fatal error: Allowed memory size of XXX bytes exhausted

Это сильно не так. Там можно найти очень разного формата заказы.

Ну и ставки, обычно, куда больше чем на 20% больше чем на наших биржах. Также, 20% это только до $500 дохода с клиента, потом 10% и потом 5% но уже с довольно приличной суммы.

Оплата за часы это вполне нормальная практика. И очень часто применяемая.

Обсуждать проект можно и там вполне. Мало того, это часто, повышает вероятность получить хороший проект.

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

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

Нет, вы ошибаетесь, это не будет работать при таком сообщении. В обоих случаях, и при memory_limit и при таймауте выполнения, была бы внятная ошибка со стороны php, точно указывающая на причину проблемы.

Ошибка "Killed", как тут, это либо вручную снят процесс, либо OOM killer при критичной нехватке памяти( ну а точнее SIGKILL или SIGTERM отправленные процессу извне, если быть точным). И именно в данном случае, это наверняка OOM Killer.

Там было бы не killed, а ошибка php в стиле "memory limit exceed".
Тут не хватает именно выделения на стороне ОС, и срабатывает OOM killer.

Правильно - надо делать update на dev, а на prod делать install, как правильно выше написано.
Второй вариант - свап или доп. память.

Второй композер конечно менее прожорлив, но не так уж и лёгок в update. Первый конечно мог и пару гигов целиком сожрать. Но и второй несколько сот мегов может.

Чтобы отображались только сегодняшние, например ноды, это имелось в виду?

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

И изучать docker всяко полезнее чем разные docksal/ddev и.т.п., об этом именно было написано. Потому, что именно это тот инструмент которым вы пользуетесь. А изучать обёртки над ним это путь в никуда - время тоже будет потрачено, но при любой проблеме придётся тупо гуглить в надежде, что на грабли кто-то уже наступил, вместо понимания того, где проблема.

Ну и для поднятия продакшен окружения, ни d4d, ни docksal не годятся совсем, так на всякий случай.

И не заработает, т.к. на сервере уже есть кому слушать 80/443. Или придётся как для d4d писать конфиг nginx.
Лучше изучить docker и свои делать наборы контейнеров, понимая, что делаешь, чем лезть в эти чёрные ящики, к тому же применяя их не по прямому назначению...

В веб сервере, который запущен на удалённом сервере. Надо написать конфиг для этого сайта.

Этот набор заточен для локальной разработки, так что "как есть" использовать его не получится в таком сценарии.

Тут есть две вещи, которые нужно сделать по меньшей мере:
Чтобы резольвился правильно testdocker.local в браузере, надо добавить в hosts на локальной машине:
testdocker.local ip_удалённого_сервера

1. И закономерно. Такое не меняется в рамках одной версии операционки.
2. В debian вообще с webp всё не просто, вероятно из-за лицензионных каких-нибудь заморочек.
3. И зря в общем-то.

Если у тебя там старый debian или ubuntu 18.04, то придётся пересобирать php или устанавливать его из сторонних репозиториев.
Ну или на imagick перейти.

Это не выделенный сервер, это VPS, поверх которого поставлена какая-нибудь кривая панелька(потому что нормальная денег стоит), и дана техподдержка, которая, обычно, у хостеров ничего не умеет толком, кроме самых базовых вещей.
Такое называется managed VPS. И часто, лучше уж шаред хостинг, потому, что квалификации админов и поддержки на него нужно меньше, т.к. всё одинаковое.

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

Если такого нет, ваши хостеры явно придумали фигню. В мире шаред хостинга так бывает не редко...

Выделенный сервер, это когда есть доступ ко всему серверу, и надо самому всё настраивать, в частности конфиг nginx. А когда всё спрятано за панелькой, это скорее всего всё же шаред хостинг.

Если используется nginx + php-fpm, то зависит от того, как написан конфиг nginx.
Если apache + php-fpm, от того как настроен apache, и если включена обработка .htaccess, от того что в нём.

У php-fpm нет каких-то специфичных настроек для разных приложений, только runtime настройки php и кол-во порождаемых процессов, если упростить.

Это не всегда так, но на уровне 1,5с, это конечно очень небольшое время, даже на 2GHz проце.

Php-fpm сам не обладает каким-либо функционалом фильтрации запросов. Что-то можно делать либо слоем выше, в настройках веб сервера - это значительно эффективнее, потому что запрос не будет доходить до обработчика php вовсе, либо слоем ниже, в настройках приложения, что создаст дополнительную нагрузку.

Да.

Что возвращает nslookup legalcompany.com.ua у этого клиента?
Где находится клиент?
Остальные сайты не в tld ua?

По whois:
domain: legalcompany.com.ua
dom-public: NO
mnt-by: ua.ukrnames
nserver: dns1.vps-private.net
nserver: dns2.vps-private.net
status: ok
created: 2015-12-14 16:31:34+02
modified: 2022-09-29 15:05:29+03
expires: 2022-12-14 16:31:34+02
source: UAEPP

А как выглядит "не работает у проблемный клиентов"? Какая у них ошибка?

Чаще всего, никакой настройки не нужно. А если она нужна в сети определённого провайдера, то не будет работать ни один сайт. И на своей стороне это никак не исправить.