Интенсивное обновление СУБД + autovacuum. Золота середина?!

kamakama
Дата: 20.04.2015 18:20:29
Доброе время суток. Имеется не очень большая (пока) база PG 9.2\Gentoo на VM (8vCPU, 24 GB, RAID 10).
shared_buffers = 16GB. Основная нагрузка приходится на 4 таблицы, которые в сумме занимают около 60 GB. Периодично (несколько раз в день) происходит удаление и перезапись данных (математические расчеты) в объеме примерно 10-15 %. Еще реже - примерно 1 раз в месяц - полное обновление всех активных таблиц (на текущем железе ресурсоемкий процесс занимает 10-12 часов).
Уже выполнено партицирование, активный объем данных для связанных таблиц примерно 3-4 GB. Оптимизация чтения организована с помощью предрасчитаных агрегатов (этакая мини пародия на OLAP). Сейчас на этапе разработки достаточно VACUUM FULL
Вопрос - как организовать работу на продуктиве? Как обычно, 24/7, доступ блокировать нельзя даже частично. Как в таких условиях настроить autovacuum? Пытались сделать это на настройках по умолчанию, но при запущенных операциях пересчета все тормозится до совсем медленной скорости. Или изощраться и придумывать варианты с кроном?
tadmin
Дата: 20.04.2015 18:41:55
kamakama,
вы определитесь, что именно вас сейчас не устраивает. Если есть операции, скорость которых вас не удовлетворяет, дайти запросы, планы.
Maxim Boguk
Дата: 21.04.2015 03:58:45
kamakama,

У вас скорее всего не хватает скорости дисков, вот туда и смотреть (а то есть привычка базы на 1 SATA диске держать вместо нормального рейда или серверного SSD).
Если autovacuum мешает работе - поднимайте autovacuum_vacuum_cost_delay понемногу пока он не перестанет заметно влиять (впрочем больше 100ms я бы не советовал в любом случае).

--
Maxim Boguk
www.postgresql-consulting.ru
kamakama
Дата: 21.04.2015 08:50:01
Maxim Boguk,

Боюсь, что я не совсем корректно поставил вопрос. Есть некоторая система, которая содержит много текстов. Эти тексты анализируются по определенным правилам, которые меняются со временем. После каждого изменения - нужно обработать часть текстов. Обработка ведется не СУБД, а отдельной программой по типу BOINC - прочитал аргумент, посчитал, удалил старые результаты, записал новые. Тексты и результаты разбиты в партиции, объем связанных данных в одной партиции - 3-4 GB, то есть в теории в памяти могут быть размещены 2-3 партиции совершенно свободно (сервер выделеный).
На текущий момент обработчиков 6, причем каждый из них работает в 4 потока - всего 24 подключения. Загрузка CPU - 75-80%. При дальнейшем наращивании мощности начинают проскакивать ошибки подключения и взаимоблокировки. Особенность обработки такова, что такая загрузка может прийти в 24/7. Естесвенно, при включенном autovacuum (AV) в жестком режиме скорость обработки падает до неприемлемых величин + тормозятся еще и функции выборок для других пользователей.
Пока есть следующие мысли:
1) Оптимизировать планировщик задач, что бы он выдавал задание на обработку из разных партиций одновременно (2-3, что бы использовать буфер по полной). Это позволит снизить вероятность конкуренции на уровне доступа
2) В сочетании с п.1 перейти на PG 9.4 и использовать разогреватель кэша (http://habrahabr.ru/post/234909/#prewarm)
3) Выполнять VACUUM после каждой обработки (или перед что неважно) целиком или по мере обработки партиций для каждой партиции
4) Ломать голову над детальной настройкой AV - что бы он включался, но только при минимальной нагрузке в фоновом режиме. Но как я понял, явно указать это нельзя, только косвенно через его настройки. Только я не могу понять как.
kamakama
Дата: 21.04.2015 08:59:18
kamakama,

Для того, чтоб бы понимать объем записей. На обработку одного текста уходит порядка секунды, вместе с чтением самого текста, обработкой и записью результата. Стало быть, где-то в секунду идут 25-30 транзакций, содержащих DELETE, INSERT и UPDATE
kamakama
Дата: 21.04.2015 09:24:21
Maxim Boguk,

Насчет дисков - стоит RAID 10 и виртуальная машина. Сейчас тащим все это на физическую машину с двумя RAID 10, на одном разместим БД, на другом clog и xlog. Но принципиальные проблемы, описанные выше, все равно останутся
Maxim Boguk
Дата: 21.04.2015 10:18:52
kamakama,

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


Совершенно неестественно. Проекты куда больше чем ваш живут с всегда включенным autovacuum.
Он вообще не должен заметно мешать при правильной настройке базы на пару с нормальной дисковой системой (у вас в общем не так все плохо с ней).
От чего вы решили что вам именно autovacuum мешает? Вы изучали каких именно ресурсов базе не хватает?
Autovacuum вообще никому мешать не должен (и его отключение - к проблемам на пустом месте).
qwwq
Дата: 21.04.2015 10:26:13
kamakama,
распишите структуру вкратце

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



как кладутся "результаты" ? это "по записи на текст" ?
по много записей на текст ?
иное ?

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



и т.п. -- т.е. обрисуйте структуру хранения и структуры, в которых происходят обновления.

PPS очень полезно по возможности производить truncate вместо delete -- там, где он возможен.
а при частых апдейтах табличек с тостами -- целенаправленно реиндексить тосты (после чисток).
т.е. надо знать, как оно у вас распределено
kamakama
Дата: 21.04.2015 10:50:24
Maxim Boguk,

Я не спорю, что живут. Главное отличие от остальных проектов в том, что у меня нагрузка не размазана более-менее по времени и при этом нельзя выделить время в течение суток или недель с минимальной нагрузкой для оптимизации. Нагрузка может прийти 24\7
Производительность вычислителей достигла таких возможностей, что запись результатов стала самым узким местом, однако суммарная скорость обработки все равно не такая хорошая, как хотелось бы. При стандартной работе AV получается так, что он отследит изменения в таблицах autovacuum_vacuum_threshold (например) = 10000 (это произойдет через секунд 30 после начала работы с партицией), и потом начнет ее оптимизировать. На партицию уходит по 30 минут времени в среднем. А в это время ее все равно продолжают пользовать другие вычислители и довольно активно (расчет не кончен). Получается рост нагрузки, который заметно тормозит сам процесс расчетов. Вот я и пытаюсь подобрать наиболее оптимальный режим. Думаю над autovacuum_vacuum_scale_factor, поставить его в 0.5, что бы максимально снизить влияние на работу вычислителей. Или воспользоваться идеей п.3 в асинхронном режиме для каждой партиции.
tadmin
Дата: 21.04.2015 10:57:51
kamakama
Обработка ведется не СУБД, а отдельной программой по типу BOINC - прочитал аргумент, посчитал, удалил старые результаты, записал новые.

Вы придумали себе проблему - автовакуум хотите с ней бороться. Но, возможно, ваша проблема выше описана.
Не делает ли внешняя программа лишней работы?
Не перезаписывает ли по 10 раз в одной транзакции большие объемы данных, порождая мегатонны dead tuples?
Не следует ли хранить промежуточные данные в unlogged таблицах или вообще в памяти?
Нельзя ли внешнюю программу (или самые дорогостоящие операции) перенести в хранимые процедуры?