The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Минздрав РФ планирует перейти на PostgreSQL и СПО, opennews (??), 07-Авг-14, (0) [смотреть все] +2

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


59. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +1 +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 10:15 
>> Постгрес???!!! А когда это чудесное создание вакуумить будут, диспетчерские будут работать?
> Вакуум, начиная с 8-какого-то постгреса не блокирует операции с БД. Кроме того,
> нагрузка операции регулируется через опции конфигурации.

Как человек, таки вакуумящий 70Гб~ Pg-базу Zabbix-а (да, не 200Тб картинок) имю сказать следующее:

* "регулировки через опции" слегка переоценены: там в основном настройки автовакуума в духе, сколько надо подождать, чтобы база была в idle, прежде чем запускать автовакуум. И _никакой "регулировки нагрузки". Я, конечно, неосилятор или, может, пропустил что, не спорю, но Zabbix в базу _пишет постоянно и *авто*вакуума не случалость никогда. Не осилил тех опций - пускаю VACUUM ANALIZE (не FULL) руками "по крону" раз в 10 минут, так _быстрее_.

* Для VACUUM FULL базу-таки надо останавливать (клиентов отключать, то есть). Диски у меня "медленные" и мониторинг ентерпрайза останавливать раз в неделю-месяц на час-два-три не вариант. Пользую для - pg_repack, в пике до 4 ч. на таблицу (22Гб+12Гб индекс) _в онлайне_. Огородил семафорчиком, чтоб VACUUM выше одновременно с pg_repack-ом не пускать.

> Поэтому этой проблемы давно уже нет вовсе.

Ну-да, ну-да.

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

62. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 10:21 
>> Поэтому этой проблемы давно уже нет вовсе.
> Ну-да, ну-да.

"Той" проблемы нет вовсе, еще раз повторю. Вакуум сейчас можно делать онлайн речь шла об этом.
Что конкретно у вас не получается? VACUUM FULL вам для чего?


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

70. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 10:35 
>>> Поэтому этой проблемы давно уже нет вовсе.
>> Ну-да, ну-да.
> "Той" проблемы нет вовсе, еще раз повторю. Вакуум сейчас можно делать онлайн
> речь шла об этом.

Два разных вакуума. Один из них можно. И до версии 8, наверное, тоже было можно. 1 из 2ух.

> Что конкретно у вас не получается? VACUUM FULL вам для чего?

База пухнет и фрагментируется (~~не "линейный" порядок) => счётчики каких-то там biuffers/сек, к-во iops-ов и iowait-ы растут. Тормозить начнёт, _боюсь_, хотя и "помещается" в 96Гб RAM-ы.

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

74. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 10:39 
> База пухнет и фрагментируется (~~не "линейный" порядок) => счётчики каких-то там biuffers/сек,
> к-во iops-ов и iowait-ы растут. Тормозить начнёт, _боюсь_, хотя и "помещается"
> в 96Гб RAM-ы.

Ого, база помещается в кэш, а вы чего-то боитесь.
Если очень хочется снизить iops, делайте тогда cluster по таблицам по тем ключам, по которым в основном идет выборка.
vacuum full как раз к тормозам и приводит в конце-концов.
Хинт: в новых версиях постгреса vacuum full реализован через cluster только без указания конкретного индекса. Что дает богатую пищу для размышлений.
З.Ы. Не надо бояться неведомо чего. У меня в проме 400 гб набор баз, 150 юзеров, активных процессов постгреса ~ 60. Оперативной памяти в основном сервере 72 гб. Vacuum full не делаю, жалоб нет, чего и вам желаю.

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

69. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от karapuz2 (ok), 07-Авг-14, 10:32 
> Для VACUUM FULL базу-таки надо останавливать (клиентов отключать, то есть). Диски у меня "медленные" и мониторинг ентерпрайза останавливать раз в неделю-месяц на час-два-три не вариант.

У меня есть база где-то 150ГБ, фулл вакуум делаю раз в 2 месяца (наполняется база не слишком часто) - приноровился делать так: в конфиге ставлю fsync=no, рестартую постгрес и делаю фулл-вакуум - время сократилось с пары часов до 15 минут. затем обратно включаю fsync.

(если чо, постгресс старый 8й, система старая, обновляться не собираюсь)

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

71. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 10:35 
>> Для VACUUM FULL базу-таки надо останавливать (клиентов отключать, то есть). Диски у меня "медленные" и мониторинг ентерпрайза останавливать раз в неделю-месяц на час-два-три не вариант.
> У меня есть база где-то 150ГБ, фулл вакуум делаю раз в 2
> месяца (наполняется база не слишком часто) - приноровился делать так: в
> конфиге ставлю fsync=no, рестартую постгрес и делаю фулл-вакуум - время сократилось
> с пары часов до 15 минут. затем обратно включаю fsync.

У меня два вопроса:
1. Зачем вы делаете vacuum full?
2. Какая версия postgres?

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

75. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от karapuz2 (ok), 07-Авг-14, 10:41 
> У меня два вопроса:
> 1. Зачем вы делаете vacuum full?
> 2. Какая версия postgres?

система старая, постгрес 8й до-исправления-глюков-с-вакуумом. я не специализируюсь на этом, просто было принято решение не трогать старую систему и периодически ее профилактировать. Без вакуума база разрастается до неприличных размеров.


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

76. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +1 +/–
Сообщение от Forth (ok), 07-Авг-14, 10:43 
>> У меня два вопроса:
>> 1. Зачем вы делаете vacuum full?
>> 2. Какая версия postgres?
> система старая, постгрес 8й до-исправления-глюков-с-вакуумом. я не специализируюсь на
> этом, просто было принято решение не трогать старую систему и периодически
> ее профилактировать. Без вакуума база разрастается до неприличных размеров.

vacuum без full должен в вашем случае не урезать базу, но и не давать расти.
периодический full с fsync=off это офигеть как опасно, коллега. :) По краю ходите. :)

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

77. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  –1 +/–
Сообщение от karapuz2 (ok), 07-Авг-14, 10:48 
> vacuum без full должен в вашем случае не урезать базу, но и
> не давать расти.

спасибо

> периодический full с fsync=off это офигеть как опасно, коллега. :) По краю
> ходите. :)

)) там нормальный упс, но тоже спасибо. Буду знать. Решение принято. Отвечать не мне. Чем быстрее навернется, тем быстрее или обновим систему, или сольем клиента.


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

80. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 10:52 
Должен добавить: не все знают что vacuum хоть с full хоть без не трогает пустое место в индексах. Иногда надо делать reindex если стеснены в дисках, или просто "страшно" за рост БД.
Я лично очень редко, но делаю vacuum full, скажем раз в год, при проф работах или типа того, вместе с cluster и reindex. И то, считаю что делаю это не от жуткой необходимости, но из любви к прекрасному.

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

92. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от crypt (ok), 07-Авг-14, 12:12 
> Должен добавить: не все знают что vacuum хоть с full хоть без
> не трогает пустое место в индексах. Иногда надо делать reindex если
> стеснены в дисках, или просто "страшно" за рост БД.
> Я лично очень редко, но делаю vacuum full, скажем раз в год,
> при проф работах или типа того, вместе с cluster и reindex.
> И то, считаю что делаю это не от жуткой необходимости, но
> из любви к прекрасному.

Вступлю с этого места. При большом количестве UPDATE autovacuum может не воспрепятствовать распуханию индекса. Т.е. мы настраиваем autovacuum отдельно для таблицы, чтобы срабатывал после каждых 5-10 update (могу быть не точен, пишу по памяти), а index распухает _на_порядок_, что, естественно, не сказывается лучшим образом на производительности. Это безусловно проблема проектировки, но я согласен с

> Сообщение от Andrey Mitrofanov on 07-Авг-14, 10:15
> * "регулировки через опции" "слегка" переоценены
> * Для VACUUM FULL базу-таки надо останавливать

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

105. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 12:48 
> Вступлю с этого места. При большом количестве UPDATE autovacuum может не воспрепятствовать
> распуханию индекса. Т.е. мы настраиваем autovacuum отдельно для таблицы, чтобы срабатывал
> после каждых 5-10 update (могу быть не точен, пишу по памяти),
> а index распухает _на_порядок_, что, естественно, не сказывается лучшим образом на
> производительности. Это безусловно проблема проектировки, но я согласен с

Согласитесь, что большое кол-во update ситуация нехарактерная. Так бывает, да, но тут вакуум опять же не к месту, тут только reindex поможет.

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

95. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от crypt (ok), 07-Авг-14, 12:16 
насчет reindex. в случае, описанном выше, reindex, естественно, - это lock, со всеми вытекающими последствиями и это равносильно остановке сервиса.


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

106. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Аноним (-), 07-Авг-14, 12:49 
> насчет reindex. в случае, описанном выше, reindex, естественно, - это lock, со
> всеми вытекающими последствиями и это равносильно остановке сервиса.

Откуда вы лезете то? create index concurrently!

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

108. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 12:55 
> Откуда вы лезете то? create index concurrently!

На нагруженной на запись таблице можно долго-долго лепить такие индексы и безуспешно, увы.

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

116. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 13:16 
>> Откуда вы лезете то? create index concurrently!
> На нагруженной на запись таблице можно долго-долго лепить такие индексы и безуспешно, увы.

У меня на базе Zabbix-а _работает_. Правда не 9К NVPS, как в сферических презентациях, а 600 с небольшим. Достаточно "нагруженно на запись"? Не знаю.

Тот самый большой индекс из пред.примера в #59 на 12Гб создавался чуть больше часа, судя по графикам объёма диска под базой ~~> 20 минут создание, 10 минут копировангие(?), 35+ минут "докатка" пришедших за этот час изменений.

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

138. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от crypt (ok), 07-Авг-14, 16:51 
>>> Откуда вы лезете то? create index concurrently!
>> На нагруженной на запись таблице можно долго-долго лепить такие индексы и безуспешно, увы.
> У меня на базе Zabbix-а _работает_. Правда не 9К NVPS, как в
> сферических презентациях, а 600 с небольшим. Достаточно "нагруженно на запись"? Не
> знаю.
> Тот самый большой индекс из пред.примера в #59 на 12Гб создавался чуть
> больше часа, судя по графикам объёма диска под базой ~~> 20
> минут создание, 10 минут копировангие(?), 35+ минут "докатка" пришедших за этот
> час изменений.

Я тоже пишу про БД заббикса. У меня было ~900 nvps. Может, если у меня не было индекса размером 12Гб, то в примере #59 база не разбита на партиции? Соответственно, можно оптимизировать.

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

107. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 12:52 
> насчет reindex. в случае, описанном выше, reindex, естественно, - это lock, со
> всеми вытекающими последствиями и это равносильно остановке сервиса.

Что поделать, чудес нет. Зато reindex, если индекс не слеплен из всех мыслимых полей непонятно зачем, достаточно быстр и не часто нужен.

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

109. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 12:56 
> насчет reindex. в случае, описанном выше, reindex, естественно, - это lock, со
> всеми вытекающими последствиями и это равносильно остановке сервиса.

Вот [упрощённо, да] онлайновый REINDEX:

CREATE INDEX CONCURRENTLY $NEWIDX ON $копия-того-что-в-старом-индексе;
ALTER INDEX $OLDIDX RENAME TO ${OLDIDX}_0;
ALTER INDEX $NEWIDX RENAME TO $OLDIDX;
DROP INDEX ${OLDIDX}_0;

И кстати, CREATE INDEX CONCURRENTLY, как ни странно, вымывает сис.кеши больше [пускаемого _часто_] VACUUM-а. Читает и сортирует всю таблицу, а vac., видимо, понимает-отличает только изменившиеся с пред.раза части стораджа.

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

110. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Forth (ok), 07-Авг-14, 13:02 
> Вот [упрощённо, да] онлайновый REINDEX:
> CREATE INDEX CONCURRENTLY $NEWIDX ON $копия-того-что-в-старом-индексе;
> ALTER INDEX $OLDIDX RENAME TO ${OLDIDX}_0;
> ALTER INDEX $NEWIDX RENAME TO $OLDIDX;
> DROP INDEX ${OLDIDX}_0;

Перед тем, как удалять старый индекс, неплохо бы проверить, что новый не кривой :)

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

113. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 13:12 
>>[упрощённо, да]
>> DROP INDEX ${OLDIDX}_0;
> Перед тем, как удалять старый индекс, неплохо бы проверить, что новый не
> кривой :)

GOTO BEGIN;)

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

142. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от crypt (ok), 07-Авг-14, 17:00 
>> насчет reindex. в случае, описанном выше, reindex, естественно, - это lock, со
>> всеми вытекающими последствиями и это равносильно остановке сервиса.
> Откуда вы лезете то? create index concurrently!

Это opennet так влияет на людей, что они начинают писать неграмотно, хамить и считать себя самыми умными? Ну да, анонимность портит людей.

> Вот [упрощённо, да] онлайновый REINDEX:

А что при этом будет со статистикой по использованию этого index'a?


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

145. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 07-Авг-14, 17:35 
>> Вот [упрощённо, да] онлайновый REINDEX:
> А что при этом будет со статистикой по использованию этого index'a?

С 0 пойдёт, индекс-то новый, фактически.

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

181. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от XoRe (ok), 07-Авг-14, 23:12 
> Как человек, таки вакуумящий 70Гб~ Pg-базу Zabbix-а (да, не 200Тб картинок) имю
> сказать следующее:

Очень рекомендую:
http://www.zabbix.org/wiki/Category:Table_partitioning
Сами пользуемся этим:
http://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_par...
И выключили нафиг housekeeper и autovacuum.
Помогает с базой 150+ГБ.

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

187. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от Andrey Mitrofanov (?), 08-Авг-14, 09:49 
> Очень рекомендую:
>wiki/Category:Table_partitioning
> Сами пользуемся этим:
>howto/zabbix2_postgresql_partitioning

Спасибо. //Надо, конечно, но стрёмно как-то. Пока нахожу опроавдания не делать:/

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

202. "Минздрав РФ планирует перейти на PostgreSQL и свободное ПО"  +/–
Сообщение от XoRe (ok), 08-Авг-14, 23:17 
> Спасибо. //Надо, конечно, но стрёмно как-то. Пока нахожу опроавдания не делать:/

Тоже вариант)

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

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

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




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

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