ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
20 сообщений из 20, страница 1 из 1
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541421
GuestIgorFB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GuestIgorFB
Гость
Добрый день.

Firebird 2.5.2, Windows Server 2008 R2.

На крупной базе размером 350 Гб накопился разрыв между OIT и OAT, запустили sweep вручную. На данный момент sweep работает уже третьи сутки, последние сутки работает монопольно.

I/O Write Bytes уже гораздо больше размера самой базы - 850 Гб.
fb_lock_print (c ключом -c) демонстрирует активность.
Например, сегодня ночью:

LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 5242880, Used: 4862912
Flags: 0x0001
Enqs: 308734391, Converts: 7300093, Rejects: 122080, Blocks: 689783
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 346723095, Acquire blocks: 2424222, Spin count: 0
Mutex wait: 0.7%
Hash slots: 1009, Hash lengths (min/avg/max): 0/ 0/ 4
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (1): forward: 2747832, backward: 2747832
Free owners (614): forward: 3687360, backward: 672816
Free locks (14738): forward: 22024, backward: 2664552
Free requests (59617): forward: 3752656, backward: 4286880
Lock Ordering: Enabled


Сегодня утром:

LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 5242880, Used: 4862912
Flags: 0x0001
Enqs: 357494277, Converts: 10067603, Rejects: 122080, Blocks: 689783
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 405238767, Acquire blocks: 2424222, Spin count: 0
Mutex wait: 0.6%
Hash slots: 1009, Hash lengths (min/avg/max): 0/ 0/ 4
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (1): forward: 2747832, backward: 2747832
Free owners (614): forward: 3687360, backward: 672816
Free locks (14738): forward: 22024, backward: 2579944
Free requests (59617): forward: 3019584, backward: 4530496
Lock Ordering: Enabled


Главный вопрос, есть ли какая-то возможность узнать прогресс работы sweep'а (грубо говоря, сколько ещё осталось ждать)?
Можно ли по данным fb_lock_print определить, на каком этапе работы sweeper?
И еще вопрос, нормально ли, что молотит третьи сутки? Предварительный backup через gbak с ключом -g делался чуть менее суток (примерно 22 часа), не в монопольном режиме.

Большое спасибо заранее.
...
Рейтинг: 0 / 0
25.10.2017, 08:07
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541427
Евгений Килин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Килин
Участник
GuestIgorFBНа крупной базе размером 350 Гб накопился разрыв между OIT и OAT, запустили sweep вручную. На данный момент sweep работает уже третьи сутки, последние сутки работает монопольно.

I/O Write Bytes уже гораздо больше размера самой базы - 850 Гб.
02.06.2017 была у меня похожая история :)
Проморгал разницу между OIT и OAT.
В результате в одной таблице записи по первичному ключу стали доставаться за 188 секунд.
Я не оговорился ровно _одна_ запись выбиралась не менее 188 _секунд_.
Если быть точнее была такая любопытная статистика запроса:

select * from Table where ID=109988700

Adapted Plan
------------------------------------------------
PLAN (TABLE INDEX (PK_TABLE))

Query Time
------------------------------------------------
Prepare : 15,00 ms
Execute : 188 574,00 ms
Avg fetch time: 188 574,00 ms

Memory
------------------------------------------------
Current: 51 900 520
Max : 53 082 752
Buffers: 3 000

Operations
------------------------------------------------
Read : 17 423 231
Writes : 4 647

Ну конечно запустил sweep.
В штаном режиме он на этой базе занимает примерно 10 минут.
У меня терпения хватило на 4 часа молотилова, потом снес sweep.
Поднял буферы с 3000 до 10000.
Прекратилось бешеное доставание страниц из кеша ОС и sweep как положено отработал минут за 10.
...
Рейтинг: 0 / 0
25.10.2017, 08:37
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541429
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
GuestIgorFBГлавный вопрос, есть ли какая-то возможность узнать прогресс работы sweep'а (грубо говоря, сколько ещё осталось ждать)?
gstat -r
...
Рейтинг: 0 / 0
25.10.2017, 08:42
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541493
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
GuestIgorFBесть ли какая-то возможность узнать прогресс работы sweep'аВ 2.5.2 - нет, позже (с 2.5.6, iirc) можно наблюдать в трейсе потабличную статистику.

Для ускорения можно деактивировать индексы, раз уж и так никто в БД не работает.
Но потом, есс-но, их придётся активировать.
Можно снять статистику gstat -r и отключить только индексы на таблицах с наибольшим кол-вом версий и при наличии большого кол-ва индексов на таблицу.
...
Рейтинг: 0 / 0
25.10.2017, 10:25
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541667
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Евгений КилинПроморгал разницу между OIT и OAT.
В результате в одной таблице записи по первичному ключу стали доставаться за 188 секунд.
не "в результате". OIT - это просто индикатор, что эта транзакция была завершена по rollback, и все.
Если он застревает, то просто увеличивается объем памяти, аллокируемый транзакциями snapshot при старте (Next-OIT)/4 байт.
На "доставание" записи, тем более по ПК, OIT никак не влияет.
Просто в конкретном месте скопилось дофига версий, при этом они не стали мусором из-за длительной транзакции.
...
Рейтинг: 0 / 0
25.10.2017, 13:11
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541703
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvПросто в конкретном месте скопилось дофига версий, при этом они не стали мусором из-за
длительной транзакции.

Нет, я делал эксперимент: 100 000 немусорных версий одной записи. Выборка её не занимала
дольше пары секунд. 180 секунд это явно сборка мусора, которая во всех существующих
версиях имеет O(N^2) алгоритм сбора ключей.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 13:38
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541706
Евгений Килин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Килин
Участник
kdvЕвгений КилинПроморгал разницу между OIT и OAT.
В результате в одной таблице записи по первичному ключу стали доставаться за 188 секунд.
не "в результате". OIT - это просто индикатор
"Для чего sweep пытается собрать мусор во всей базе данных? Для того, чтобы подвинуть "вверх" номер Oldest Interesting Transaction (Oldest transaction в gstat -h)...
А транзакции snapshot оценивают состояния конкурирующих транзакций и возможность модификации записей именно от Oldest transaction до Next transaction. Собственно, при чтении версий, номер транзакций которых меньше Oldest transaction, сервер даже не проверяет наличие версий"
http://www.ibase.ru/sweep/
Но если честно мне все это не интересно :)
Мне интересно только одно, чтобы свип не тупил в случае форсмажора.
...
Рейтинг: 0 / 0
25.10.2017, 13:39
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541720
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Евгений Килин,

не путай сборку мусора и свип. 99% что в твоём случае началась именно сборка мусора, а не запустился автосвип.
Что касается самого свипа, то 2.5.3 было существенное ускорение в некоторых случаях CORE-3994 Тут ещё жаркая дискуссия по этому поводу была
...
Рейтинг: 0 / 0
25.10.2017, 13:50
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541729
Евгений Килин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Килин
Участник
Симонов ДенисЕвгений Килин,

не путай сборку мусора и свип. 99% что в твоём случае началась именно сборка мусора, а не запустился автосвип.
Что касается самого свипа, то 2.5.3 было существенное ускорение в некоторых случаях CORE-3994 Тут ещё жаркая дискуссия по этому поводу была
Да не путаю я свип и сборку мусора :))
Я прекрасно понимал, что проблема с мусором и параллельными точечными селектами зачистил несколько критичных ИДшников.
В моем случае версия была выше 2.5.3.
...
Рейтинг: 0 / 0
25.10.2017, 13:56
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541750
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakovсборка мусора, которая во всех существующих
версиях имеет O(N^2) алгоритм сбора ключей.Ты снова трындишь, не зная о чём
...
Рейтинг: 0 / 0
25.10.2017, 14:08
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541783
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladТы снова трындишь, не зная о чём

Ты готов отрицать, что процедура list_staying() для получения каждой новой версии проходит
заново всю их цепочку, начиная с головной?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 14:27
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541790
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakov,

посмотри когда она вызывается и что нового вокруг неё в новых версиях.
А потом трынди про регулярную сборку мусора и про все существующие версии...
...
Рейтинг: 0 / 0
25.10.2017, 14:33
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541809
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladпосмотри когда она вызывается и что нового вокруг неё в новых версиях.

Во-первых, если ты забыл, трэд в девеле, приведший к CORE-4935 начал именно я:
https://sourceforge.net/p/firebird/mailman/message/32332647/

Во-вторых, ТС-у с его 2.5 от этого не легче.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 14:55
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541821
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakov,

перечитай ту ветку, свой нынешний трындёж и на что именно я тебе ответил.
И - нет - не она привела к появлению CORE-4935.
И - нет - ты никому не открыл глаза, проблема была известна задолго до этого.
...
Рейтинг: 0 / 0
25.10.2017, 15:05
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541940
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladперечитай ту ветку, свой нынешний трындёж и на что именно я тебе ответил.

А теперь перечитай свой код и подумай в каком случае вызывается старый, неэффективный
вариант процедуры.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 17:29
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541941
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 17:31
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39541995
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Мимопроходящий,

у кого раздвоение ? Если шо - я справа, с усами ;)
...
Рейтинг: 0 / 0
25.10.2017, 18:58
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39542003
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Евгений КилинЯ прекрасно понимал, что проблема с мусором и параллельными точечными селектами зачистил несколько критичных ИДшников.
тогда при чем тут OIT ???
...
Рейтинг: 0 / 0
25.10.2017, 19:19
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39542007
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
hvlad> Если шо - я справа, с усами ;)

Осталось выяснить, кто тот дылда рядом... :)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.10.2017, 19:21
| Ответить | Цитировать | Написать  
Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
    #39542513
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
hvladя справа, с усами

и тут я словил нарушение констрейнта и выпал в дамп
...
Рейтинг: 0 / 0
26.10.2017, 14:39
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird 2.5.2 - контроль работы sweep на большой базе (350Гб)
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&tid=1561363]:
 0ms
get settings:
 8ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 49ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 15ms
total:  154ms
созд. / загр.: 154ms
x
x
Закрыть


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