Загрузка процессора при выполнении запроса

[Demiurg]

Есть база на Firebird 1.5.3. Размер файла порядка 4-х гиг.
В ней таблица порядка 14 000 000 записей. Запускаю запрос на
удаление записей старее определенной даты (есть там такое поле).
Выполняется безбожно долго. При этом загрузка проца около 3-х
процентов. А сервак вообще 2-х процессорный. Как бы заставить
Firebird использовать побольше вычислительных ресурсов и
работать побыстрее?

[kdv]

Запускаю запрос на
удаление записей старее определенной даты (есть там такое поле).
Выполняется безбожно долго.

удаление - это создание версий. "безбожно долго" - сколько записей удаляется, и как "долго"?

Как бы заставить
Firebird использовать побольше вычислительных ресурсов и
работать побыстрее?

на многопроцессорных машинах рекомендуется использовать Firebird Classic, если надо загрузить все процессоры. Удаление, само по себе, будет выполняться одним процессором, разумеется.

[Demiurg]

Удаляется примерно половина записей ~7 000 000. И весь процесс занимает порядка 1-1.5 часа.
Птица именно классик.

[dimitr]

какой-то из индексов плох с точки зрения селективности

[Demiurg]

А при плохом индексе такая низкая загрузка процессора это нормально?

[dimitr]

хороший вопрос. Вроде проц должен быть сильнее загружен. 3% это явно сплошной дисковый в/в. Надо бы посмотреть page reads/writes/fetches в результате удаления.

[Merlin]

хороший вопрос. Вроде проц должен быть сильнее загружен. 3% это явно сплошной дисковый в/в. Надо бы посмотреть page reads/writes/fetches в результате удаления.

Кстати, глянь в мыло, которое firebird2

[Demiurg]

хороший вопрос. Вроде проц должен быть сильнее загружен. 3% это явно сплошной дисковый в/в. Надо бы посмотреть page reads/writes/fetches в результате удаления.

Ок. Еще один эксперимент и посмотрю.

[Demiurg]

Ну вот, та же таблица, запрос:

Код: Выделить всё

delete from data;

Результат

Код: Выделить всё

Plan
PLAN (DATA NATURAL)

Adapted Plan
PLAN (DATA NATURAL)

14608479 record(s) was(were) deleted from DATA

------ Performance info ------
Prepare time = 0ms
Execute time = 5h 8m 16s 750ms
Current memory = 18,833,300
Max memory = 18,897,728
Memory buffers = 2,048
Reads from disk to cache = 11,700,714
Writes from cache to disk = 1,732,986
Fetches from cache = 102,377,854

Загрузка процессора порядка 4%.

[CyberMax]

Force Writes выключен?
Какая ОС?
Что за дисковая подсистема?
Что за процессоры?

[Demiurg]

ОС: Вынь 2003
Диск: IBM SCSI (шустрый)
Процы: 2 Xeon'a 2.8
Оперативки 2.5 гига

Про Force Writes - где проверить и как?

[CyberMax]

1.

Про Force Writes - где проверить и как?

В каталоге \bin firebird'а напиши команду:
gstat -h ПутьКБазе
или перепиши gstat в каталог с базой и напиши:
gstat -h база_данных.fdb (надеюсь, расширение у тебя fdb?).
Инфу кинь сюда.
2. Через диспетчер задач узнай размер системного кэша и напиши его здесь.
3. Стоит оптимизация фоновых процессов и системного кэша? Это в свойствах системы - параметры быстродействия - дополнительно.

[kdv]

Firebird 1.5.3, база 2.6 гиг, размер страницы 16 к. удаляем тоже 14 миллионов записей.
правда, Forced Write = OFF.
загрузка проца - 50-60 %.

Код: Выделить всё

Table	Records	RecLength	VerLen	Versions	Max Vers	Data Pages	Size, mb	Slots	Avg fill%	0-19%	20-39%	40-59%	60-79%	80-99%	RealFill
MINUTES	14287963	116.90	0.00	0	0	118726	1855.09	118726	98	0	0	0	1	118725	98

PLAN (MINUTES NATURAL)

14287963 record(s) was(were) deleted from MINUTES

------ Performance info ------
Prepare time = 0ms
Execute time = 3m 37s 360ms
Current memory = 19 529 144
Max memory = 19 616 980
Memory buffers = 2 048
Reads from disk to cache = 137 425
Writes from cache to disk = 137 464
Fetches from cache = 89 872 444

из сравнения статистики следует что вероятно:

1. в базе размер страницы 1-2К. это мало
2. таблица сильно замусорена. то есть при удалении срабатывает сборка мусора (?). Индексы на таблицу отключены?
Кстати, я специально не стал отключать индексы по своей таблице, для проверки:

Код: Выделить всё

статистика "кривовато" выглядит, в общем, там и "плохие" индексы по 12 миллионов total dup, и уникальные, и т.п. 5 штук.

3. на таблице висят триггеры, которые ...
4. проблема в Win2003 + SCSI. иногда бывает очень тормозно, хуже чем Win2000 + SCSI. зависит от железа.

проц AMD Athlon 64 3000+, диск IDE IBM 80 гиг

[dimitr]

Результат

а сколько страниц таблица занимала (приблизительно), не скажешь?

[Demiurg]

Итак, gstat выдал:

Код: Выделить всё

Database header page information:
        Flags                   0
        Checksum                12345
        Generation              305
        Page size               1024
        ODS version             10.1
        Oldest transaction      49
        Oldest active           264
        Oldest snapshot         257
        Next transaction        299
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      0
        Implementation ID       16
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jun 7, 2006 13:47:22
        Attributes              force write

    Variable header data:
        Sweep interval:         20000
        *END*

2. Кэш: 2351064
3. Оптимизация стоит

kdv

Триггеров нет
Про мусор - база только из бэкапа
Ну страницу то я побольше сделаю, но так ли это критично?

[Demiurg]

dimitr

Увы - без понятия.

[dimitr]

Page size 1024

вопрос можно закрывать. Быстро backup/restore с увеличением страницы до 8К.

[kdv]

Page size 1024

это никуда не годится. IBAnalyst никогда не запускал? Он бы сразу выругался на размер страницы. Для 4-гиговой базы это просто караул.

[Demiurg]

Всем спасибо, проблема решена.
Перенес базу на Linux на таком же железе, page size=8192. Шустро пашет, зараза!