ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сборка мусора
50 сообщений из 50, показаны все 2 страниц
  все  
Сборка мусора
    #39735370
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
20.11.2018, 00:00
| Ответить | Цитировать | Написать  
Сборка мусора
    #39735372
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
DmSerСделал очень простой тест для FB2.5 (полагаю, что относится к любым версиям FB):Повтори на снапшоте fb4 и больше так не полагай :)
...
Рейтинг: 0 / 0
20.11.2018, 00:17
| Ответить | Цитировать | Написать  
Сборка мусора
    #39735376
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
DmSer,

дело не в "признании", а в необходимости "выкусывания" лишних версий, что (до ФБ 4) считалось сложным и не нужным.
...
Рейтинг: 0 / 0
20.11.2018, 00:26
| Ответить | Цитировать | Написать  
Сборка мусора
    #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
20.11.2018, 09:50
| Ответить | Цитировать | Написать  
Сборка мусора
    #39735482
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов ДенисЕсли так и должно бытьДа, так и должно быть.

Предыдущая версия нужна той тр-ции, которая делает апдейт\делит.
Её снимок никто не отменял.
Да и куда откатываться, в случае роллбека ?
...
Рейтинг: 0 / 0
20.11.2018, 11:03
| Ответить | Цитировать | Написать  
Сборка мусора
    #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
20.11.2018, 11:43
| Ответить | Цитировать | Написать  
Сборка мусора
    #39735516
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов ДенисКак только делаем в сессии 2 commit gstat показывает длину цепочки версий 0Коммит сбросил кеш на диск.
gstat читает данные с диска сам, без движка.
...
Рейтинг: 0 / 0
20.11.2018, 12:01
| Ответить | Цитировать | Написать  
Сборка мусора
    #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
20.11.2018, 22:25
| Ответить | Цитировать | Написать  
Сборка мусора
    #39735849
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов ДенисКоммит транзакции которая делает update разве не сбрасывает кеш на диск?Сбрасывает. И в этот момент на диске две версии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

И возникает вопрос, кто такое приложение писал, что оно так работает.
...
Рейтинг: 0 / 0
26.11.2018, 13:02
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738522
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
kdvИ возникает вопрос, кто такое приложение писал, что оно так работает.

Сам в шоке!

Это БД эмитента топливных карт в Иркутске. У него более 4000 контрагентов, половина из которых работает через личный кабинет. Плюс каждую минуту репликация срабатывает, видимо и она нехилое количество новых транзакций открывает.
Также у него несколько десятков АЗС (меньше сотни), каждая их которых каждые 15 секунд выполняет запрос в офис.
Плюс еще при выполнении некоторых запросов то ли IBX то ли Firebird стартует для внутренних целей дополнительную короткую транзакцию.
И всё это на FB2.1 SuperServer x86.
...
Рейтинг: 0 / 0
26.11.2018, 13:13
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738536
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
DmSer,

неужели суперсервер FB2.1 справляется? Я до 3.0 вообще супер старался не использовать ни где.


kdvПримерно в такой же мелкой таблице апдейтами за эти 3 дня нагенерилось 1.5млн версий. Даже если в этой таблице два целочисленных столбца, размер такой записи (с кучей версий) - под 50 мегабайт.

мда... Тут по идее 4.0 должен облегчить страдания вот таких программ, но частично
...
Рейтинг: 0 / 0
26.11.2018, 13:33
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738548
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Симонов ДенисDmSer,

неужели суперсервер FB2.1 справляется? Я до 3.0 вообще супер старался не использовать ни где.


Летом они хоть перевели на современный сервер (как раз в тот момент первое повреждение было). А до этого обычная XP-ка стояла с 2 ГБ ОЗУ, причём на виртуалке.
Как-то FB и тогда справлялся.

А теперь всё летает! :)
...
Рейтинг: 0 / 0
26.11.2018, 13:41
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738572
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Стараемся следить, чтобы все запросы исполнялись максимально быстро. Если проблем с запросами нет, то и SS на одном ядре справляется. Если запросы будут тормозить, то и Classic загнётся. При этом в системе громадное количество мелких запросов (по сложности сложности SELECT FIELD FROM RDB$DATABASE). Не факт, что с Classic будет шустрее (хотя везде по возможности пул подключений используется). Сейчас у клиента 16 ГБ ОЗУ, можно попробовать на SuperClassic перевести.
...
Рейтинг: 0 / 0
26.11.2018, 14:12
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738578
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
o_v_a
Участник
Мимопроходящийцепляться нужно было с отключенной сборкой мусора

Ээээ... Кстати, не везде это получится. Вот как это сделать из php, к примеру, через стандартное дополнение ibase?!
У меня была такая потребность недавно.С использованием клиентских библиотек или с прямым доступом сколько угодно, no_garbage_collect - это хорошо.А вот с ПыхПых проблема.
...
Рейтинг: 0 / 0
26.11.2018, 14:19
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738589
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
26.11.2018 14:19, o_v_a пишет:
> Ээээ... Кстати, не везде это получится. Вот как это сделать из php, к примеру, через стандартное дополнение ibase?!
> У меня была такая потребность недавно.С использованием клиентских библиотек или с прямым доступом сколько угодно, no_garbage_collect - это хорошо.А вот с ПыхПых проблема.

с BDE тоже не всё в шоколадзЭ
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.11.2018, 14:28
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738608
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
o_v_a,

у вас в БД только пых пишет?
...
Рейтинг: 0 / 0
26.11.2018, 14:50
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738691
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
o_v_a
Участник
Не, только веб-сервисы.

Оффтоп, раз уж заикнулся:
У одного клиента на днях после массовой чистки старых данных (удалили несколько десятков миллионов записей из нескольких таблиц) сервер начал помирать - диски не справлялись.
Я было захотел упростить ему существование, используя no_garbage_collect.
Посрубал все некритичные коннекты, явно натравил на базу gfix -sweep, тот яро вгрызся делать записям expunge. И, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло.
Ну не умеет php в модуле ibase произвольные параметры использовать при формировании DPB.

Потому просто периодически раз в 5-7 часов снимал клиенту лишнюю нагрузку с сервера, прикрывая часть внешних коннектов (нельзя было полностью перекрывать доступ, часть сервисов должна была работать при любых условиях).

А gfix лопатил базу (хоть и небольшая, 15 Гигов) 27 часов!
Там швах с дисковой подсистемой - база на зеркале на интегрированном в Intel-чипсет контроллере на обычной десктопной материнке, админы местные в курсе, сами такое захотели, но не от хорошей жизни.
...
Рейтинг: 0 / 0
26.11.2018, 17:13
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738703
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
o_v_aИ, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло.Запусти isql, открой в нём тр-цию (не RCRO), просто выполнив любой запрос - и всё. Сборка мусора заблокирована.
Но имей в виду - sweep не волшебник, он точно так же не сможет собирать мусор.
...
Рейтинг: 0 / 0
26.11.2018, 17:29
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738704
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
o_v_a,

в индексах ключи мусорных записей удалял.
После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро.

o_v_aПосрубал все некритичные коннекты, явно натравил на базу gfix -sweep, тот яро вгрызся делать записям expunge. И, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло.

На SS можно было на это время перевести чисто на фоновую сборку мусора. Единственное что с рестартом сервиса FB.

Впрочем gfix всё равно тормозил бы дисковую.
...
Рейтинг: 0 / 0
26.11.2018, 17:33
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738801
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Ну вот, опять проблема с этой базой. Попросил клиента отключить все приложения подключенные к базе данных, затем остановить службу. После этого службу запустили и выполнили gfix -v -full
Выдал: Number of record level errors : 1

Кстати, gfix -sweep после этого отработал моментально. Видимо, мусор был собран при первом вызове gfix.
Похоже, Firebird 2.1 SS также в шоке от такого количества транзакций :)
Firebird 2.1 там один из последних (2.1.5 от 2016г.)
...
Рейтинг: 0 / 0
26.11.2018, 20:49
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738817
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
DmSerПохоже, Firebird 2.1 SS также в шоке от такого количества транзакций :)
не в количестве транзакций дело. Самих транзакций могут быть мульоны, но если в них обновляется мало записей, версий будет тоже мало.
А если одна транзакция засандалит апдейт по 10млн записей - так и будет 10млн версий при одной транзакции.

А 2.1.5, это, конечно, обалдеть какая свежая версия. Я обычно рекомендую скачать релизноты к действительно последней 2.1, и почитать раздел багфиксов.
https://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes217.html#rnfb210-v217
...
Рейтинг: 0 / 0
26.11.2018, 21:52
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738858
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Глючу наверное. У меня даты файлов для 2.1.5 отображаются 19.07.2016. Странно...
...
Рейтинг: 0 / 0
26.11.2018, 23:24
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738912
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
o_v_a
Участник
Симонов Денисo_v_a,
в индексах ключи мусорных записей удалял.
После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро.

Дропнуть первичный индекс на живой базе с двумя десятками коннектов, активно работающих с этой таблицей - без шансов скорее всего.
Кстати, этот здоровенный индекс так и остался с глубиной 4, а он мне нужен там после чистки с глубиной 3. И тыщи страниц в нём (6 тыщ из 18) с заполнением 0-19%. Ну, се-ля-ви, это поправится только бэкапом-рестором.
Абориген-админ (бабушка - божий одуванчик) уже запланировала ночные работы.
...
Рейтинг: 0 / 0
27.11.2018, 08:31
| Ответить | Цитировать | Написать  
Сборка мусора
    #39738981
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
DmSerГлючу наверное. У меня даты файлов для 2.1.5 отображаются 19.07.2016. Странно...

Видимо пару лет назад на компе, где собирался инсталлятор нашего ПО, хозяйничал вирус, затем его лечили, в результате EXE-файлы из каталога FIREBIRD\bin оказались изменены.
...
Рейтинг: 0 / 0
27.11.2018, 11:02
| Ответить | Цитировать | Написать  
Сборка мусора
    #39749970
Cobalt747
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cobalt747
Участник
Симонов Денисo_v_a,
в индексах ключи мусорных записей удалял.
После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро.

Подскажите, в такой ситуации - было бы быстрее отключить индексы, провести сборку и включить индексы обратно?
...
Рейтинг: 0 / 0
19.12.2018, 10:22
| Ответить | Цитировать | Написать  
Сборка мусора
    #39749973
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Cobalt747,

PK, FK всё равно не отключишь
...
Рейтинг: 0 / 0
19.12.2018, 10:25
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750157
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
Симонов ДенисCobalt747,

PK, FK всё равно не отключишь

Я что-то смутно вспоминаю про прямой апдейт rdb$index_inactive. Склерозничаю или раньше прокатывало, а теперь нет?
...
Рейтинг: 0 / 0
19.12.2018, 13:32
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750167
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Старый плюшевый мишкаЯ что-то смутно вспоминаю про прямой апдейт rdb$index_inactive.

В трёшке такие трюки запретили. И я сомневаюсь что раньше они работали. Да и сборка мусора в индексах хитро выполняется. Но тут пожалуй что Влад может прояснить.
...
Рейтинг: 0 / 0
19.12.2018, 13:44
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750206
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
o_v_a
Участник
Зато всегда (и тогда, и сейчас) их можно удалить, а потом заново создать.
...
Рейтинг: 0 / 0
19.12.2018, 14:25
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750308
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
o_v_a,

слишком много геморроя. Базу надо остановить. Работать в ней всё это время нельзя. А если ещё и ошибка при этом произойдёт, то база запорота будет.
...
Рейтинг: 0 / 0
19.12.2018, 16:34
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750330
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
o_v_a
Участник
Так то по обстоятельствам. Если очень надо, то пути решения имеются. Главное - это знать, где инструмент сельхозназначения разбросан.
...
Рейтинг: 0 / 0
19.12.2018, 16:51
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750679
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
19.12.2018 13:44, Симонов Денис пишет:
> В трёшке такие трюки запретили. И я сомневаюсь что раньше они работали.

не сумлевайся.
нормально всё отключается, и ПК и ФК.
но вот взыграл "синдром вахтёра" и лавочку прикрыли.
не пущать и воспрещать!
ога.

> Да и сборка мусора в индексах хитро выполняется. Но тут пожалуй что Влад может прояснить.

не знаю как сейчас, а в полуторке после массовых операций насилия над таблицей
отключение индексов помогало даже тогда, когда процесс сборки мусора уже стартовал.
причем эффект был значительный.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.12.2018, 11:45
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750724
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Мимопроходящий,

в полуторке сборка мусора в индексах с хреновой селективностью вообще была печальной. В двушке это правили и теперь стало намного лучше.

Но тем не менее сборку мусора в индексах всё равно быстрой назвать нельзя.
ИХМО. Ситуацию в ряде случаев могли бы улучшать частичные индексы, секционирование и табличные пространства.
...
Рейтинг: 0 / 0
20.12.2018, 12:38
| Ответить | Цитировать | Написать  
Сборка мусора
    #39750782
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Симонов ДенисИ я сомневаюсь что раньше они работали.
там магическое число в столбце активности использовалось. не 0 или 1, а 3. При ресторе так делается. В метаданных пишется активность 3, заливаются данные, а в конце уже индексы переводятся в активное состояние.
Так что, для PK, FK и UNIQUE можно было троечку поставить, коммит, а потом опять 1 (или что там) и коммит.
...
Рейтинг: 0 / 0
20.12.2018, 13:26
| Ответить | Цитировать | Написать  
50 сообщений из 50, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сборка мусора
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1560869]:
 0ms
get settings:
 8ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 157ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 66ms
get tp. blocked users:
 1ms
others: 12ms
total:  273ms
созд. / загр.: 273ms
x
x
Закрыть


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