это нормальное состояние на высоколатентных дисках. Смириться или переезжать на нормальные диски.
"писать большими блоками"
у вас обновилась одна строка таблицы и соответственно к определению этой таблицы допустим пять индексов. Разумеется, это 6 разных блоков в разных местах. Ну и как вы их запишете одним большим блоком, ммм?
вы бы хоть написали в вопросе, что это вообще дисковая полка. Там-то причин куда больше бывает. По вопросу выглядит, что вы перетыкаете кабель напрямую от atx блока питания напрямую к диску...
базу-то пересоздали перед второй попыткой импорта?
ALTER DATABASE zabbix_two OWNER TO zabbix_user2;
не вы первый для кого это неожиданно, но owner базы даёт права только на саму базу. То есть CREATE (создание новых схем, публикаций, trusted extensions (замечу, даже не create table, оно в грантах уровня schema)), CONNECT (возможность подключиться к этой базе), TEMPORARY (возможность сделать create temp table) но ничего сверх этого. Никаких рекурсивно выданных прав на объекты внутри этой базы.
а как то можно сменить владельца таблиц разом?
написать запрос, который сформирует список (внимательно не зацепить системный каталог) alter table .. owner .. и выполнить полученные alter'ы. Плюс аналогично сиквенсы и что ещё было.
для обычных дел есть reassign owned, но оно будет плохой идеей для смены владельца с суперпользователя на обычную учётку. Зацепит много лишнего и возможно даже с фейерверками
Adamos, не я администратор этого сервера, не могу угадывать задачи и вероятные потребности. Но два соображения есть сразу:
centos 7 емнип делает lvm по-умолчанию - то есть об этом могли не думать вовсе
это виртуалка, поэтому возможно предполагалось иметь возможность дальнейшего расширения места методом добавления новых виртуальных дисков, что легко решается через lvm
Adamos, lvm как раз-таки не новомодная умная прослойка, а очень древняя и тупая. И никаких взмахов мышей не подразумевает. Примерно как назвать 800.COM флопиком, который можно будет прочитать на любом компьютере.
Ну, если работать с linux так же часто как я с виндами (то есть только на картинках), то да.
Напишу прямо: бесполезно искать или пытаться менять любым способом max_locks_per_transaction в конфигурации самого postgresql. Все вопросы только к patroni. patroni намеренно передаёт часть настроек напрямую аргументами бинарнику базы при запуске. Это высший приоритет и ничем в конфигурации базы не переопределить.
Как менять эти 6 параметров найдите в документации patroni и только в его документации, потому что это сделано и задокументировано в patroni именно так намеренно.
если файловые системы какие-то отличные от ext4, то использовать вместо resize2fs подходящий инструмент.
PS: если xfs - то проблема, он уменьшаться не умеет вообще
если у вас на базе не 50к tps, то вы на самом деле не хотите ввязываться в это граблехранилище. Если у вас больше - то... Что ж, вы тем более не хотите связываться без поддержки DBA.
для микросервера на 512мб ram, ещё и совмещённого с приложением (непонятно сколько памяти потребляющим) дефолтных 128мб shared_buffers явно слишком много. Рекомендация выдавать под shared_buffers 25% ram - это про выделенные сервера именно под базу и при хотя бы 8гб ram.
серьёзно?