ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
15 сообщений из 15, страница 1 из 1
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852111
pg_newbie_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pg_newbie_user
Гость
Версия Postgresql 9.1

Необходимо узнать за счёт чего так быстро прирастает база?
смотрю сегменты в pg_class, но это мало помогает.

Сегодня утром база 100Гб, в обед уже 110Гб.
auto_vacuum включен, из pg_stat_user_tables видно, что последний раз отрабатывал сегодня

Хочется понять какая именно таблица или индекс выросли на 10 Гб.
спасибо!
...
Рейтинг: 0 / 0
12.01.2015, 12:15
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852123
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
/\/\/\/\/\/\
Гость
pg_newbie_user,

Собирайте данные по размеру всех объектов в отдельную таблицу с установленной периодичностью (можно в другую БД и другой сервер). Потом анализируйте статистику.

autovacuum в общем случае не сжимает таблицу. То есть объем таблицы уменьшается в редких случаях, когда зачищается хвост таблицы.

Если отработал "сегодня" - есть подозрение на неоптимальную его настройку. Значение обычно ближе к "отработал x раз за последний час".
...
Рейтинг: 0 / 0
12.01.2015, 12:28
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852142
pg_newbie_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pg_newbie_user
Гость
/\/\/\/\/\/\pg_newbie_user,

Собирайте данные по размеру всех объектов в отдельную таблицу с установленной периодичностью (можно в другую БД и другой сервер). Потом анализируйте статистику.

autovacuum в общем случае не сжимает таблицу. То есть объем таблицы уменьшается в редких случаях, когда зачищается хвост таблицы.

Если отработал "сегодня" - есть подозрение на неоптимальную его настройку. Значение обычно ближе к "отработал x раз за последний час".

За последний час база выросла на 6 Гб.

Могли бы вы любезно подсказать, какими запросами осуществить данный сбор данных?
приведёт ли это к полному сканированию таблиц или брать значения уже собранной ранее статистики?
как это можно сделать?

спасибо!
...
Рейтинг: 0 / 0
12.01.2015, 12:49
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852165
hattifattener
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hattifattener
Участник
pg_newbie_user,

Для начала проделайте элементарное:

Код: sql
1.
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;



Повторять раз в 5 минут до понимания тенденции.
...
Рейтинг: 0 / 0
12.01.2015, 13:05
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852168
hattifattener
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hattifattener
Участник
pg_newbie_user,

Затем прочитайте тут и тут и собирайте более подробную статистику через pg_total_relation_size.
...
Рейтинг: 0 / 0
12.01.2015, 13:09
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852193
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tadmin
Участник
У вас нет долгих транзакций? От них база может сильно распухать.
Код: plsql
1.
SELECT (now() - query_start) as TTT_______,query, * FROM pg_stat_activity WHERE state <> 'idle' and   datname = current_database() order by 1 desc
...
Рейтинг: 0 / 0
12.01.2015, 13:29
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852218
hattifattener
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hattifattener
Участник
pg_newbie_user,

А производные ловить как-то так:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table pagestat ( moment timestamptz, relname name, relpages integer );

insert into pagestat select now(), relname , relpages from pg_class; -- регулярно

select moment,relname, dr/ds as diff from (
  select 
    moment, relname, 
    (lead(relpages) over (partition by relname order by moment) - relpages) as dr, 
    (extract(epoch from (lead(moment) over  (partition by relname order by moment) - moment))) as ds 
  from pagestat 
) q where dr notnull and ds notnull and ds > 0 order by diff desc;
...
Рейтинг: 0 / 0
12.01.2015, 13:48
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852219
hattifattener
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hattifattener
Участник
pg_newbie_user,

А производные ловить как-то так:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table pagestat ( moment timestamptz, relname name, relpages integer );

insert into pagestat select now(), relname , relpages from pg_class; -- регулярно

select moment,relname, dr/ds as diff from (
  select 
    moment, relname, 
    (lead(relpages) over (partition by relname order by moment) - relpages) as dr, 
    (extract(epoch from (lead(moment) over  (partition by relname order by moment) - moment))) as ds 
  from pagestat 
) q where dr notnull and ds notnull and ds > 0 order by diff desc;
...
Рейтинг: 0 / 0
12.01.2015, 13:48
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852250
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
/\/\/\/\/\/\
Гость
hattifattenerpg_newbie_user,

Для начала проделайте элементарное:

Код: sql
1.
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;



Повторять раз в 5 минут до понимания тенденции.

Кстати, еще раз более внимательно прочитал RTFM про relpages.
Оказывается, это ОЖИДАЕМОЕ значение. Нужно быть осторожным.

авторSize of the on-disk representation of this table in pages (of size BLCKSZ). This is only an estimate used by the planner. It is updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX.

Поэтому я бы опирался на pg_total_relation_size .
...
Рейтинг: 0 / 0
12.01.2015, 14:17
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852792
pg_newbie_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pg_newbie_user
Гость
/\/\/\/\/\/\hattifattenerpg_newbie_user,

Для начала проделайте элементарное:

Код: sql
1.
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;



Повторять раз в 5 минут до понимания тенденции.

Кстати, еще раз более внимательно прочитал RTFM про relpages.
Оказывается, это ОЖИДАЕМОЕ значение. Нужно быть осторожным.

авторSize of the on-disk representation of this table in pages (of size BLCKSZ). This is only an estimate used by the planner. It is updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX.

Поэтому я бы опирался на pg_total_relation_size .

Всем добрый день!

Я выяснил, что у меня прирост идёт за счёт pg_largeobject. Прирост 1 Гб за 1 час.
last_autovacuum для pg_largeobject отсутствует...

что можно сделать в данной ситуации с pg_largeobject? я так понял там хранятся BLOB, их можно как-то ужать?
...
Рейтинг: 0 / 0
13.01.2015, 09:45
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852828
pg_newbie_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pg_newbie_user
Гость
нашёл вот примерное решение,

http://www.postgresql.org/message-id/23124.1264204910@sss.pgh.pa.us]http://www.postgresql.org/message-id/23124.1264204910@sss.pgh.pa.us


Код: plsql
1.
2.
3.
1. REINDEX TABLE pg_largeobject;
2. VACUUM pg_largeobject;
3. VACUUM FULL pg_largeobject;



но проблема в том, что reindex и vacuum full требуют эксклюзивной блокировки таблицы, что приведет к простою.
Возможен ли вариант без эксклюзивной блокировки таблицы?

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

как можно ещё решить данный вопрос?
...
Рейтинг: 0 / 0
13.01.2015, 10:12
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852890
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
pg_newbie_user/\/\/\/\/\/\пропущено...


Кстати, еще раз более внимательно прочитал RTFM про relpages.
Оказывается, это ОЖИДАЕМОЕ значение. Нужно быть осторожным.

пропущено...


Поэтому я бы опирался на pg_total_relation_size .

Всем добрый день!

Я выяснил, что у меня прирост идёт за счёт pg_largeobject. Прирост 1 Гб за 1 час.
last_autovacuum для pg_largeobject отсутствует...

что можно сделать в данной ситуации с pg_largeobject? я так понял там хранятся BLOB, их можно как-то ужать?

для начала покажите что показывает на вашей базе:
select * from pg_stat_all_tables where relname='pg_largeobject';
вполне может быть что там и сжимать то нечего и вы просто некорректно large objects используете.
...
Рейтинг: 0 / 0
13.01.2015, 11:05
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38852896
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
я даже скорее всего знаю что именно вы не учли и почему у вас все пухнет но хотелось бы ваши запросы работы с LO увидеть

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
13.01.2015, 11:14
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38853355
pg_newbie_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pg_newbie_user
Гость
Maxim Bogukpg_newbie_userпропущено...


Всем добрый день!

Я выяснил, что у меня прирост идёт за счёт pg_largeobject. Прирост 1 Гб за 1 час.
last_autovacuum для pg_largeobject отсутствует...

что можно сделать в данной ситуации с pg_largeobject? я так понял там хранятся BLOB, их можно как-то ужать?

для начала покажите что показывает на вашей базе:
select * from pg_stat_all_tables where relname='pg_largeobject';
вполне может быть что там и сжимать то нечего и вы просто некорректно large objects используете.

Код: plsql
1.
2.
3.
4.
 relid | schemaname |    relname     | seq_scan | seq_tup_read |  idx_scan   | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum |        last_autovacuum        | last_analyze |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count
-------+------------+----------------+----------+--------------+-------------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------+-------------------------------+--------------+-------------------------------+--------------+------------------+---------------+-------------------
  2613 | pg_catalog | pg_largeobject |        1 |       886005 | 14195595411 |   15346520502 | 312049499 |         0 | 266696723 |             0 |  297214307 |  136663001 |             | 2015-01-11 03:22:57.832844+03 |              | 2015-01-11 06:07:42.830167+03 |            0 |               11 |             0 |                26
(1 row)
...
Рейтинг: 0 / 0
13.01.2015, 16:39
| Ответить | Цитировать | Написать  
Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
    #38853532
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
pg_newbie_userMaxim Bogukпропущено...


для начала покажите что показывает на вашей базе:
select * from pg_stat_all_tables where relname='pg_largeobject';
вполне может быть что там и сжимать то нечего и вы просто некорректно large objects используете.

Код: plsql
1.
2.
3.
4.
 relid | schemaname |    relname     | seq_scan | seq_tup_read |  idx_scan   | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum |        last_autovacuum        | last_analyze |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count
-------+------------+----------------+----------+--------------+-------------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------+-------------------------------+--------------+-------------------------------+--------------+------------------+---------------+-------------------
  2613 | pg_catalog | pg_largeobject |        1 |       886005 | 14195595411 |   15346520502 | 312049499 |         0 | 266696723 |             0 |  297214307 |  136663001 |             | 2015-01-11 03:22:57.832844+03 |              | 2015-01-11 06:07:42.830167+03 |            0 |               11 |             0 |                26
(1 row)



сделайте
create extension pgstattuple;
и покажите что выводит
select * from pgstattuple('pg_largeobject');

основная теория на данный момент - в некоторых или во всех местах вы забываете делать lo_unlink при удалении соответствующей записи.
почитайте для начала:
http://www.postgresql.org/docs/9.2/static/lo-interfaces.html
вот это особенно важно для понимания и использования LO: http://www.postgresql.org/docs/9.2/interactive/lo.html
и http://www.postgresql.org/docs/9.2/interactive/vacuumlo.html

Если же вы уверены что у вас на этот счет все впорядке - то значит просто пишется столько вот large objects в базу.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
13.01.2015, 18:25
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Аудит прироста базы данных. Узнать за счёт чего растёт база на уровне сегментов
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38852218&tid=1998246]:
 0ms
get settings:
 6ms
get forum list:
 12ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 152ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 2ms
others: 209ms
total:  448ms
созд. / загр.: 448ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]