The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз СУБД PostgreSQL 11, opennews (?), 19-Окт-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


129. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 14:30 
Ладно, понял, что осмысленно диалога "DBA с двадцатилетним стажем" не выйдет.
Просто накрутите
-- autovacuum_vacuum_cost_limit в десять раз (больше 1000) поставьте;
-- autovacuum_vacuum_cost_delay сделайте в районе 5--10.
Если не помогло, то предварительно всё же стоило убедиться, что проблема именно в недостаточно частой "уборке" файла отношения. Потому что подобное поведение может быть следствием очень длительной транзакции, которая работает по данным, которые вы часто изменяете, а значит -- это ошибка вашей модели и её нужно корректировать. В общем, не тупите и читайте документацию.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

153. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 23-Окт-18, 09:36 
Ну нету там длинных транзакций, нету инсертов, делейтов, много коротких апдейтов, и это НЕ единственная таблица, другим тоже нужны ресурсы процессора, память, вакумы, и т.д.
Вакуум на ней висит практически постоянно, и не успевает, блять 2000 строк уже 260MB, простенький запрос к этой таблице должен выполнятся мгновенно, а он задумывается
Ответить | Правка | Наверх | Cообщить модератору

154. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (27), 23-Окт-18, 11:31 
Думаю, вы уже знаете, что в Слоне update-ов нет, а есть delete/insert. Как и все современные РСУБД Слон работает исключительно с кэшем буферов (не с диском), а синхронно пишет изменения только в WAL. Поэтому ваш характер нагрузки на нормально настроенном серваке не должен приводить к частым сбросам буферов в файл (и его росту) -- данные меняются в кэше и, по идее, их вообще не нужно сбрасывать в файл. Вам этого и нужно добиться. Увеличивайте а) время между чекпоинтами, б) размазывайте фактический сброс по этому времени сильнее, в) проверьте достаточно ли памяти вашим процессам автовакуума (см. логи на предмет ошибок недостатка памяти, их в таком случае будет очень много), г) настройте параметры вакуума для конкретного отношения (настройки выше проскакивали), д) чтобы HOT-механизм работал эффективней (а это как раз ваш случай, у вас же не меняются индексные поля), увеличивайте значение филфактора для данной конкретной таблички.
С много процессов параллельно пытаются эти ваши статусы менять?
Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 23-Окт-18, 14:40 
есть и много процессов, но разные строки, read commited,
в данном конкретном случае, 2-3 процесса, (плюс позанимался, добавил нужных индексов для других таблиц, в целом уменьшилась нагрузка на сервер), сделал
alter table  set (autovacuum_vacuum_cost_limit = 1000);
alter table  set (autovacuum_vacuum_cost_delay = 5);
теперь автовакум не висит постоянно, остановил все сервисы, сделал VACUUM FULL
через пол дня:
Кортежей доступно    2130    
«Мертвых» кортежей    28101
vacuum verbose
найдено удаляемых версий строк: 0, неудаляемых - 30230,
какого хрена?, никто таблицу не блокирует
select * from pg_catalog.pg_locks l where l.relation=23037
пусто
Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 15:32 
Блокировки тут не причём.
Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.
А vacuum full эти мёртвые кортежи убирает?
Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.
Ответить | Правка | Наверх | Cообщить модератору

159. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 16:01 
Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.
T1 началась во время t1.
T2 началась в t1 + 1.
T3 : t1 + 2
T4 : t1 + 3.
Ну и т.д.
Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.
На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.
Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

160. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 16:05 
А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?
Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

161. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 26-Окт-18, 09:10 
Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!
Ответить | Правка | Наверх | Cообщить модератору

162. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forth (ok), 26-Окт-18, 10:24 
> Короче, нашел, в этой же базе но, вообще не имеюшее к этой
> таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но
> у него свои таблицы и к моей никогда не обращается!!!

Чужое приложение научили делать commit? Помогло?


Ответить | Правка | Наверх | Cообщить модератору

163. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 26-Окт-18, 16:42 
Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я рубал все их сессии, и пока не налезли опять, вакум проходил
но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и к СВОИМ таблицам, короче бред какойто
Ответить | Правка | Наверх | Cообщить модератору

164. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forth (ok), 26-Окт-18, 18:26 
> Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я
> рубал все их сессии, и пока не налезли опять, вакум проходил
> но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и
> к СВОИМ таблицам, короче бред какойто

Если дело в одной БД происходит и даже в разных схемах - бывает просто имена совпадают, допустим в вашей схеме (дефолтный public) есть таблица state и у него есть в его схеме таблица с тем же имененм, но в запросе указать схему чужой разраб забыл и обращается не к своей, потом получает не те колонки вылетает с софте ошибка и коннект с тразакцией теряется и висит бесконечно.

Ответить | Правка | Наверх | Cообщить модератору

155. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 11:38 
Не зря вас про уровень изоляции транзакции спрашивали. Если у вас много параллельных запросов на изменение, к тому же все они serializable, то что-то подобное может произойти. Если приложение работает через jdbc-драйвер нужно проверить какой режим изоляции для транзакций выбран.
Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру