Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Удаление записей - работает очень медленно! / 22 сообщений из 22, страница 1 из 1
01.04.2005, 12:45
    #32993090
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Привет уважаемым Гуру!

Тут вот у нас возникла маленькая проблемка с удалением записей из базы - очень медленно происходит.
Например, при удалении 3000 записей затрачивается 25 минут, при CPU-load 99,9%.
команда выглядит примерно так:
DELETE FROM datadb WHERE timestamp LIKE '2005-01-0%'

Я думал что просто по порядку сделать удаление типа 'WHERE ID BETWEEN 1 AND 5000' будет быстрее - таже пертрушка.

Что я могу сделать для ускорения процесса?

Спасибо заранее
...
Рейтинг: 0 / 0
01.04.2005, 13:22
    #32993208
wbear
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
begin ;
explain analuze delete ...

что говорит?
...
Рейтинг: 0 / 0
01.04.2005, 14:47
    #32993540
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Ищите каскады и вообще вторичные ключи к табличке. + посмотри триггеры на удаление.
...
Рейтинг: 0 / 0
01.04.2005, 19:50
    #32994334
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Говорит не много (я правда немного видоизменил команду).
Но толку столько-же (по времени):

voipdb=> begin;
BEGIN
voipdb=> explain analyze delete from voipcall where id between '48181' and '48909';
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Index Scan using voipcall_pkey on voipcall (cost=0.00..2690.49 rows=699 width=6) (actual time=17.368..20.754 rows=729 loops=1)
Index Cond: ((id >= 48181::bigint) AND (id <= 48909::bigint))
Total runtime: 48.122 ms
(3 rows)
...
Рейтинг: 0 / 0
01.04.2005, 19:51
    #32994335
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
А результат ждал 8 минут - это для 700 записей...
...
Рейтинг: 0 / 0
01.04.2005, 21:39
    #32994402
DkmS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Сегодня удалял ок. полумиллиона записей - 1.5 минуты + 5 минут vacuum.
...
Рейтинг: 0 / 0
01.04.2005, 22:32
    #32994432
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Счастливчик!
А вот у меня никак!

Что делать ума не приложу!
Сейчас CPU-Load на внесение записи от 10 до 45% :-(

Прсто Караул!
Что делать? Где копать?

База то не большая 2 миллиона записей всего!

Выручайте!
...
Рейтинг: 0 / 0
03.04.2005, 00:18
    #32994950
DkmS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Чё-то с компьютером - может, диск под завязку, фрагментирован сильно. Тогда так и должно быть при вставке.
...
Рейтинг: 0 / 0
03.04.2005, 13:42
    #32995156
Sad Spirit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTISСчастливчик!
Что делать ума не приложу!
Сейчас CPU-Load на внесение записи от 10 до 45% :-(

Прсто Караул!
Что делать? Где копать?


вопрос номер раз: ссылаются ли на эту таблицу какие-нибудь внешние ключи?

вопрос номер два: проводилась ли вообще настройка параметров в postgresql.conf?

вопрос номер два с половиной: если проводилась, то что там щас написано?
...
Рейтинг: 0 / 0
03.04.2005, 13:44
    #32995158
Sad Spirit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTISГоворит не много (я правда немного видоизменил команду).

Total runtime: 48.122 ms


А в каком месте ты нам врёшь: когда показываешь EXPLAIN ANALYZE, отрабатывающий за 0,05 с или когда говоришь о запросе, работающем 8 минут?
...
Рейтинг: 0 / 0
04.04.2005, 10:41
    #32995787
wbear
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
может все-таки кто-то лочит?
...
Рейтинг: 0 / 0
06.04.2005, 04:24
    #32999268
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Привет всем,

1) на винте места хватает, но наверняка фрагментирован - за последние 5 месяцев не выключался - база должны была постоянно работать - сегодня сделаем.

2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!

3) настройка производилась - но с начала запуска базы - ничего не менялось

4) "А в каком месте ты нам врёшь: когда показываешь EXPLAIN ANALYZE, отрабатывающий за 0,05 с или когда говоришь о запросе, работающем 8 минут?"
Тут скажу так - то что он вывел - это одно - но реально я ждал несколько минут - всё это время CPU загрузка было 99,99%, и только после этого времени psql выдал промт на новую команду!

Есть идеи?
...
Рейтинг: 0 / 0
06.04.2005, 04:29
    #32999269
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Дефрагментация... Хмм...

Система-то Linux!
...
Рейтинг: 0 / 0
06.04.2005, 10:24
    #32999596
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTIS
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!

а индексы на полях фк есть? (если нет - создай)
а каскады на фк есть? А дополнительные таблички на каскадах уже к зависимым табличкам не появились ли. А триггерами зависимые таблички не обвязывались ли. "Папаша не пьющий ли? Мамаша не сумашедша ли? До ветру часто ходили?"
...
Рейтинг: 0 / 0
06.04.2005, 10:32
    #32999626
Sad Spirit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTISПривет всем,
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!

3) настройка производилась - но с начала запуска базы - ничего не менялось

ты что, издеваешься? хочешь, чтобы тебе помогали и не хочешь давать никакой информации?

В общем 4321 дело говорит, нужны индексы по внешним ключам, если их до сих пор нету.

А так давай показывай схему базы и значения из postgresql.conf
...
Рейтинг: 0 / 0
07.04.2005, 00:49
    #33001653
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Sad Spirit NECTISПривет всем,
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!

3) настройка производилась - но с начала запуска базы - ничего не менялось

ты что, издеваешься? хочешь, чтобы тебе помогали и не хочешь давать никакой информации?

В общем 4321 дело говорит, нужны индексы по внешним ключам, если их до сих пор нету.

А так давай показывай схему базы и значения из postgresql.conf

Согласен.
Схема - что конкретно показать? - установочный sql скрипт подойдёт?
Индексов там много, так же как и триггеров и функций.
В приложенном файле postgresql конфигурация.
Но там стандартные настройки - если что не так - помогите! Правда очень надо!

Заранее спасибо!
...
Рейтинг: 0 / 0
07.04.2005, 11:18
    #33002125
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTIS Схема - что конкретно показать? - установочный sql скрипт подойдёт?
Индексов там много, так же как и триггеров и функций

достаточно показать ту часть, которая "затрагивается" удалениями. (триггерами, чеками и ф-кеями)


"Индексов много" - не ответ. Поля вторичных ключей (в подчиненных таблицах) должны либо быть первыми полями сложных индексов, либо попросту на них должны заводится отдельные индексы. Если это не так - отработка проверки целостности по ф-кеям у вас будет работать без использования индекса - т.е. попросту сканом подчиненной таблицы. Если количество вставляемых записей сравнимо (больше) количества наличествующих - есть надежда, что снос зависимостей перед вливом и поднятие - после существенно (раз до 5-ти-7-ми у меня иногда набегало) повысит скорость вставки (интегрально на все операции). (Но если там целый паровоз зависимостей, то без конкретной схемы не разберешься)


Триггеры надо смотреть отдельно. Может оказаться, что вместо позаписных отработок, которые уместны при работе из интерморды, при массированной вставке имеет смысл запустить нечто "на стейтмент" (т.е. на всю операцию)(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).
...
Рейтинг: 0 / 0
07.04.2005, 12:21
    #33002355
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
4321(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).

Согласен - перечитал туеву хучу форумов...
Осталось отключить!
А как?
...
Рейтинг: 0 / 0
07.04.2005, 13:29
    #33002582
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
NECTIS 4321(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).

Согласен - перечитал туеву хучу форумов...
Осталось отключить!
А как?

ну, проще всего это делается так:
DROP xxx;
а после
CREATE ххх;
но если xxx это не триггер, а таблица или ПК таблицы, то придется повторно запустить создание всех остальных обращающихся к этой таблице процедур (OID-ы то изменятся).


Но есть и способ отключить (кажется все) триггера (ищи по форуму - насколько я помню - от версии может зависеть допустимость). Я сам не пользуюсь, но стандартный pg_restore вроде пользуется этой фенькой.
...
Рейтинг: 0 / 0
07.04.2005, 18:58
    #33003552
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
4321
ну, проще всего это делается так:
DROP xxx;
а после
CREATE ххх;
но если xxx это не триггер, а таблица или ПК таблицы, то придется повторно запустить создание всех остальных обращающихся к этой таблице процедур (OID-ы то изменятся).

Но есть и способ отключить (кажется все) триггера (ищи по форуму - насколько я помню - от версии может зависеть допустимость). Я сам не пользуюсь, но стандартный pg_restore вроде пользуется этой фенькой.

Тогда это называется УДАЛИТЬ/СОЗДАТЬ.
Это не правильно - ибо удаление чревато уничтожением данных - а это очень и очень плохо... Я полагал есть другой способ...

А что по поводу конфигурации PostgreSQL? в приложенном файлике?
Я просто уверен что его править нужно! Подскажете что?
...
Рейтинг: 0 / 0
08.04.2005, 12:57
    #33004659
mwolf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
Ну поехали:
NECTIS
Тогда это называется УДАЛИТЬ/СОЗДАТЬ.
Это не правильно - ибо удаление чревато уничтожением данных - а это очень и очень плохо... Я полагал есть другой способ...

Отключение триггеров:
UPDATE pg_trigger SET tgenabled=FALSE WHERE tgname=xxx;
Включить, я надеюсь, догадаешься как.

NECTIS
А что по поводу конфигурации PostgreSQL? в приложенном файлике?
Я просто уверен что его править нужно! Подскажете что?
Параметры машины давай, все - проц, память, винты (скоко, какие, под что юзаются). Да и ещё, что там ещё крутиться?

ИМХО
16 метров под shared_buffers мало будет - я полпамяти под это дело отрезаю.
sort_mem тоже моно бы увеличить, только осторожно - у тебя max_connections = 300. Кстати, их не много?
effective_cache_size увеличить
geqo = true включить
stats_start_collector = true сборку статистики тоже лучше включить - ресурсов жрёт не много, а статистика всегда актуальна
...
Рейтинг: 0 / 0
08.04.2005, 14:33
    #33005119
NECTIS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей - работает очень медленно!
mwolfИМХО
16 метров под shared_buffers мало будет - я полпамяти под это дело отрезаю.
sort_mem тоже моно бы увеличить, только осторожно - у тебя max_connections = 300. Кстати, их не много?
effective_cache_size увеличить
geqo = true включить
stats_start_collector = true сборку статистики тоже лучше включить - ресурсов жрёт не много, а статистика всегда актуальна

На машине живёт маленький свич и радиус биллинг.
Р4 2,2Гц, 512МБ, 40Гб.

Поэтому только 64Мб могу под Постгрес отдать.
max_connections может быть до 200.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Удаление записей - работает очень медленно! / 22 сообщений из 22, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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