VY
Yaroslav Schekin
А я бы отключал. Начинал бы с этого, более того.
увы, там где проблемы с вакуумом, там и с железом проблемы. на моём опыте.
Size: a a a
2021 March 18
AL
Yaroslav Schekin
А я бы отключал. Начинал бы с этого, более того.
а можете развернуто аргументировать свою позицию?
YS
увы, там где проблемы с вакуумом, там и с железом проблемы. на моём опыте.
Нет, если там существенные проблемы с I/O, но есть maintenance windows, то возможны варианты, да.
s
Yaroslav Schekin
А можете пояснить для незнакомых с MySQL — там это как-то "перебивается" на уровне отдельных сессий?
И насколько надёжно Вам нужно в PostgreSQL?
И насколько надёжно Вам нужно в PostgreSQL?
Оно "Closes all open tables. New tables are only allowed to be opened with read locks until an UNLOCK TABLES is given"
s
Ну то есть сливает таблицу на диск и берёт обычный read lock, как это и выглядит.
YS
а можете развернуто аргументировать свою позицию?
Пока вкратце:
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
VY
Yaroslav Schekin
Пока вкратце:
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
я предпочитаю в таких ситуациях:
- настраивать вакуум как следует
- руками вакуумить основные проблемные таблицы
- настраивать вакуум как следует
- руками вакуумить основные проблемные таблицы
s
Yaroslav Schekin
Пока вкратце:
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
"The problem is that if you slow down autovacuum to reduce I/O, you can get into a death spiral where less vacuuming means more bloat, which means more I/O, which means less vacuuming." (RhodiumToad)
Условный sleep(0) выглядит не очень в случае отсутсвия работы как-то. Будет часто дёргаться, ничего не находить и снова уходить спать на ноль секунд. Там же нет специального хитрого режима для такой ситуации?
s
Я бы тогда чисто интуитивно ставил бы хотя бы 1 секунду. Но только потому что этот вопрос шедулинга при экстремальных значениях интервала вообше не изучал
YS
я предпочитаю в таких ситуациях:
- настраивать вакуум как следует
- руками вакуумить основные проблемные таблицы
- настраивать вакуум как следует
- руками вакуумить основные проблемные таблицы
Так вот "как следует" с моей точки зрения — это отключить задержку. ;)
Т.е. "вытащите" Вы эту базу один раз — она опять "провалится", и т.п. Зачем кругами ходить?
Т.е. "вытащите" Вы эту базу один раз — она опять "провалится", и т.п. Зачем кругами ходить?
VY
Условный sleep(0) выглядит не очень в случае отсутсвия работы как-то. Будет часто дёргаться, ничего не находить и снова уходить спать на ноль секунд. Там же нет специального хитрого режима для такой ситуации?
по умолчанию стоит
vacuum_cost_delay = 0. я не думаю, что там дёргают sleep при нулевой задержкеVY
Yaroslav Schekin
Так вот "как следует" с моей точки зрения — это отключить задержку. ;)
Т.е. "вытащите" Вы эту базу один раз — она опять "провалится", и т.п. Зачем кругами ходить?
Т.е. "вытащите" Вы эту базу один раз — она опять "провалится", и т.п. Зачем кругами ходить?
вы исходите из того, что у вас есть окно. я из того, что я на живой базе должен её в чувство привести
YS
Я бы тогда чисто интуитивно ставил бы хотя бы 1 секунду. Но только потому что этот вопрос шедулинга при экстремальных значениях интервала вообше не изучал
Т.е. Вы хотите намного увеличить задержку, по сравнению с default? ;)
YS
вы исходите из того, что у вас есть окно. я из того, что я на живой базе должен её в чувство привести
Нет, я как раз исхожу из того, что окон нет.
Если "живую" базу не начать интенсивно "приводить в чувство", она "свалится в штопор"... the end. ;(
Если "живую" базу не начать интенсивно "приводить в чувство", она "свалится в штопор"... the end. ;(
VY
Yaroslav Schekin
Нет, я как раз исхожу из того, что окон нет.
Если "живую" базу не начать интенсивно "приводить в чувство", она "свалится в штопор"... the end. ;(
Если "живую" базу не начать интенсивно "приводить в чувство", она "свалится в штопор"... the end. ;(
я считаю, что в чувствуо иначе надо приводить, без таких жёестких телодвижений. потом — да, можно.
YS
я считаю, что в чувствуо иначе надо приводить, без таких жёестких телодвижений. потом — да, можно.
Просто мне это не кажется таким уж жёстким (особенно, если иметь в виду альтернативу).
А что Вы делаете вместо этого, если подробнее?
А что Вы делаете вместо этого, если подробнее?
s
Yaroslav Schekin
Т.е. Вы хотите намного увеличить задержку, по сравнению с default? ;)
Опять же я про конкретную обсуждаемую ситуацию с уже каким-то ненулевым значением. А то поставят гордо ноль и система ввода-вывода перегрузится до неюзабельности.
YS
Опять же я про конкретную обсуждаемую ситуацию с уже каким-то ненулевым значением. А то поставят гордо ноль и система ввода-вывода перегрузится до неюзабельности.
Поставлю, да. Потому что если не поставить, система ввода-вывода "перегрузится до неюзабельности" от кое-чего другого.
Проблема-то в том, что это всё происходит... не в вакууме. ;)
Проблема-то в том, что это всё происходит... не в вакууме. ;)
s
Если изначально стоит ноль, то у вас вряд ли может накопиться мусор на многие часы чистки вперёд. Если он копится в такой конфигурации, то у вас уже какие-то проблемы с железом.
GT
Привет!
подскажите, в таблице jiraissue, примерно 700к записей,
а fileattachment - 870к.
следующий запрос выполняется более получаса
подскажите, какой параметр отвечает на подзапросы. Хочется именно ускорить подзапросы
подскажите, в таблице jiraissue, примерно 700к записей,
а fileattachment - 870к.
следующий запрос выполняется более получаса
select count(*) from fileattachment where issueid not in (select id from jiraissue);
подскажите, какой параметр отвечает на подзапросы. Хочется именно ускорить подзапросы