Oleg NNNМожно ли хранить и эффективно искать храня в PostgreSQL 1ТБ данных? а 5ТБ? а 10ТБ ?

Какая должна быть архитектура ?

хранить легко вообще...

искать - смотря что хранить в ней и как искать... я знаю задачки где и 100MB база в памяти будет тормозить...
с другой стороны выборки по primary key + нормальная дисковая подсистема и 10TB не проблема...
т.е. тут надо четкое понимание задачи...

128-512GB памяти
+ raid10 на intel s-3700 SSD нужного обьема (хотя бы для индексов... лучше для все базы)
+ нормальный сервер
+ (и это главное) нормальная архитектура базы и разумные запросы к ней

в общем для многих задач на 1-10TB будет без проблем тянуть... базы под терабайт у меня на хозяйстве есть и в общем проблем не доставляют

для более конкретного ответа недостаточно информации.

--
www.postgresql-consulting.ru

eddie,

C бюджетными дисками проблемы две:

1)Сильно сниженный максимальный обьем записи (10-10000 раз меньше чем intel x3700... смотрите спецификации конкретных моделей)
2)Непредсказуемые и неровные задержки на запись

Итого если у вас база readonly или почти readonly (небольшой обьем записи) - тогда на бюджетных моделях тоже все будет работать без проблем. Если у вас обьем записи большой в базу то вполне может быть ситуация когда вам прийдется ваши диски менять раз в полгода-год.

Бюджетным дискам еще может помочь вынос pg_xlog на SAS диски (это снизит обьем записи на SSD от 2x минимум до 100раз и соотвественно продлит время работы до замены).

У меня были преценденты когда бюджетные диски не работали на базе больше 4х месяцев... после замены на intel s3700 - 2 года полет нормальный.

--
Максим Богук
postgresql-consulting.ru

eddieMaxim Bogukeddie,

C бюджетными дисками проблемы две:

1)Сильно сниженный максимальный обьем записи (10-10000 раз меньше чем intel x3700... смотрите спецификации конкретных моделей) ну берём s3700:
200GB: 3.65 PBW

у более дешёвого 600 pro на 400GB:
Суммарное количество записанных терабайт (TBW) при корпоративной рабочей нагрузке в течение гарантийного периода: 1190
(на последовательной записи и вовсе 2630, непонятно какой именно показатель у intel указан).

так что разница есть, но она не фатальная.

2)Непредсказуемые и неровные задержки на запись

Итого если у вас база readonly или почти readonly (небольшой обьем записи) - тогда на бюджетных моделях тоже все будет работать без проблем. Если у вас обьем записи большой в базу то вполне может быть ситуация когда вам прийдется ваши диски менять раз в полгода-год. ну всё-таки в мире бывает не только чёрное и белое ;)
между "readonly база" и "менять диски раз в полгода" есть всё-таки промежуточные варианты.

тут и ресурс дисков не так важен будет, и запись не таким плотным потоком (то есть проблем не будет с "плавающими" задержками)

1)вы сравниваете 400GB vs 200GB модели... это не совсем честно...write endurance линейно от обьема диска растет... у 400GB Intel write endurance 7.3PBW что дает разницу уже раз в 6 и это уже может быть заметно...

2)600 pro - не то чтобы ноутбучный/end-user SSD (а когда спрашивают про подешевле обычно ставят самые дешевые что нашли на price.ru.

Я и не писал про черное и белое... я просто описал проблемы на другом конце линейки... а решать где ваши конкретные модели SSD в линейке находятся (и где по обьему записи находится ваша база) - это дело ваше.

Так как если взять какой то samsung 840 EVO - так они вообще write endurance не дают с формулировкой "840 EVO is not validated for data center usage." и я видел как они сыпались под базой. Неофициальные данные дают для модели 250GB где 50TBW до отказа. А это уже очень большая разница. (почему то хостеры именно их любят ставить... наверное потому что самые дешевые).

inforseРебят, хотелось бы оживить тему. Актуальная проблема.

База валиться в случае накопления информации больше 40 гб, если не обслуживать её каждый день.

А сейчас планируется база свыше 1 Тб, не подскажете в какую сторону смотреть? Как у вас настроены конфиги, под базу с большими объемами? Как выполняется обслуживание такой базы, ведь индексы при частых изменениях таблиц будут накапливаться с быстрой скоростью.

в сторону хорошей дисковой подсистемы (такая база - диски диски и еще раз диски)...
или ssd only
или 16+ SAS 15000 rpm+нормальный рейд контроллер
+ достаточно аггресивный autovacuum
+ 128-256 GB памяти...
смотря конечно что с этой базой делать но вообще проблем быть не должно

PS: "База валиться в случае накопления информации больше 40 гб, если не обслуживать её каждый день."
это как??? 500GB базы на хозяйстве рестартуются по 2-4 раза в год для минорных обновлений и все... в жизни ничего на хорошем железе не падало.

--Maxim Boguk
www.postgresql-consulting.ru

inforseMaxim BogukPS: "База валиться в случае накопления информации больше 40 гб, если не обслуживать её каждый день."
это как??? 500GB базы на хозяйстве рестартуются по 2-4 раза в год для минорных обновлений и все... в жизни ничего на хорошем железе не падало.

--Maxim Boguk
www.postgresql-consulting.ru

База оперативная, в секунду проходит много транзакций. Размер за сутки вырастает где-то на 10 гб. Если вручную не обслужить (vacuum + reindex) то через пару дней валиться. В логах возникает ошибка "ошибка сигментации получен сигнал 11" и сервер уходит в режим восстановления.
Соответственно после операций очистки база становиться своего размера. Но как её держать в актуальном размере при большом росте размеров индексов и "пустых" строк которые каждую секунду удаляются и инсертятся? Без остановки работы.

У вас или сбойный сервер (скорее всего сбойная память),
или старая версия postgres с каким то из багов который такое может вызывать,
или неправильно настроен сервер (по памяти)...

Практически segfault это одно из первых двух, редко третье когда но тогда обычно OOM вылетает который может завершится segfault при сильном невезении но обычно этого не происходит.

Никогда ни на одной базе не надо было не то что ежедневный а вообще когда-либо ручные vacuum+reindex пускать (а у нас на поддержке больше сотни postgresql серверов с разными базами до 700GB размером).

PS: включите сбор корок и посмотрите gdb backtrace может что то прояснится.

--Maxim Boguk
www.postgresql-consulting.ru

inforseMaxim BogukУ вас или сбойный сервер (скорее всего сбойная память),
или старая версия postgres с каким то из багов который такое может вызывать,
или неправильно настроен сервер (по памяти)...

Практически segfault это одно из первых двух, редко третье когда но тогда обычно OOM вылетает который может завершится segfault при сильном невезении но обычно этого не происходит.

Никогда ни на одной базе не надо было не то что ежедневный а вообще когда-либо ручные vacuum+reindex пускать (а у нас на поддержке больше сотни postgresql серверов с разными базами до 700GB размером).

PS: включите сбор корок и посмотрите gdb backtrace может что то прояснится.

--Maxim Boguk
www.postgresql-consulting.ru

У нас стоит сертифицированая в МО РФ операционная система с версией PostgreSQL от 8.3 до 9.1. Базы разрастаются очень быстро, все идет в режиме онлайн, информация постоянно обновляется. Серверов много, следили за другими серверами, тоже самое. Если вручную не чистить база валиться.

Пробовали настраивать автовакуум на самые часто используемые таблицы. Не помогло. вот пример конфига автовакуума

Автовакуум#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------

autovacuum = off # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
autovacuum_max_workers = 2 # max number of autovacuum subprocesses
autovacuum_naptime = 20min # time between autovacuum runs
autovacuum_vacuum_threshold = 10000 # min number of row updates before
# vacuum
autovacuum_analyze_threshold = 10000 # min number of row updates before
# analyze
autovacuum_vacuum_scale_factor = 0.1 # fraction of table size before vacuum
autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
autovacuum_freeze_max_age = 100000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit


Ну сейчас он отключен естественно, он еще притормаживал базу сам по себе, что для нас критично достаточно.

В результате приходиться "чистить" вручную... Есть ли какие нибудь способы выхода из ситуации?

ничего более ужасного для postgresql чем отключенный autovacuum придумать нельзя... его наоборот предельно аггресивно настраивать надо
(причем на все таблицы
autovacuum_max_workers = 10 # max number of autovacuum subprocesses
autovacuum_naptime = 1s # time between autovacuum runs
autovacuum_vacuum_threshold = 50 # min number of row updates before
autovacuum_analyze_threshold = 10 # min number of row updates before
autovacuum_vacuum_scale_factor = 0.02 # fraction of table size before vacuum
autovacuum_analyze_scale_factor = 0.02 # fraction of table size before analyze
autovacuum_vacuum_cost_delay = 5ms # default vacuum cost delay for
)...
а если от него тормозит база - см то что я писал про нормальные диски... если у вас дисковая подсистема не дает хотя бы 1000IOPS стабильно - базе на ней делать нечего.

PS: чем чаще autovacuum работает чем ДЕШЕВЛЕ каждый его запуск и тем меньше он мешает остальной базе. Поэтому надо не реже а чаще запускать.

PPS: ну и естественно следить чтобы открытые транзакции не оставались часами (а тем более сутками). Это второй надежный метод как сделать PostreSQL больно.

--Maxim Boguk
www.postgresql-consulting.ru

inforse,

1)линтер это вообще не постгрес а глючнай устаревшая и пачтеный левой ногой форк... там проблем и ошибок своих кучи... не говоря уж о том что 8.3 out of support уже года два и жаловаться на то что там что то не работает или работает не так как надо смысла мало... никто не поможет... т.е. это уже лично ваши проблемы и проблемы вашей организации...

2)при автовакуме реиндексация не происходит но осовобождается место в индексе под reuse по мере его появления...т.е. если индекс уже распух - autovacum ему не поможет... но при нормальных настройках autovacuum (и отсутствии длинных часовых и более транзакций) индексы не пухнут... (т.е. нормальное состояние индекса это где то на 30% больше чем сразу после reindex и так надо).

3)" Как проходит механика удаления старых версий записей в таблице во время очистки? Какую логику выбирает Postgres, и можно ли вручную указывать ему какие именно старые версии строк удалять?" - вопроса не понял... почитайте про mvcc в postgres и вам станет понятнее как оно работает. Удаляются те версии строк которые не видны самым старым открытым транзакциям. А зачем вам собственно удалять не все старые версии строк а некоторые только (так только тяжелее получается.. всеравно каждый раз записывать целые 8kb страницы).

PS: если даже при настроенном autovacuum у вас таблицы и индексы постоянно пухнут - вам надо добавить мониторинг и отстрел долгих транзакций... на серьезно нагруженной OLTP базе даже открытые транзакции длинной в 5 минут строго не рекомендуются (не говоря о часовых или забытых на несколько суток).

PPS: еще полезно посмотреть на настройки checkpoints... если они у вас каждую минуту (или даже каждые 5 минут идут) - так делать не надо и надо настраивать... идеальный (на мой взгляд) вариант 60 минут checkpoint_timeout и достаточное количество сегментов чтобы в него всегда укладываться.

inforseMaxim Boguk,

Максим, скажите пожалуйста, в вашей подписи указан сайт. Я на него зашел, задал пару вопросов, на мыло, и с сайта. Но ответа так и не поступило. Сайт живой? Организация работает?

все работает.. когда вы отправляли письма и форму с сайта?
я первый раз о этой проблеме слышу

qwwqinforse отвалилась с сигналом 11 :(

дилетански думаю -- ошибка адресации в c .
как вариант -- выели какой-то ограниченный системный ресурс.

вопрос к знатокам -- возможно ли, а если да, то какой ?

70% - сбойное железо
10% - ОС чудит
20% - хитрое сочетание out of memory в какой то специфической ситуации и настройках

в общем надо сначала попробовать включить сбор корок в ядре...
потом посмореть gdb bt где оно вылетело и почему и дальше думать
до этого - гадание на кофейной гуще...

просто так postgres не падает... тем более в таких примитивных ситуациях

Maxim BogukinforseMaxim Boguk,

Максим, скажите пожалуйста, в вашей подписи указан сайт. Я на него зашел, задал пару вопросов, на мыло, и с сайта. Но ответа так и не поступило. Сайт живой? Организация работает?

все работает.. когда вы отправляли письма и форму с сайта?
я первый раз о этой проблеме слышу

ага это родной гугл чудит и в спам все отправил...
ответим в течении 2х часов

извините за неоперативность