powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Vacuum Full без полного лока таблицы
25 сообщений из 154, страница 3 из 7
Vacuum Full без полного лока таблицы
    #37018804
905
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WarstoneДелают VACUUM FULL

Таблица на диске маленькая, так как произошла "релокация" данных с конечных страниц в начальные.

Так как таблица стала меньше, то она эффективнее ложится в файловый кеш (ОС) и выборки идут быстрее.


Получается, что если из таблицы удалить половину строк (и не делать пока vacuum full), а затем с ней производить работу, то в памяти(кэше) будет бессмысленно болтаться удаленная половина таблицы ?
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37018926
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
905Получается, что если из таблицы удалить половину строк (и не делать пока vacuum full), а затем с ней производить работу, то в памяти(кэше) будет бессмысленно болтаться удаленная половина таблицы ?Не совсем так. Эта информация МОЖЕТ быть в кеше (например когда ее "вот прям щас удалили"), но индексы, насколько я помню, будут гораздо больше, равно как и общее количество страниц и, как следствие, поиск необходимой страницы (как в кеше, так и на диске) будет больше. Хотя, конечно, у меня нет 100% уверенности в предыдущем высказывании, так как я код не смотрел, но по ощущениям - если в таблице много пустого места, то с ней "тяжелее" работать.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37019194
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
905WarstoneДелают VACUUM FULL

Таблица на диске маленькая, так как произошла "релокация" данных с конечных страниц в начальные.

Так как таблица стала меньше, то она эффективнее ложится в файловый кеш (ОС) и выборки идут быстрее.


Получается, что если из таблицы удалить половину строк (и не делать пока vacuum full), а затем с ней производить работу, то в памяти(кэше) будет бессмысленно болтаться удаленная половина таблицы ?
по-любому информация с диска читается страницами. Если в каждой странице будет 90% мусора, то будет полная опа. Если вы сделаете VACUUM FULL. Эта опа переместиться из таблицы в индексы и будет опа, но уже с другой стороны :)
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37019591
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
web_foxпо-любому информация с диска читается страницами. Если в каждой странице будет 90% мусора, то будет полная опа. Если вы сделаете VACUUM FULL. Эта опа переместиться из таблицы в индексы и будет опа, но уже с другой стороны :)В индексах она будет меньше.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37019651
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Warstoneweb_foxпо-любому информация с диска читается страницами. Если в каждой странице будет 90% мусора, то будет полная опа. Если вы сделаете VACUUM FULL. Эта опа переместиться из таблицы в индексы и будет опа, но уже с другой стороны :)В индексах она будет меньше.

Предполагая что индексы были не распухшие при VF их размер строго удвоится. Если распухшие уже то они могут даже и не вырости вообще. На самом деле кроме primary key/unique constraints распухшие индексы лечатся достаточно легко и бескровно в отличии от упаковки самой таблицы.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37019833
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

а почему с primary key хуже дела обстоят?
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37020092
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eddieMaxim Boguk,

а почему с primary key хуже дела обстоят?

Потому что с обычными индексами вместо блокируюшего таблицу reindex можно поступить следующим образом:

CREATE INDEX CONCURRENTLY applicant_adv_subscription_sent_date_key_new ON applicant_adv_subscription USING btree (sent_date);
DROP INDEX public.applicant_adv_subscription_sent_date_key;
ALTER INDEX public.applicant_adv_subscription_sent_date_key_new RENAME TO applicant_adv_subscription_sent_date_key;

пересоздав индекс без блокировки таблицы.

А вот с primary key этот фокус до выхода версии 9.1 не пройдет (в 9.1 обещают возможность уже созданный индекс обьявить как primary key).
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37021280
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, человеческое спасибо что небезразличны, разработали и открыли полезную вещь.
А автоматическая неблокирующая прозрачная оптимизация таблиц и индексов уже давно напрашивается в стандартную поставку PG.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37022027
Фотография Степан H.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо большое. Особо ценная вещь.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37022136
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim BogukА вот с primary key этот фокус до выхода версии 9.1 не пройдет (в 9.1 обещают возможность уже созданный индекс обьявить как primary key).Причем непонятно будет-ли тогда блокироваться таблица.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37023930
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ёш http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY

PG всё это умеет, и O_DIRECT и posix_fadvise. насчёт O_DIRECT - речь про это:
The open_* options also use O_DIRECT if available. Not all of these choices are available on all platforms.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
?

так оно имеет отношение только к WAL (то есть никак не поможет в борьбе с двойной буферизацией в shared memory/кэше OS).

PS: из изменений в 9.0.2:
Force the default wal_sync_method to be fdatasync on Linux (Tom Lane, Marti Raudsepp)

The default on Linux has actually been fdatasync for many years, but recent kernel changes caused PostgreSQL to choose open_datasync instead. This choice did not result in any performance improvement, and caused outright failures on certain filesystems, notably ext4 with the data=journal mount option.

http://www.postgresql.org/docs/9.0/static/release-9-0-2.html
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37024080
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eddieнасчёт O_DIRECT - речь про это:
The open_* options also use O_DIRECT if available. Not all of these choices are available on all platforms.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
?Да.
eddieтак оно имеет отношение только к WAL (то есть никак не поможет в борьбе с двойной буферизацией в shared memory/кэше OS).Можно сделать большой shared buffers, тогда под кеш файловой системы не останется места. Так же, кеш файловой системы можно настроить средствами операционной системы.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37026895
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обновлена версия утилиты. (переписана почти начисто)
Из бонусов:
1)поддержка DBD::Pg как основного API к базе (спасибо Warstone)
2)поддержка ключа --all вместо указания таблицы для того чтобы обработать всю базу или всю схему за раз
3)встроена эвристика которая не делает упаковку таблицы если оцениваемый уровень распухания меньше 30% (можно отключить через --force)
4)заметно более умная установка параметров --pages-per-round и --pages-per-vacuum (причем первый будет автоматически уменьшатся по мере уменьшения таблицы)... все это сделано для того чтобы --all нормально работал и с большими и с маленькими таблицами в базе
5)добавлена куча отладочного вывода... см --verbose-level
6)слегка побыстрее в простых случаях
7)по коду стало в 10 раз более читаемо и понятно... весь sql изолирован от основной логики работы.

Брать прямо из svn все там же где и раньше:
http://code.google.com/p/compacttable/

Версия протестирована на нескольких базах размером от 10GB до 300GB никаких проблем или ошибок пока не выявлено.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37027952
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vacuum_table.pl revision 22

Код: plaintext
1.
2.
3.
4.
5.
6.
root@ubuntus:/home/andrei# ./vacuum_table.pl --username postgres --dbname test --all
 Tue Dec 21 17:19:01 2010 BEGIN WORK
Can't init DBI because of No such file or directory
Managed psql connection will be avail. in futher revisions
SQL execution method is Password for user postgres:
Using: host = localhost, port = 5432, user = postgres, database = test, delay = 0 s, delay-ratio = 2
Can't use an undefined value as an ARRAY reference at ./vacuum_table.pl line 322.

line 322
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
	my $result = perform_query("
SELECT
	c.oid	  AS oid,
	n.nspname AS schema,
	c.relname AS name
....
");
	return @$result;
Что я сделал не так ? К базе скрипт подключился создал хранимку в логе пишет
EET LOG: could not receive data from client: Connection reset by peer
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37028609
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SmeL_mdvacuum_table.pl revision 22

Код: plaintext
1.
2.
3.
4.
5.
6.
root@ubuntus:/home/andrei# ./vacuum_table.pl --username postgres --dbname test --all
 Tue Dec 21 17:19:01 2010 BEGIN WORK
Can't init DBI because of No such file or directory
Managed psql connection will be avail. in futher revisions
SQL execution method is Password for user postgres:
Using: host = localhost, port = 5432, user = postgres, database = test, delay = 0 s, delay-ratio = 2
Can't use an undefined value as an ARRAY reference at ./vacuum_table.pl line 322.

line 322
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
	my $result = perform_query("
SELECT
	c.oid	  AS oid,
	n.nspname AS schema,
	c.relname AS name
....
");
	return @$result;
Что я сделал не так ? К базе скрипт подключился создал хранимку в логе пишет
EET LOG: could not receive data from client: Connection reset by peer

Спасибо за репорт сейчас разберемся и починим... судя по всему при создании поддержки DBI сломали где то работу через psql. Через час будет новая версия.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37028653
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В репозитарий закомичена исправленная версия. Мои извинения за пролезший косяк.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37033171
905
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
дошли руки попробовать

ругается в скрипте на сформированный sql:
Код: plaintext
AND c.oid = "__test"::regclass 
поправил на:
Код: plaintext
AND c.oid = '__test'::regclass 

мой тест делал так (уменьшил кол-во строк и возле рандома поправил 1 на 0.5):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE __test as select id,random() as f1,random() as
f2,random()::text as f3,now() as mtime,(random()> 0 . 5 )::boolean as flag
FROM generate_series( 1 , 1000000 ) as t(id);
DELETE FROM __test where id% 5 <> 0 ;
ALTER TABLE __test add primary key (id);
CREATE INDEX __test_f1_key ON __test(f1);
CREATE INDEX __test_f2_key ON __test(f2);
CREATE INDEX __test_f3_key ON __test(f3);

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT sum(pg_relation_size('public.'
||indexname))::bigint/current_setting('block_size')::bigint
,pg_relation_size('__test')/current_setting('block_size')::bigint,
pg_size_pretty(pg_relation_size('__test')), pg_size_pretty(pg_total_relation_size('__test'))
FROM pg_indexes WHERE schemaname='public' AND tablename='__test';

 13188 	 11358 	 89  MB	 192  MB

Код: plaintext
1.
2.
3.
4.
./vacuum_table.pl
real    2m55.557s

 13188 	 2287 	 18  MB	 121  MB

вопрос: суммарный размер индексов не уменьшился (13188), (я полагал, что должен) не ?

opensuse 11.3 x86_64; postgresql 8.4.4, r31
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37033273
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
905дошли руки попробовать

ругается в скрипте на сформированный sql:
Код: plaintext
AND c.oid = "__test"::regclass 
поправил на:
Код: plaintext
AND c.oid = '__test'::regclass 

мой тест делал так (уменьшил кол-во строк и возле рандома поправил 1 на 0.5):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE __test as select id,random() as f1,random() as
f2,random()::text as f3,now() as mtime,(random()> 0 . 5 )::boolean as flag
FROM generate_series( 1 , 1000000 ) as t(id);
DELETE FROM __test where id% 5 <> 0 ;
ALTER TABLE __test add primary key (id);
CREATE INDEX __test_f1_key ON __test(f1);
CREATE INDEX __test_f2_key ON __test(f2);
CREATE INDEX __test_f3_key ON __test(f3);

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT sum(pg_relation_size('public.'
||indexname))::bigint/current_setting('block_size')::bigint
,pg_relation_size('__test')/current_setting('block_size')::bigint,
pg_size_pretty(pg_relation_size('__test')), pg_size_pretty(pg_total_relation_size('__test'))
FROM pg_indexes WHERE schemaname='public' AND tablename='__test';

 13188 	 11358 	 89  MB	 192  MB

Код: plaintext
1.
2.
3.
4.
./vacuum_table.pl
real    2m55.557s

 13188 	 2287 	 18  MB	 121  MB

вопрос: суммарный размер индексов не уменьшился (13188), (я полагал, что должен) не ?

opensuse 11.3 x86_64; postgresql 8.4.4, r31

На всякий случай при vacuum fulll размер индексов может и в 2 раза вырости и растет почти всегда.
А касательно уменьшения индексов берите свежую версию из svn и используйте ключ --perform-reindex.
Указанная вами выше проблема в свежей версии тоже уже вылечена.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37033493
905
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim BogukА касательно уменьшения индексов берите свежую версию из svn и используйте ключ --perform-reindex.
Указанная вами выше проблема в свежей версии тоже уже вылечена.

взял последнею версию и перевыполнил тест с --perform-reindex, и опять не уменьшился индекс
удалил еще половину записей (DELETE FROM __test where id%2<>0) и прогнал скрипт, стало:
Код: plaintext
 13188 	 1144 	 9152  kB	 112  MB
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37033653
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
905Maxim BogukА касательно уменьшения индексов берите свежую версию из svn и используйте ключ --perform-reindex.
Указанная вами выше проблема в свежей версии тоже уже вылечена.

взял последнею версию и перевыполнил тест с --perform-reindex, и опять не уменьшился индекс
удалил еще половину записей (DELETE FROM __test where id%2<>0) и прогнал скрипт, стало:
Код: plaintext
 13188 	 1144 	 9152  kB	 112  MB


Хммм... постучитесь ко мне в jabber или почту maxim.boguk@gmail.com или в skype maxim.boguk
попробуем разобратся почему реиндексация не срабатывает.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37044006
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Был выявлен и исправлен неприятный баг при использовании --perform-reindex (--print-reindex) в ситуации когда индексы расположены на отдельном от базы tablespace. В такой ситуации после отработки программы индексы оказывались в умолчательном tablespace для базы.

Исправлено с r35.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37047184
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Очередная серьезная доработка программы (r36). Видимых изменений в функциональности нет но очень много сделано для ускорения работы и повышения надежности.

Изменения:
1)--perform-reindex --print-reindex теперь заменяют старый индекс новым и дропают старый индекс в одной транзакции (так чтобы не могло возникнуть ситуации при аварийном завершении процесса когда старый индекс уже убили а новый еще не переименовали в старое название)

2)--print-reindex --perform-reindex теперь выполняются в самом конце после того как все таблицы уже упакованы

3)добавлены корректные проверки на завершение старых транзакций (перед тем как выполнять vacuum) и на то что нет давних локов на таблицу (чтобы не повесить ожидающий exclusive lock на таблицу когда не надо) (резко снизился шанс того что при переиндексации возникнет долгий exclusive lock на смене индексов). Как итог стало работать быстрее так как вместо обязательного 2х секундного ожидания перез запуском vacuum стало ожидать только завершения старых транзакций.

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

5)перераскидана часть сообщений между --verbose-level= 1,2 и 3 и добавлено много новой полезной информации о процессе выполнения.

6)по результатам профилирования изменена часть значений по умолчанию.

7)добалена корректная (насколько это возможно) проверка на то что таблица успешно упакована до максимально возможного размера или около того.
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37050630
Фотография alienzzzz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Отпишите, кто-то это пользует в рабочих проектах ?
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37050632
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alienzzzzОтпишите, кто-то это пользует в рабочих проектах ?

Я как автор использую (список текущих рабочих проектов см http://mboguk.moikrug.ru/ ,он весьма представительный).
Еще несколько человек с которыми я общался ее пробовали насколько я знаю.

Если кто то кроме меня ее использует (или пробовал) отпишитесь в этот топик если вас не затруднит (с комментариями и предложениями если таковые будут).

Хочу заметить что утилита все-таки не для того чтобы ее по крону пускать (т.е. это скорее инструмент для починки когда что то не то с размером таблицы случилось а не замена autovacuum хотя я временами с --all ее пускаю но только руками под контролем происходящего).

В данный момент все известные мне баги или проблемы в ней устранены (хотя безусловно там есть куда дальше развивать).
...
Рейтинг: 0 / 0
Vacuum Full без полного лока таблицы
    #37050741
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,
Использовал на рабочих базах, проблем не обнаружил
...
Рейтинг: 0 / 0
25 сообщений из 154, страница 3 из 7
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Vacuum Full без полного лока таблицы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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