Страница 1 из 1

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

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

Добавлено: 07 июн 2006, 13:20
kdv
Запускаю запрос на
удаление записей старее определенной даты (есть там такое поле).
Выполняется безбожно долго.
удаление - это создание версий. "безбожно долго" - сколько записей удаляется, и как "долго"?
Как бы заставить
Firebird использовать побольше вычислительных ресурсов и
работать побыстрее?
на многопроцессорных машинах рекомендуется использовать Firebird Classic, если надо загрузить все процессоры. Удаление, само по себе, будет выполняться одним процессором, разумеется.

Добавлено: 07 июн 2006, 13:24
Demiurg
Удаляется примерно половина записей ~7 000 000. И весь процесс занимает порядка 1-1.5 часа.
Птица именно классик.

Добавлено: 07 июн 2006, 14:06
dimitr
какой-то из индексов плох с точки зрения селективности

Добавлено: 07 июн 2006, 14:16
Demiurg
А при плохом индексе такая низкая загрузка процессора это нормально?

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

Добавлено: 07 июн 2006, 14:44
Merlin
dimitr писал(а):хороший вопрос. Вроде проц должен быть сильнее загружен. 3% это явно сплошной дисковый в/в. Надо бы посмотреть page reads/writes/fetches в результате удаления.
Кстати, глянь в мыло, которое firebird2

Добавлено: 07 июн 2006, 15:15
Demiurg
dimitr писал(а):хороший вопрос. Вроде проц должен быть сильнее загружен. 3% это явно сплошной дисковый в/в. Надо бы посмотреть page reads/writes/fetches в результате удаления.
Ок. Еще один эксперимент и посмотрю.

Добавлено: 08 июн 2006, 09:03
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%.

Добавлено: 08 июн 2006, 09:12
CyberMax
:shock:
Force Writes выключен?
Какая ОС?
Что за дисковая подсистема?
Что за процессоры?

Добавлено: 08 июн 2006, 09:29
Demiurg
ОС: Вынь 2003
Диск: IBM SCSI (шустрый)
Процы: 2 Xeon'a 2.8
Оперативки 2.5 гига

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

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

Добавлено: 08 июн 2006, 09:43
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 гиг :-)

Добавлено: 08 июн 2006, 10:36
dimitr
Demiurg писал(а):Результат
а сколько страниц таблица занимала (приблизительно), не скажешь?

Добавлено: 08 июн 2006, 10:38
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

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

Добавлено: 08 июн 2006, 10:39
Demiurg
dimitr

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

Добавлено: 08 июн 2006, 10:40
dimitr
Demiurg писал(а): Page size 1024
вопрос можно закрывать. Быстро backup/restore с увеличением страницы до 8К.

Добавлено: 08 июн 2006, 11:30
kdv
Page size 1024
это никуда не годится. IBAnalyst никогда не запускал? Он бы сразу выругался на размер страницы. Для 4-гиговой базы это просто караул.

Добавлено: 08 июн 2006, 11:32
Demiurg
Всем спасибо, проблема решена.
Перенес базу на Linux на таком же железе, page size=8192. Шустро пашет, зараза!