powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сборка мусора
25 сообщений из 50, страница 1 из 2
Сборка мусора
    #39735370
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал очень простой тест для FB2.5 (полагаю, что относится к любым версиям FB):
1. Создал таблицу (не важно какую) с длинным полем varchar(5000) - для наглядности
2. Добавил в таблицу 1 запись
3. Запустил транзакцию T1 read_committed,rec_version,nowait (для удержания Oldest active)
2. Запустил цикл из 10000 итераций, в котором:
2.1 Запускается транзакция T2 read_committed,rec_version,nowait
2.2 Обновляется запись (каждый раз генерируется случайный текст из 5000 символов)
2.3 Коммитится транзакция T2

В результате gstat показывает ожидаемую разницу между "Oldest active" и "Next transaction" (те самые 10000 итераций).
При этом размер базы: 85 МБайт. В ней очень много версий этой одной записи.

Вопрос наверное звучит странно: почему Firebird, зная что транзакция "Oldest active" является "read_committed" и видя что все остальные транзакции между "Oldest active" и "Next transaction" закомичены, не хочет признавать версии записей мусором?
...
Рейтинг: 0 / 0
Сборка мусора
    #39735372
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSerСделал очень простой тест для FB2.5 (полагаю, что относится к любым версиям FB):Повтори на снапшоте fb4 и больше так не полагай :)
...
Рейтинг: 0 / 0
Сборка мусора
    #39735376
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSer,

дело не в "признании", а в необходимости "выкусывания" лишних версий, что (до ФБ 4) считалось сложным и не нужным.
...
Рейтинг: 0 / 0
Сборка мусора
    #39735437
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для тех кто не читал fbdevel. Если я правильно понимаю промежуточная сборка мусора вообще изначально не планировалась и идея возникла случайно. Николай предложил патч для реализации Statement Consistency в Read Committed, и предложил чтобы этот режим работал в Firebird 4.0 по умолчанию для Read Committed. Были заданы уточняющие вопросы из которых выяснилось, что в таком режиме даже транзакция RC RO будет удерживать мусор, что естественно вызвало недовольство, особенно программистов на Delphi. Потом в беседу вступил Джим и сказал что возможно в Firebird можно сделать промежуточную сборку мусора, чтобы уменьшить негативные последствия. Николай изучил этот вопрос и реализовал эту промежуточную сборку мусора. Ну а Влад потом доводил до ума и портировал в 4.0. Спасибо всем разработчикам за проделанную работу.

hvladПовтори на снапшоте fb4 и больше так не полагай

я пробовал. Промежуточные версии действительно отлично чистятся. Но одна версия всё равно остаётся пока читающая транзакция не завершена, даже когда она read committed и все записи курсора отфетчены (таблица содержит всего одну запись). Не знаю правильно это или нет (в любом случае лучше чем раньше). Если так не должно быть могу вечером написать воспроизводимый пример. Если так и должно быть, то не мог бы ты пояснить почему, ведь формально снапшот для курсора в RC из которого отфетчены все записи больше не нужен. Мешают BlobId?
...
Рейтинг: 0 / 0
Сборка мусора
    #39735482
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЕсли так и должно бытьДа, так и должно быть.

Предыдущая версия нужна той тр-ции, которая делает апдейт\делит.
Её снимок никто не отменял.
Да и куда откатываться, в случае роллбека ?
...
Рейтинг: 0 / 0
Сборка мусора
    #39735504
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad,

тот кто делал апдейт/делит уже закомичен. Схема теста приблизительно такая

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
-- сессия 1
set transaction read commited read consistency;
update t set a=a;

-- сессия 2
set transaction read commited read consistency;
select count(*) from t;

-- сессия 1
commit;



я могу сколько угодно делать в сессии 1 start trasaction -> update -> commit

gstat будет показывать длину цепочки версий 1

select count(*) from t;
могу тоже сколько угодно раз повторять ничего не меняется. Как только делаем в сессии 2 commit gstat показывает длину цепочки версий 0
...
Рейтинг: 0 / 0
Сборка мусора
    #39735516
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисКак только делаем в сессии 2 commit gstat показывает длину цепочки версий 0Коммит сбросил кеш на диск.
gstat читает данные с диска сам, без движка.
...
Рейтинг: 0 / 0
Сборка мусора
    #39735847
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad,

честно говоря не понял. Коммит транзакции которая делает update разве не сбрасывает кеш на диск?
gstat я через сервисы запускаю, да и полностью рестартую каждый раз

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
RECREATE TABLE T (
    ID  INTEGER NOT NULL,
    A   INTEGER,
    CONSTRAINT PK_T PRIMARY KEY (ID)
);

insert into t (id, a) values (1, 1);

commit;



сессия 1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
set list on;
commit;
set transaction read committed read consistency;
select
  id,
  a,
  cast(rdb$get_context('SYSTEM', 'ISOLATION_LEVEL') as varchar(20)) as ISOLATION_LEVEL,
  current_transaction,
  rdb$record_version as rec_version,
  RDB$GET_TRANSACTION_CN(rdb$record_version) as record_cn,
  cast(rdb$get_context('SYSTEM', 'SNAPSHOT_CN') as bigint) as SNAPSHOT_CN,
  cast(rdb$get_context('SYSTEM', 'GLOBAL_CN') as bigint) as GLOBAL_CN
from  t;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ID                              1
A                               1
ISOLATION_LEVEL                 READ COMMITTED
CURRENT_TRANSACTION             1664
REC_VERSION                     1568
RECORD_CN                       398
SNAPSHOT_CN                     493
GLOBAL_CN                       493

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Analyzing database pages ...
T (129)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 12.00, total records: 1
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 12.00, compression ratio: 1.00

сессия 2
Код: sql
1.
2.
3.
4.
commit;
set transaction read committed read consistency;
update t set a=a;
commit;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Analyzing database pages ...
T (129)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 12.00, total records: 1
    Average version length: 9.00, total versions: 1, max versions: 1
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 12.00, compression ratio: 1.00

сессия 2
Код: sql
1.
2.
set transaction read committed read consistency;
update t set a=a;



сессия 1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
commit;
set transaction read committed read consistency;
select
  id,
  a,
  cast(rdb$get_context('SYSTEM', 'ISOLATION_LEVEL') as varchar(20)) as ISOLATION_LEVEL,
  current_transaction,
  rdb$record_version as rec_version,
  RDB$GET_TRANSACTION_CN(rdb$record_version) as record_cn,
  cast(rdb$get_context('SYSTEM', 'SNAPSHOT_CN') as bigint) as SNAPSHOT_CN,
  cast(rdb$get_context('SYSTEM', 'GLOBAL_CN') as bigint) as GLOBAL_CN
from  t;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ID                              1
A                               1
ISOLATION_LEVEL                 READ COMMITTED
CURRENT_TRANSACTION             1685
REC_VERSION                     1677
RECORD_CN                       505
SNAPSHOT_CN                     512
GLOBAL_CN                       512

Код: plaintext
1.
2.
3.
4.
5.
T (129)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 12.00, total records: 1
    Average version length: 9.00, total versions: 1, max versions: 1
    Average fragment length: 0.00, total fragments: 0, max fragments: 0

сессия 2
Код: sql
1.
commit;



Код: plaintext
1.
2.
3.
4.
5.
T (129)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 12.00, total records: 1
    Average version length: 9.00, total versions: 1, max versions: 1
    Average fragment length: 0.00, total fragments: 0, max fragments: 0

сессия 1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
commit;
set transaction read committed read consistency;
select
  id,
  a,
  cast(rdb$get_context('SYSTEM', 'ISOLATION_LEVEL') as varchar(20)) as ISOLATION_LEVEL,
  current_transaction,
  rdb$record_version as rec_version,
  RDB$GET_TRANSACTION_CN(rdb$record_version) as record_cn,
  cast(rdb$get_context('SYSTEM', 'SNAPSHOT_CN') as bigint) as SNAPSHOT_CN,
  cast(rdb$get_context('SYSTEM', 'GLOBAL_CN') as bigint) as GLOBAL_CN
from  t;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ID                              1
A                               1
ISOLATION_LEVEL                 READ COMMITTED
CURRENT_TRANSACTION             1685
REC_VERSION                     1683
RECORD_CN                       517
SNAPSHOT_CN                     526
GLOBAL_CN                       526

сессия 1
Код: sql
1.
commit;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Analyzing database pages ...
T (129)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 12.00, total records: 1
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 12.00, compression ratio: 1.00
...
Рейтинг: 0 / 0
Сборка мусора
    #39735849
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисКоммит транзакции которая делает update разве не сбрасывает кеш на диск?Сбрасывает. И в этот момент на диске две версии.

Потом ты запускаешь select в новой тр-ции, он собирает мусор.
Но очищенные страницы живут в кеше FB и gstat их не видит.

Симонов Денисgstat я через сервисы запускаю, да и полностью рестартую каждый разСервисы\не сервисы - он всё равно с диска читает, а не из кеша FB.
...
Рейтинг: 0 / 0
Сборка мусора
    #39735852
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad,

о как! Спасибо за разъяснения. А я то надеялся увидеть это живьём
...
Рейтинг: 0 / 0
Сборка мусора
    #39738393
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот такая жесть с транзакциями сейчас у клиента:
http://www.loginovprojects.ru/gstat-office.jpg

Если клиент остановит СУБД, то БД будет повреждена.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738397
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSerЕсли клиент остановит СУБД, то БД будет повреждена.С чего бы это ?
...
Рейтинг: 0 / 0
Сборка мусора
    #39738404
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSerЕсли клиент остановит СУБД, то БД будет повреждена.

ты откуда это взял?
...
Рейтинг: 0 / 0
Сборка мусора
    #39738428
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 раза уже было такое - в августе и в ноябре. Видимо, при закрытии всех программ срабатывает сборка мусора (может sweep, но в логи FB2.1 об этом не писал), а клиент завершает работу Windows (в последний раз отключили внешнее питание и нужно было выключить сервер, пока не сел бесперебойник). После этого базу приходилось восстанавливать с помощью gfix.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738434
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Такое чаще всего бывает, когда база уже повреждена (вы работаете с повреждённой базой), но не настолько, чтобы это вызвало аварийное завершение.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738440
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSer2 раза уже было такоеКакое ?
DmSerПосле этого базу приходилось восстанавливать с помощью gfix.Кроме орфанов что-то было ? А до того ?
...
Рейтинг: 0 / 0
Сборка мусора
    #39738442
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladКакое ?

База повреждалась. Оба раза довольно легко лечилась с помощью gfix.
После первого повреждения зависал SELECT к таблице, где много версий (там всего 150 записей, но каждая из них обновляется раз в минуту).
После второго повреждения проверка БД выдавала несколько тысяч ошибочных страниц с данными. При этом данные затронуты не были, проблема видимо была только со страницами, на которых хранились версии.

hvladКроме орфанов что-то было ? А до того ?

По сути в логах FB оба раза я видел только орфаны, причем по несколько миллионов.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738464
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSer,

орфаны <> повреждения

DmSerПосле первого повреждения зависал SELECT к таблице, где много версий (там всего 150 записей, но каждая из них обновляется раз в минуту).

не путай сборку мусора, которая и выглядит как зависание, с повреждениями.
Вариант 2 время уходит на восстановление записей из версий

>> там всего 150 записей, но каждая из них обновляется раз в минуту

ужас!!!!
И ещё 2.1 уже снят с поддержки вряд ли в нём что-то будет правится
...
Рейтинг: 0 / 0
Сборка мусора
    #39738470
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисне путай сборку мусора, которая и выглядит как зависание, с повреждениями.
Вариант 2 время уходит на восстановление записей из версий

Спутать невозможно. Клиент 6 часов ждал. Там именно зависание было.

Симонов ДенисИ ещё 2.1 уже снят с поддержки вряд ли в нём что-то будет правится

Зачем править Firebird? Проблема в моём софте, а не в Firebird.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738495
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
26.11.2018 12:19, DmSer пишет:
> Спутать невозможно. Клиент 6 часов ждал.
> Там именно зависание было.

"мамом клянусЪ, э!" (С)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сборка мусора
    #39738498
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий26.11.2018 12:19, DmSer пишет:
> Спутать невозможно. Клиент 6 часов ждал.
> Там именно зависание было.

"мамом клянусЪ, э!" (С)


Можно и так сказать. Клиент мне эту базу присылал (в состоянии "поврежденная"). Там FB при SELECT к этой несчастной таблице жрал одно ядро на 100%.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738501
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
26.11.2018 12:47, DmSer пишет:
> Можно и так сказать. Клиент мне эту базу присылал (в состоянии "поврежденная").
> Там FB при SELECT к этой несчастной таблице жрал одно ядро на 100%.

цепляться нужно было с отключенной сборкой мусора
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сборка мусора
    #39738506
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис>> там всего 150 записей, но каждая из них обновляется раз в минуту
ужас!!!!

вполне может быть ужас. Я наблюдал систему, где на классике повис один коннект с активной транзакцией, и висел он три дня.
Примерно в такой же мелкой таблице апдейтами за эти 3 дня нагенерилось 1.5млн версий. Даже если в этой таблице два целочисленных столбца, размер такой записи (с кучей версий) - под 50 мегабайт.
...
Рейтинг: 0 / 0
Сборка мусора
    #39738508
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv> 1.5млн версий. ... под 50 мегабайт.

И что, 3 дня чистилось? Не верю.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сборка мусора
    #39738509
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DmSer,

много orphan pages - результат обрубания коннекта, который много навставлял. Это не повреждение, просто результат ACID.
А вот зависание при сборке мусора, да еще на 6 часов - вполне может быть. Много индексов, хилое железо, плюс старый ФБ - вот и результат.

Другое дело, что
- за 9 дней 4 миллиона транзакций, это 460 тысяч транзакций в сутки.
- активная транзакция висела чуть больше 2х суток.

И возникает вопрос, кто такое приложение писал, что оно так работает.
...
Рейтинг: 0 / 0
25 сообщений из 50, страница 1 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сборка мусора
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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