|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
Опишу ситуацию. Есть самописный сервис репликации(синхронная), настроен на базу "концентратор" так сказать. Служба эта принимает данные от удаленных серверов, парсит, применят - все просто. Проблемы поползли, когда этих удаленных серверов, которые кидают все свои данные в общую базу, стало 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.
Данные от удаленных серверов, по идее должны быть разными, то есть нет такого что потоки обновляют одни и те же строки данных.(но это так задуманно, на деле может быть наоборот) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 18:41 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992Служба к базе коннектится через пул соединений, пар транзакций - rc rec_version wait. С чего бы можно было начать, как точно понять что начинает так сильно тормозить? Начни с мониторинга чтобы удостовериться, что там именно rec_version, причём во всех транзакциях. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 18:49 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Проверил, Код: java 1.
Сразу не написал, сервис на java, соотв с базой работает через jdbc. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 19:14 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
Это откуда весёлые картинки? Формат не выглядит как у Firebird... В любом случае трассируй вглубь, до уровня performance stats запросов. Может, там мусора тонна собирается или в триггерах таблицы мониторинга опрашиваются... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 19:26 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Это откуда весёлые картинки? Формат не выглядит как у Firebird... В любом случае трассируй вглубь, до уровня performance stats запросов. Может, там мусора тонна собирается или в триггерах таблицы мониторинга опрашиваются... Картинка из IBE, вкладки мониторинга. А чем обычно делают этот трейс? Я пытался через ibe trace and audit, но либо я не понял как правильно им пользоваться, либо там ничего необычного нету. Deadlock scans: 35238 - это нормально? На нормально работающей базе этот показатель сильно меньше, либо вообще 0. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 09:44 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
Если кому интересно, таки нашел причину тормозов. В базе ведется журнал репликации, и когда в нем накапливается приличное кол-во записей (в моем случае тормоза пошли на ~50млн), начинал тормозить запрос, который как раз таки работал с этой таблицей, не сильно, с 200-500 мс до 3 сек, но этого уже хватало чтобы ложить всю систему. Так вот когда подписчику отдавались данные из журнала, ставилась отметка о том, что лог отправлен (в запросе который описан выше), т.е. был апдейт записи. Судя по всему, из-за этого апдейта появлялся лок на таблицу? страницу? индекс? и не давал другим тредам в фоне нормально применять данные, так как применение данных = вставка в таблицу журнала. А проблема вся оказалась в тормозящей сортировке order by id, решилось все простым добавлением +0, т.е. сменой order на sort. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 01:44 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992(в моем случае тормоза пошли на ~50млн), начинал тормозить запрос, это болезнь всех программных репликаторов - когда накапливается большое кол-во изменений, или запрос много обрабатывает, или плодятся версии, а если еще к тому же у приложений плохо с транзакциями (долго держат активными), то потом еще и сборка мусора начинается. demon1992из-за этого апдейта появлялся лок на таблицу? страницу? индекс? нет таких локов в ФБ. Т.е. локи страниц есть, но они крайне быстрые, и апдейт одной записи не приводит к длительной блокировке страницы, на которой эта запись находится. У вас там в параметрах транзакции isc_tpb_wait - поэтому конкурирующая транзакция повиснет при обновлении УЖЕ обновленной в другой транзакции записи. В других ситуациях виснуть ничего не будет. Зачем вам wait, собственно? Чего ждете? роллбэка конкурирующей транзакции? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 03:24 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
kdv нет таких локов в ФБ. Т.е. локи страниц есть, но они крайне быстрые, и апдейт одной записи не приводит к длительной блокировке страницы, на которой эта запись находится. Вот и я так же всегда думал, ну не должно оно так тормозить, а на деле получилось, что из-за того что запрос начал отрабатывать вместо пол секунды три, пошли проблемы. Но, в запросе две команды - апдейт и за ним селект, поэтому у меня вывод такой и сложился, что из-за незакоммиченного апдейта начала тормозить вставка, что я тоже считаю нелогичным, но другого объяснения у меня нету. Никаких долгоживущих транзакций нету, мусора следовательно тоже нет, все это я проверил в первую очередь. kdv Зачем вам wait, собственно? Чего ждете? роллбэка конкурирующей транзакции? Насчет этого тоже думал, но за столько лет работы с fb, я до сих пор не вдуплил, на что конкретно повлияет этот параметр. Да, я читал доки, смотрел видео и т.д. Но хотелось бы понять на простеньком примере, как это повлияет на работу системы, потому что в системе высокая нагрузка и непредвиденных ситуаций не хотелось бы получить. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 14:16 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
kdvЧего ждете? роллбэка конкурирующей транзакции? В нормальных случаях обычно таки да. Не имеет смысла изображать дятла и нарываться на одну и ту же блокировку в цикле, лучше подождать пока она рассосётся. Но у аффтара такая схема, что можно убиться одним фейспалмом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 15:54 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
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). Всё это написано в статьях много раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 19:21 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
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 - возникнут тормоза, потому что начнется сборка мусора этой записи, т.к. старые ее версии уже никому не нужны. А "сборка мусора" - это чтение пакета версий, определение кто нужен и кто нет, и создание более свежей версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 19:26 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
kdvв этот момент в таблице будет 1 запись с id =50 и ее 4 версии. То есть, читаемый "пакет" одной записи вырастет в размерах, и затормозит запрос. У аффтара ничего подобного быть не может, поскольку отметку "обработано" ставит только репликатор, работающий по определению в единственном экземпляре. Грабли у него зарыты глубже (в том числе в консерватории). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 22:28 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
kdv demon1992, и дополнение: транзакция 1 - старт, ничего не делает. транзация 1 - commit А я правильно понимаю, что если транзакция 1 - read commited, то это не актуально?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2021, 01:06 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
alekcvpА я правильно понимаю, что если транзакция 1 - read commited, то это не актуально?.. с ФБ 4 все совсем не так, там сборка мусора по другому работает. А вот исходно, по идее вплоть до ФБ 3, есть специфическая фигня с read committed. http://www.ibase.ru/summary/ надо докрутить до "Когда ReadCommitted блокирует Oldest Snapshot?" Там есть описание последовательности транзакций, при которой уровень изолированности по барабану. То есть, ситуация вполне себе не случайная или редкая - при read committed застревает oldest snapshot, а oldest snapshot это ориентир для сервера как граница превращения актуальной версии в мусор. Следовательно, вот такая череда read committed приводит к накоплению версий. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2021, 13:49 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 10:36 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992 что из-за того что запрос начал отрабатывать вместо пол секунды три, пошли проблемы. Но, в запросе две команды - апдейт и за ним селект, поэтому у меня вывод такой и сложился, что из-за незакоммиченного апдейта начала тормозить вставка, что я тоже считаю нелогичным, но другого объяснения у меня нет Отсюда вопрос - каким образом разные потоки определяют что им обрабатывать ? Могут ли они конкурировать за один и тот же пакет ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 10:57 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
hvlad, В журнале логов хранится ид подписчита, ид пакета и два флага - отправлено и получено. Служба при обращении подписчика к себе за получением новых данных, запускает процедуру с параметрами последнего принятого лога и ид подписчика. Апдейт принятых и отправленных логов идет только в этом месте, больше апдейтов нет нигде, ровно как и селектов к этой таблице. В триггерах только вставка новых данных в журнал. Так вот когда процедура, с этим самым единственным апдейтом начинает работать дольще секунды, сразу начинаются тормоза на вставку новых данных в эту саму таблицу. Вот я и пытаюсь понять, как такое может происходить. Каждый поток работает только со своим набором данных, апдейт одних и тех же строк в разных потоках невозможен. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 11:20 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992 Каждый поток работает только со своим набором данных, апдейт одних и тех же строк в разных потоках невозможен. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 11:43 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992, трассировку включай. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 11:45 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
hvlad, Запрос вызывается с параметром - ид потока, в каждом обращении к таблице в условии where id_subscriber=? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 11:59 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992, ок, значит конкуренция апдейтов отсутствует, по крайней мере в данном месте. Откуда известно, что тормозит именно вставка ? К совету насчёт трассировки я бы прислушался. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 12:22 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
demon1992Так вот когда процедура, с этим самым единственным апдейтом начинает работать дольще секунды, сразу начинаются тормоза на вставку новых данных в эту саму таблицу. Так, может, ты уже покажешь нам DDL "той самой таблицы" и текст "той самой процедуры"? Чисто на поржать, ибо я и так догадываюсь что там. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 12:23 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
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.
Код: 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.
Только если есть на чем поржать, ты напиши пожалуйста, не стесняйся, я буду тебе очень признателен, а то будет выглядеть как пук в лужу. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 14:06 |
|
Помогите советом, репликация
|
|||
---|---|---|---|
#18+
hvlad Откуда известно, что тормозит именно вставка ? Потому что на базе крутится только служба реплики, она ничего кроме вставки данных не делает. Проверял trace and audit, который в ibe есть, задержка непосредственно на командах модификации. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 14:10 |
|
|
start [/forum/topic.php?fid=40&msg=40098488&tid=1559935]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
142ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 237ms |
total: | 484ms |
0 / 0 |