Александр Карабанов

Давайте разберём самое начало процесса, когда запускается ab и в нгинкс примерно одновременно начинают лететь 80 запросов. Счётчики в этот момент по нулям, но выставлен лимит в 1000 rps, то есть запросы могут обрабатываться не чаще, чем раз в 1 мсек.

По факту, внутрь провалятся ровно 1+10=11 запросов, а остальные 80-11=69 отобьются с 503 кодом - это даже больше 62%.

В дальнейшем, поскольку запросы постепенно размажутся во времени, перестав приходить синхронно, процент отлупов снизится, но отнюдь не до ожидаемых вами (1026-1000)/1000*100%, потому что время от времени (и скорее часто, чем редко) запросы всё-таки будут приходить чаще, чем раз в 1 мсек (бурст в 10 rps можно не учитывать, он по сравнению с лимитом микроскопический) - на это намекает среднее время исполнения 0.974 мсек, делёное на 80 потоков.

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

Gparted, QtParted и иже с ним.

Pma и mysql в разных сетях. У pma так же должно быть

networks:
      - app-network

Или другая общая с mysql сеть

файлы заблокированные на чтение в linux есть точно так же как и в других системах, исторически любое резервное копирование предлагается (в любой ос) делать через создание снапшота (в linux это средствами lvm если он используется или при использовани cow файловых систем таких как btrfs/zfs/... прямо их средствами), снапшот является замороженным мгновенным снимком файловой системы, без ограничений по чтению.

совершенно нормально, используя root копировать с помощью обычного cp (scp если по ssh) или rsync или к примеру tar -c . | ssh user@server tar -x скопирует все удаленно, завернув сначала в tar а на удаленной машине распаковав (с помощью ключей tar можно контролировать например файловую систему --one-file-system или передачу hardlink и symlink, например --dereference и --hard-dereference добавят в архив сам файл а не линк на него...)

осторожно, в рабочей системе могут быть запущенные базы данных, копировать файлы которых на живую нельзя (не будет гарантий что будут корректно скопированы данные), такие базы нужно копировать средствами баз данных

p.s. если же все же хочется скопировать систему как есть, а снапшоты недоступны, то лучше перевести диск в режим ro: mount -r remount,ro /dev/sd... и так с каждым разделом, на котором размещена система (тогда начнут отваливаться программы, пытающиеся делать запись) и уже получившиеся данные копировать
в этом случае можно использовать partclone, умеет копировать раздел как dd но не передавая сектора, помеченные как свободные, что заметно быстрее (собственно это самый быстрый способ скопировать раздел)

Если кратко то как то так.

1. Образы БД брать из офф репозитория, подкидывать только файлы конфигурации если требуются через docker-compose.
2. Образ приложения собирать либо на шаред раннерах, либо на своём раннере.
3. Собранный образ пушить в репозиторий гитлаба.
4. На сервере куда деплоить поставить гитлаб раннер, привязать к нему тэг.
5. В докер композ указать в качестве имаджа репозиторий гитлаба/имяобраза:тэг
6. В gitlab ci добавить 2 стейджа. 1 это сборка и пуш докер образов, 2 это выполнение на установленном раннере docker-compose up -d

for d in `kubectl -n your-namespace get deployments | grep -v NAME | awk '{print $1}'`; do kubectl -n your-namespace get deployment $d -o json > $d.json; done

или

for d in `kubectl -n your-namespace get deployments -o=name | cut -f2 -d'/'`; do kubectl -n your-namespace get deployment $d -o json > $d.json; done

а можно все в один файл, ещё проще:

kubectl -n your-namespace get deployments -o json > deployments.json

На "выделенном сервере" если доступ только у Вас отключение этих защит имеет смысл и в целом "безопасно".
Но на VDS во-первых это бессмыленно, во-вторых "небезопасно", а в третьих не получится :)

Во-первых, при чём тут python, вопрос по sql.
Во-вторых, SELECT * FROM mytable ORDER BY id DESC

ob_flush