edo1h

zpool показывает свободное место без вычета контрольных блоков (их же пока там нет).
zfs же показывает (примерно) то, что вам нужно.

если бы не было никаких накладных расходов, то вы бы увидели 3.6T:

((500 ⋅ (10^9)) ⋅ (10 − 2)) / (1024^4) ≈ 3.637978807091713

Здесь указывается

ну там же ответили: один воркер может проснуться и «схапать» все ожидающие входящие соединения, в результате будет дисбаланс ну и вообще не очень хорошо.

Как стоит поступить на многоядерной системе Debian 11 x64?

правила простые: если что-то не понимаете — не меняете, дефолт нжинкса достаточно хорош для большинства применений.

Говоря простым языком, на сайте может быть онлайн более одного человека при multi_accept off?

ИМХО проще взять и проверить, чем тут спрашивать.

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

«Потребление swap» нужно в первую очередь смотреть не в гигабайтах, а в операциях в секунду, если у вас нет никакого мониторинга, то можно с помощью iostat -mxzp 10
Если у вас много IOPS на разделе со свопом — тогда и нужно что-то предпринимать, если же нет — радуйтесь, у вас там осели неиспользуемые данные, можно сказать бесплатно память добавилась (хотя для заметного эффекта размер свопа должен быть одного порядка с размером памяти, конечно).

«Много IOPS» — это сколько? Можно считать в процентах от производительности диска, условно HDD умеет 100 IOPS, так что менее 10 обращений к свопу в секунду (менее 10% от потенциала диска) не окажут существенного влияния на производительность системы. Для SSD цифры будут куда выше, там и тысячи IOPS на своп могут быть нормальными (но для десктопных SSD надо помнить про ресурс дисков/забивание SLC кэша).

что будет при увеличении кол-ва машин (боюсь увидеть 100%)?

Само по себе это не не страшно. Но вот если приложениям (виртуальным машинам в вашем случае) не хватит общей памяти (физическая+своп), то у ядра не остаётся выбора кроме OOM killer.

Повторюсь, особого смысла в свопе, размером на порядок меньшим, чем объём физической памяти, я не вижу.
Обычно я настраиваю размером или с RAM (там, где он нужен, как в вашем случае), или вообще без swap (если на хосте, скажем, только postgresql или elsaticsearch).

Резюмируя:
- если у вас всё нормально с производительностью, IOPS, связанных со свопом мало — то ничего не делать, разве что рассмотреть возможность увеличения раздела со свопом «на вырост»;
- если дисковая система тормозит, то увеличивать объём оперативной памяти (или умерять аппетиты приложений).

плюс принцип "Не делай то, что не нужно делать"

ну так и надо использовать уже имеющуюся инфраструктуру, а не устраивать «закат солнца вручную»

вариант 1:
первая ссылка в гугле по «python pid file»:
https://pypi.org/project/python-pidfile/

вариант 2:

Да и условия эксплуатации скрипта - только cron.

независимо от нашего отношения в systemd, нам с ним жить. и этот функционал там из коробки:
https://unix.stackexchange.com/questions/203254/do...
так что если скрипт linux-only, я бы просто сделал запуск не из крона, а таймерами systemd, и пусть уже сам systemd следит завершился предыдущий экземпляр или нет.

если отвечать на вопрос как он задан, то
aptitude remove mariadb-server mariadb-client
с настройками по умолчанию удалит те пакеты, на которые ругался apt-get, и автоматически установленные пакеты.
purge стоит делать только осознанно, он отличается от обычного remove тем, что удаляются все конфиги (если у вас стоит задача перейти на более новую версию, то это может быть не то, что вам нужно).

если же «читать между строк», то конечная цель — не удаление пакетов, а разрешение зависимостей.
можно попробовать использовать aptitude, у него немного другой алгоритм разрешения зависимостей + есть интерактивный режим.
просто запускаете aptitude, в нижней строке будет подсказка по горячим кнопкам.

быстрее перести каталог базы рсинком или mariabackup (если у вас mariadb)