powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Помогите советом, репликация
25 сообщений из 38, страница 1 из 2
Помогите советом, репликация
    #40083628
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Опишу ситуацию.
Есть самописный сервис репликации(синхронная), настроен на базу "концентратор" так сказать. Служба эта принимает данные от удаленных серверов, парсит, применят - все просто.
Проблемы поползли, когда этих удаленных серверов, которые кидают все свои данные в общую базу, стало 4 шт. То есть если с одного двух, все норм, данные применяются очень быстро, как только стало 4, все запросы, которые модифицируют данные начали тормозить, доходит до того что апдейт одной строки может 4-5 сек висеть.
Служба репл многопоточная, на каждый удаленный сервер создает тред, и уже в нем гоняет данные.
Пакеты репл парсятся в базе, и применяются с помощью execute statement. Служба к базе коннектится через пул соединений, пар транзакций - rc rec_version wait.
С чего бы можно было начать, как точно понять что начинает так сильно тормозить?
Сервер достаточно мощный(виртуалка), вейтов не вижу, проц не нагружен вообще, памяти свободной полно. 3.0.7 SS. Кеш задан 16гб, файловый кеш включен, fw включен, кеш на запись есть.
Подозрение только одно, что начинается конкуренция на запись, но как анализировать fb_lock_print я так и не разобрался.
Да и кто вообще может поможет с советом, как сделать лучше.
Если я сильно туплю и не вижу очевидных вещей, прошу прощения.
Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
LOCK_HEADER BLOCK
        Version: 146, Creation timestamp: 2021-07-03 19:37:07
        Active owner:      0, Length: 26214400, Used: 11458184
        Enqs: 2251485914, Converts: 9947181, Rejects: 158444555, Blocks: 9267903
        Deadlock scans:  35238, Deadlocks:      2, Scan interval:  10
        Acquires: 4532677690, Acquire blocks: 76914749, Spin count:   0
        Mutex wait: 1.7%
        Hash slots: 30011, Hash lengths (min/avg/max):    0/   0/   6
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners (368):   forward: 253144, backward: 2563376
        Free owners (328):      forward: 11065808, backward: 11105184
        Free locks (1553):      forward: 253672, backward: 1478904
        Free requests (39402):  forward: 4485968, backward: 3450704



Данные от удаленных серверов, по идее должны быть разными, то есть нет такого что потоки обновляют одни и те же строки данных.(но это так задуманно, на деле может быть наоборот)
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40083634
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992Служба к базе коннектится через пул соединений, пар транзакций - rc rec_version wait.
С чего бы можно было начать, как точно понять что начинает так сильно тормозить?

Начни с мониторинга чтобы удостовериться, что там именно rec_version, причём во всех
транзакциях.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40083640
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

Проверил,

Код: java
1.
props.setProperty("TRANSACTION_READ_COMMITTED", "isc_tpb_read_committed,isc_tpb_rec_version,isc_tpb_wait");



Сразу не написал, сервис на java, соотв с базой работает через jdbc.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40083645
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это откуда весёлые картинки? Формат не выглядит как у Firebird...

В любом случае трассируй вглубь, до уровня performance stats запросов. Может, там мусора тонна собирается или в триггерах таблицы мониторинга опрашиваются...
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40083712
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov
Это откуда весёлые картинки? Формат не выглядит как у Firebird...

В любом случае трассируй вглубь, до уровня performance stats запросов. Может, там мусора тонна собирается или в триггерах таблицы мониторинга опрашиваются...


Картинка из IBE, вкладки мониторинга.
А чем обычно делают этот трейс? Я пытался через ibe trace and audit, но либо я не понял как правильно им пользоваться, либо там ничего необычного нету.
Deadlock scans: 35238 - это нормально? На нормально работающей базе этот показатель сильно меньше, либо вообще 0.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40083784
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992,

видимо, надо вот это
http://www.ibase.ru/how_to_track_deadlocks/
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098413
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если кому интересно, таки нашел причину тормозов.
В базе ведется журнал репликации, и когда в нем накапливается приличное кол-во записей (в моем случае тормоза пошли на ~50млн), начинал тормозить запрос, который как раз таки работал с этой таблицей, не сильно, с 200-500 мс до 3 сек, но этого уже хватало чтобы ложить всю систему.
Так вот когда подписчику отдавались данные из журнала, ставилась отметка о том, что лог отправлен (в запросе который описан выше), т.е. был апдейт записи. Судя по всему, из-за этого апдейта появлялся лок на таблицу? страницу? индекс? и не давал другим тредам в фоне нормально применять данные, так как применение данных = вставка в таблицу журнала.
А проблема вся оказалась в тормозящей сортировке order by id, решилось все простым добавлением +0, т.е. сменой order на sort.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098420
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992(в моем случае тормоза пошли на ~50млн), начинал тормозить запрос,
это болезнь всех программных репликаторов - когда накапливается большое кол-во изменений, или запрос много обрабатывает, или плодятся версии, а если еще к тому же у приложений плохо с транзакциями (долго держат активными), то потом еще и сборка мусора начинается.
demon1992из-за этого апдейта появлялся лок на таблицу? страницу? индекс?
нет таких локов в ФБ. Т.е. локи страниц есть, но они крайне быстрые, и апдейт одной записи не приводит к длительной блокировке страницы, на которой эта запись находится.
У вас там в параметрах транзакции isc_tpb_wait - поэтому конкурирующая транзакция повиснет при обновлении УЖЕ обновленной в другой транзакции записи. В других ситуациях виснуть ничего не будет.
Зачем вам wait, собственно? Чего ждете? роллбэка конкурирующей транзакции?
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098446
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
нет таких локов в ФБ. Т.е. локи страниц есть, но они крайне быстрые, и апдейт одной записи не приводит к длительной блокировке страницы, на которой эта запись находится.

Вот и я так же всегда думал, ну не должно оно так тормозить, а на деле получилось, что из-за того что запрос начал отрабатывать вместо пол секунды три, пошли проблемы. Но, в запросе две команды - апдейт и за ним селект, поэтому у меня вывод такой и сложился, что из-за незакоммиченного апдейта начала тормозить вставка, что я тоже считаю нелогичным, но другого объяснения у меня нету. Никаких долгоживущих транзакций нету, мусора следовательно тоже нет, все это я проверил в первую очередь.

kdv
Зачем вам wait, собственно? Чего ждете? роллбэка конкурирующей транзакции?

Насчет этого тоже думал, но за столько лет работы с fb, я до сих пор не вдуплил, на что конкретно повлияет этот параметр. Да, я читал доки, смотрел видео и т.д. Но хотелось бы понять на простеньком примере, как это повлияет на работу системы, потому что в системе высокая нагрузка и непредвиденных ситуаций не хотелось бы получить.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098455
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvЧего ждете? роллбэка конкурирующей транзакции?

В нормальных случаях обычно таки да. Не имеет смысла изображать дятла и
нарываться на одну и ту же блокировку в цикле, лучше подождать пока она рассосётся.

Но у аффтара такая схема, что можно убиться одним фейспалмом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098462
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992поэтому у меня вывод такой и сложился
а получить gstat -r хотя бы по существенной таблице в запросе не судьба? Там сразу будет видно, есть версии, или нет.
demon1992Никаких долгоживущих транзакций нету
не верю. хотя бы gstat -h во время тормозов.
demon1992 хотелось бы понять на простеньком примере
транзакция 1 - старт, update table where id = 50
транзакция 2 - старт, update table wheren id = 50
если транзакция 2 nowait, update тут же выдаст ошибку (конфликт обновления). Если транзакция 2 wait - то она будет висеть до commit/rollback транзакции 1.
Собственно, всё. Вместо update может быть delete, без разницы, т.к. оба создают новую версию записи. Которую никакая другая транзакция обновить не может до commit/rollback исходной (где был update/delete).
Всё это написано в статьях много раз.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098464
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992,

и дополнение:
транзакция 1 - старт, ничего не делает.
транзакция 2, старт, update set ... where id = 50, commit
транзакция 3, старт, update set ... where id = 50, commit
транзакция 4, старт, update set ... where id = 50, commit
транзакция 5, старт, update set ... where id = 50, commit
в этот момент в таблице будет 1 запись с id =50 и ее 4 версии. То есть, читаемый "пакет" одной записи вырастет в размерах, и затормозит запрос.

транзация 1 - commit
в этот момент ничего не произойдет. А вот если кто-то начнет читать запись с id = 50 - возникнут тормоза, потому что начнется сборка мусора этой записи, т.к. старые ее версии уже никому не нужны. А "сборка мусора" - это чтение пакета версий, определение кто нужен и кто нет, и создание более свежей версии.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098488
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvв этот момент в таблице будет 1 запись с id =50 и ее 4 версии. То есть, читаемый
"пакет" одной записи вырастет в размерах, и затормозит запрос.

У аффтара ничего подобного быть не может, поскольку отметку "обработано" ставит
только репликатор, работающий по определению в единственном экземпляре. Грабли у
него зарыты глубже (в том числе в консерватории).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098497
alekcvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv
demon1992,

и дополнение:
транзакция 1 - старт, ничего не делает.
транзация 1 - commit

А я правильно понимаю, что если транзакция 1 - read commited, то это не актуально?..
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098518
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alekcvpА я правильно понимаю, что если транзакция 1 - read commited, то это не актуально?..
с ФБ 4 все совсем не так, там сборка мусора по другому работает.
А вот исходно, по идее вплоть до ФБ 3, есть специфическая фигня с read committed.
http://www.ibase.ru/summary/
надо докрутить до
"Когда ReadCommitted блокирует Oldest Snapshot?" Там есть описание последовательности транзакций, при которой уровень изолированности по барабану.
То есть, ситуация вполне себе не случайная или редкая - при read committed застревает oldest snapshot, а oldest snapshot это ориентир для сервера как граница превращения актуальной версии в мусор. Следовательно, вот такая череда read committed приводит к накоплению версий.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098607
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
не верю. хотя бы gstat -h во время тормозов.

Еще раз повторю - как только запрос начинает работать чуть дольше секунды, тормоза перманентные, никаких версий и долгоживущих транзакций нету, смысла мне выдумывать это.

Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Database header page information:
        Flags                   0
        Generation              47045267
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      46994210
        Oldest active           46994211
        Oldest snapshot         46994211
        Next transaction        46994212
        Sequence number         0
        Next attachment ID      1398472
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            1048576
        Next header page        0
        Database dialect        3
        Creation date           Jul 19, 2021 11:56:07
        Attributes              force write

    Variable header data:
        Sweep interval:         0
        *END*

...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098614
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992
что из-за того что запрос начал отрабатывать вместо пол секунды три, пошли проблемы. Но, в запросе две команды - апдейт и за ним селект, поэтому у меня вывод такой и сложился, что из-за незакоммиченного апдейта начала тормозить вставка, что я тоже считаю нелогичным, но другого объяснения у меня нет
В одной тр-ции сначала апдейт, а потом селект с тормозами. Другая тр-ция не может апдейтить эту запись до коммита первой (с селектом с тормозами).
Отсюда вопрос - каким образом разные потоки определяют что им обрабатывать ?
Могут ли они конкурировать за один и тот же пакет ?
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098622
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad,

В журнале логов хранится ид подписчита, ид пакета и два флага - отправлено и получено.
Служба при обращении подписчика к себе за получением новых данных, запускает процедуру с параметрами последнего принятого лога и ид подписчика. Апдейт принятых и отправленных логов идет только в этом месте, больше апдейтов нет нигде, ровно как и селектов к этой таблице. В триггерах только вставка новых данных в журнал.
Так вот когда процедура, с этим самым единственным апдейтом начинает работать дольще секунды, сразу начинаются тормоза на вставку новых данных в эту саму таблицу.
Вот я и пытаюсь понять, как такое может происходить.
Каждый поток работает только со своим набором данных, апдейт одних и тех же строк в разных потоках невозможен.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098630
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992
Каждый поток работает только со своим набором данных, апдейт одних и тех же строк в разных потоках невозможен.
Чем это гарантировано ?
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098632
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992,

трассировку включай.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098638
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad,

Запрос вызывается с параметром - ид потока, в каждом обращении к таблице в условии where id_subscriber=?
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098641
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992,

ок, значит конкуренция апдейтов отсутствует, по крайней мере в данном месте.
Откуда известно, что тормозит именно вставка ?
К совету насчёт трассировки я бы прислушался.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098643
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
demon1992Так вот когда процедура, с этим самым единственным апдейтом начинает работать
дольще секунды, сразу начинаются тормоза на вставку новых данных в эту саму таблицу.

Так, может, ты уже покажешь нам DDL "той самой таблицы" и текст "той самой
процедуры"? Чисто на поржать, ибо я и так догадываюсь что там.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098671
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
CREATE TABLE tbl (
    ID                bigint NOT NULL,
    ID_LOG    		  bigint NOT NULL,
    ID_SBSCR  		  bigint NOT NULL,
    STATE             int DEFAULT 0 NOT NULL,
    IS_SEND           int DEFAULT 0,
    DT_SEND           timestamp
);



/******************************************************************************/
/***                              Primary keys                              ***/
/******************************************************************************/

ALTER TABLE tbl ADD CONSTRAINT PK_tbl PRIMARY KEY (ID);


/******************************************************************************/
/***                              Foreign keys                              ***/
/******************************************************************************/

ALTER TABLE tbl ADD CONSTRAINT FK_tbl_LOG FOREIGN KEY (ID_LOG) REFERENCES tbl_log (ID);
ALTER TABLE tbl ADD CONSTRAINT FK_tbl_SBSCR FOREIGN KEY (ID_SBSCR) REFERENCES tbl_subscriber (ID);


/******************************************************************************/
/***                                Indices                                 ***/
/******************************************************************************/

CREATE INDEX idx1 ON tbl (ID_SBSCR, STATE);
CREATE INDEX idx2 ON tbl (ID_SBSCR, IS_SEND, STATE);


Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
create or alter procedure LOG_GET (
    ID_LOG_LATEST bigint,
    ID_SUBSCR bigint)
returns (
    id bigint,
    log_unit blob)
as
declare variable MAX_COUNT_LOG_SEND bigint = 100;
declare variable CNT_SND integer = 1;
begin
  update tbl_subscriber
  set ID_LOG_LATEST = :ID_LOG_LATEST
  where ID = :ID_SUBSCR;

  update tbl
  set STATE = 1
  where ID_LOG + 0 <= :ID_LOG_LATEST and
        ID_SBSCR = :ID_SUBSCR and
        IS_SEND = 1 and
        STATE = 0;

  select param
  from cfg
  where name = 'MAX_COUNT_LOG_SEND'
  into :MAX_COUNT_LOG_SEND;

  for select id_log,
             log_unit 
      from tbl T2
      left join tbl_log T1 on T1.ID = T2.ID_LOG
      where T2.ID_SBSCR = :ID_SUBSCR and
            T2.STATE = 0
      order by T2.ID_LOG + 0 asc
      into :id, :log_unit
  do
  begin
    if (:CNT_SND <= :MAX_COUNT_LOG_SEND) then
    begin
      update tbl
      set IS_SEND = 1,
          DT_SEND = localtimestamp
      where ID_LOG = :ID and
            ID_SBSCR = :ID_SUBSCR;

      CNT_SND = :CNT_SND + 1;
      suspend;
    end
    else
    begin
      break;
    end
  end
end



Только если есть на чем поржать, ты напиши пожалуйста, не стесняйся, я буду тебе очень признателен, а то будет выглядеть как пук в лужу.
...
Рейтинг: 0 / 0
Помогите советом, репликация
    #40098672
demon1992
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad

Откуда известно, что тормозит именно вставка ?

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


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