Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Тут вот у нас возникла маленькая проблемка с удалением записей из базы - очень медленно происходит.
Например, при удалении 3000 записей затрачивается 25 минут, при CPU-load 99,9%.
команда выглядит примерно так:
DELETE FROM datadb WHERE timestamp LIKE '2005-01-0%'
Я думал что просто по порядку сделать удаление типа 'WHERE ID BETWEEN 1 AND 5000' будет быстрее - таже пертрушка.
Говорит не много (я правда немного видоизменил команду).
Но толку столько-же (по времени):
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)
1) на винте места хватает, но наверняка фрагментирован - за последние 5 месяцев не выключался - база должны была постоянно работать - сегодня сделаем.
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!
3) настройка производилась - но с начала запуска базы - ничего не менялось
4) "А в каком месте ты нам врёшь: когда показываешь EXPLAIN ANALYZE, отрабатывающий за 0,05 с или когда говоришь о запросе, работающем 8 минут?"
Тут скажу так - то что он вывел - это одно - но реально я ждал несколько минут - всё это время CPU загрузка было 99,99%, и только после этого времени psql выдал промт на новую команду!
NECTIS
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!
а индексы на полях фк есть? (если нет - создай)
а каскады на фк есть? А дополнительные таблички на каскадах уже к зависимым табличкам не появились ли. А триггерами зависимые таблички не обвязывались ли. "Папаша не пьющий ли? Мамаша не сумашедша ли? До ветру часто ходили?"
Sad Spirit NECTISПривет всем,
2) внешние ключи есть - но в начале они тоже были - и этих проблем не было!
3) настройка производилась - но с начала запуска базы - ничего не менялось
ты что, издеваешься? хочешь, чтобы тебе помогали и не хочешь давать никакой информации?
В общем 4321 дело говорит, нужны индексы по внешним ключам, если их до сих пор нету.
А так давай показывай схему базы и значения из postgresql.conf
Согласен.
Схема - что конкретно показать? - установочный sql скрипт подойдёт?
Индексов там много, так же как и триггеров и функций.
В приложенном файле postgresql конфигурация.
Но там стандартные настройки - если что не так - помогите! Правда очень надо!
NECTIS Схема - что конкретно показать? - установочный sql скрипт подойдёт?
Индексов там много, так же как и триггеров и функций
достаточно показать ту часть, которая "затрагивается" удалениями. (триггерами, чеками и ф-кеями)
"Индексов много" - не ответ. Поля вторичных ключей (в подчиненных таблицах) должны либо быть первыми полями сложных индексов, либо попросту на них должны заводится отдельные индексы. Если это не так - отработка проверки целостности по ф-кеям у вас будет работать без использования индекса - т.е. попросту сканом подчиненной таблицы. Если количество вставляемых записей сравнимо (больше) количества наличествующих - есть надежда, что снос зависимостей перед вливом и поднятие - после существенно (раз до 5-ти-7-ми у меня иногда набегало) повысит скорость вставки (интегрально на все операции). (Но если там целый паровоз зависимостей, то без конкретной схемы не разберешься)
Триггеры надо смотреть отдельно. Может оказаться, что вместо позаписных отработок, которые уместны при работе из интерморды, при массированной вставке имеет смысл запустить нечто "на стейтмент" (т.е. на всю операцию)(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).
4321(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).
Согласен - перечитал туеву хучу форумов...
Осталось отключить!
А как?
NECTIS 4321(например "инкрементальный" триггер (коли таковые есть) на каждую запись отключить, а по вливу всего - произвести однократный расчет конечных агрегатов - это для схем, где считаются какие-то итоги триггерами).
Согласен - перечитал туеву хучу форумов...
Осталось отключить!
А как?
ну, проще всего это делается так:
DROP xxx;
а после
CREATE ххх;
но если xxx это не триггер, а таблица или ПК таблицы, то придется повторно запустить создание всех остальных обращающихся к этой таблице процедур (OID-ы то изменятся).
Но есть и способ отключить (кажется все) триггера (ищи по форуму - насколько я помню - от версии может зависеть допустимость). Я сам не пользуюсь, но стандартный pg_restore вроде пользуется этой фенькой.
4321
ну, проще всего это делается так:
DROP xxx;
а после
CREATE ххх;
но если xxx это не триггер, а таблица или ПК таблицы, то придется повторно запустить создание всех остальных обращающихся к этой таблице процедур (OID-ы то изменятся).
Но есть и способ отключить (кажется все) триггера (ищи по форуму - насколько я помню - от версии может зависеть допустимость). Я сам не пользуюсь, но стандартный pg_restore вроде пользуется этой фенькой.
Тогда это называется УДАЛИТЬ/СОЗДАТЬ.
Это не правильно - ибо удаление чревато уничтожением данных - а это очень и очень плохо... Я полагал есть другой способ...
А что по поводу конфигурации PostgreSQL? в приложенном файлике?
Я просто уверен что его править нужно! Подскажете что?
Ну поехали:
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 сборку статистики тоже лучше включить - ресурсов жрёт не много, а статистика всегда актуальна
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.
