Страница 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
Ну вот, та же таблица, запрос:
Результат
Код: Выделить всё
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
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. Шустро пашет, зараза!