Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
30.03.2007, 11:16
|
|||
|---|---|---|---|
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
Приветствую, господа. Такая ситуация: База данных на pg (8.2.3) восстанавливается из архива. После восстановления она занимает на диске 90 Gb (естественно, со всеми индексами и т.д.). После этого она работает месяц и активно используется несколькими приложениями. Данные добавляются и изменяются в больших объемах. autovacuum включен. За месяц размер базы на диске вырастает до 190 Gb. Я решаю сделать VACUUM FULL ANALIZE чтобы немного освободить место и вообще... VACUUM длится уже около двух суток и конца ему не видно... Вопрос - почему так долго? Сервер достаточно мощный, и настроен pg вроде бы правильно... За первые 6 часов работы операции VACUUM FULL ANALIZE размер базы на диске сократился на 8 гиг. За последущие сутки - только на 1 гиг. Загрузка проца постоянно - в пределах 60%. Доступ к базе никто не имеет больше (чтоб никто не подумал, что проблема в этом). Характеристики сервера: 2 x Intel(R) Xeon(TM) CPU 3.40GHz памяти - 8 гиг ОС - CentOS 4.4 с smp-ядром В /etc/sysctl.conf видим следущее: kernel.shmmax = 4126146560 kernel.shmall = 4126146560 vm.overcommit_memory=2 В конфиге pg видим: shared_buffers = 400MB work_mem = 64MB maintenance_work_mem = 640MB max_fsm_pages = 204800 max_fsm_relations = 3000 checkpoint_segments = 64 effective_cache_size = 1024MB stats_start_collector = on stats_row_level = on autovacuum = on В базе порядка 2000 относительно мелких таблиц и одна, размером где-то 2/3 от всей базы. Что у меня не так сделано? Почему так долго эта операция выполняется? Подскажите, кто знает. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2007, 11:34
|
|||
|---|---|---|---|
|
|||
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
А свободного места много на диске, где база находится? А сильно ли большая таблица была дефрагментирована? Если есть возможность остановки сервера, то я для таких больших таблиц создавал бы дубликат имеющейся таблицы, сливал туда данные из старой, создавал бы нужные индексы и удалял бы старую таблицу. Если возможности остановки сервера нет, то лучший вариант - часто делатьVACUUM ANALYZE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2007, 11:42
|
|||
|---|---|---|---|
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
BlackDanА свободного места много на диске, где база находится? А сильно ли большая таблица была дефрагментирована? Если есть возможность остановки сервера, то я для таких больших таблиц создавал бы дубликат имеющейся таблицы, сливал туда данные из старой, создавал бы нужные индексы и удалял бы старую таблицу. Если возможности остановки сервера нет, то лучший вариант - часто делатьVACUUM ANALYZE Места свободного 100 гиг на диске. А по поводу вашего совета делать копию таблицы а старую удалять... по-моему это не дело так извращаться. Должен же вакуум нормально работать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2007, 12:00
|
|||
|---|---|---|---|
|
|||
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
tier.ruА по поводу вашего совета делать копию таблицы а старую удалять... по-моему это не дело так извращаться. Должен же вакуум нормально работать... Это к вопросу, почему при востановлении таблицы из дампа индексы создаются в последнюю очередь, а не перед заливкой самих данных. З.Ы. У меня самого опыта с полным вакуумом таких больших таблиц нет, поэтому очень интересно, чем и когда это закончится ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2007, 12:44
|
|||
|---|---|---|---|
|
|||
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
tier.ru За первые 6 часов работы операции VACUUM FULL ANALIZE размер базы на диске сократился на 8 гиг. За последущие сутки - только на 1 гиг. Загрузка проца постоянно - в пределах 60%. Доступ к базе никто не имеет больше (чтоб никто не подумал, что проблема в этом). Характеристики сервера: 2 x Intel(R) Xeon(TM) CPU 3.40GHz памяти - 8 гиг ОС - CentOS 4.4 с smp-ядром А чего с винтом? tier.ru Что у меня не так сделано? Почему так долго эта операция выполняется? Подскажите, кто знает. Спасибо. У меня есть два предположения: 1. Посмотри в сторону файлов WAL, у меня при вакууме "тяжелой" таблице они писались с потрясающей скоростью, и все его 750 метров постоянно перезаписывались :( 2. В принципе не так давно пофиксали какую-то багу по тормозам ВАКУУМА. Подробности, попадает ли этот случай под провило и т.д. - в официальной рассылке постгресов. А вообще создание таблицы заново и залив туда данных, с пересозданием индексов - это приблизительный алгоритм VACUUM FULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2007, 14:28
|
|||
|---|---|---|---|
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
VACUUM FULL VERBOSE Хотя бы будете видеть что он делает в текущий момент ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2007, 14:33
|
|||
|---|---|---|---|
|
|||
VACUUM FULL ANALIZE длится ну ооочень долго... |
|||
|
#18+
К сожалению VACUUM FULL VERBOSE выдаст результат, когда этот VACUUM FULL закончиться. Правельнее вопрос Andrey Daeron "А чего с винтом?". Хорошо бы SCSI, да еще RAID0. А мне на винде, правда, здорово помогла дефрагментация винта. Вся обработка почти на четверть ускорилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=53&mobile=1&tid=2005557]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
82ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 258ms |
| total: | 432ms |

| 0 / 0 |
