|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
Всем пирвет! Собственно есть тестовый стенд, машинка достаточно слабая, 2 Xeon(R) CPU E5-2676 ну и RAM в GB, диски SSD Проблема в том что этот тестовый стенд регулярно используется для тестирования каких-либо настроек PostgreSQL, тестирование архитектурных решений и так далее. Сейчас после очередного теста, загрузить порядка 700ГБ данных, удалив все тестовые данные из таблиц (их было две), все стало ужасно медленно работать уже второй час. Я так понимаю в PostgreSQL мне мешает, после удаления данных, работать комфортно - WAL механизмы для синхронизации данных с журналом и autovacuum для чистки помеченных на удаление данных. Вопрос, есть ли какая-либо возможность отключать данные процессы и что я потеряю отключив данные процессы? Если потеряю целостность логической части и файловой системы и так далее. Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2017, 17:07 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
Вы что, сделали delete на тестовых таблицах размером 700Gb? Truncate или drop table невозможно было сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2017, 17:51 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
Sergei.Agalakov, Все верно. Сделали delete all ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2017, 09:04 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
Sergei.Agalakov, Дело в том что одно из условий так сказать тестирования это как то оптимизировать write condition процессы, к примеру инсерты сделать без подтверждения, delete то же самое. Но как то не реагирует. На данный момент это запуск autovacuum после delete, вот этот зверь не отключается (autovacuum = off). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2017, 09:08 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
alexzf, если вы пришли к решению "надо отключить фоновые процессы" значит вы что-то делаете изначально неверно. удаляйте не через "delete all", а truncate'ом, или вообще удаляйте постгресовый инстанс целиком и делайте initdb заново. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2017, 10:59 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
alexzfSergei.Agalakov, Дело в том что одно из условий так сказать тестирования это как то оптимизировать write condition процессы, к примеру инсерты сделать без подтверждения, delete то же самое. Но как то не реагирует. На данный момент это запуск autovacuum после delete, вот этот зверь не отключается (autovacuum = off). пробуйте сделать fsync=off, synchronous_commit=off, full_page_writes=off, настройки чекпоинтов выкрутить в максимум чтобы на время выполнения теста чекпоинты вообще не делались +) -- но это все только для тестовой среды где данные продолбать не жалко. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2017, 11:02 |
|
WAL/autovacuum процессы после удаления записей из таблицы.
|
|||
---|---|---|---|
#18+
daevy, Отключение фоновых процессов, да это решение неверное, ведь когда то нужно запускать тот же autovacuum, просто дело в том что после огромных записей в таблицу тестировщику ждут пока завершится autovacuum , а простой это плохо :) Спасибо отключил все, прям по вашему посту. Единственное, такое чувство что autovacuum (даже если отключен) срабатывает после вставки через COPY. То бишь для COPY свое правило запуска autovacuum. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 12:28 |
|
|
start [/forum/topic.php?fid=53&fpage=66&tid=1996220]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
others: | 290ms |
total: | 411ms |
0 / 0 |