|
|
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
Сталкивались с сабжем на вставке в таблицу? Обычно около 8% от времени выполнения, но при повышенной нагрузке(даже явно не связанной с таблицей куда вставляем) вырастает до 35%. Рак 18.7, таблица партиционированная. Индексы есть и локальные и глобальные, партиционированные по хэшу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 13:44 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
Melkomyagkii_newbi Рак Собственно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 14:26 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Melkomyagkii_newbi Рак Собственно странно что ранее не наблюдалось такой ситуации. правда не понятно когда началось, может после апгрейда с 12.2, может что-то в прикладном коде поменялось.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 14:32 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
Melkomyagkii_newbi andrey_anonymous пропущено... Собственно странно что ранее не наблюдалось такой ситуации. правда не понятно когда началось, может после апгрейда с 12.2, может что-то в прикладном коде поменялось.. Конкуренцию за глобальный кэш можно развести только тщательно продумывая привязку операций к узлам. Ранее не наблюдалось - к примеру, нагрузка была ниже и потому интерконнект справлялся шустрее. Или планы поменялись - к примеру, загрузка данных распараллелилась между нодами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 14:49 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Конкуренцию за глобальный кэш можно развести только тщательно продумывая привязку операций к узлам. Не совсем. Вот прямо сейчас именно этим и занимаюсь. Два (или более) клиента запрашивают примерно в то же время insurance quote. И попадают эти quotes в один и тот-же database block. Дальше начинается свистопляска - клиенты начинают изменять сумму страховки, deductible (у вас кажется франшиза), сумму медицинских выплат, и.т.д, и.т.п. для сравнения цены страховки. И начинаетcя нагрузка на GCS. А если посчитать среднее время "жизни" quote и среднее количество quotes за это время можно партицировать таблицу по остатку от деления QUOTE_ID на среднее количество quotes за среднее время "жизни" quote тем самым минимизировать ожидание сессии X пока GCS разбирается c изменениями блока сделанными сессией Y. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 15:55 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
SY партицировать таблицу по остатку от деления QUOTE_ID на среднее количество quotes за среднее время "жизни" quote тем самым минимизировать ожидание сессии X пока GCS разбирается c изменениями блока сделанными сессией Y. Интересно, спасибо. Но у ТС - массовая загрузка, если я правильно понял, а на этом паттерне играть с вероятностями несколько сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 16:04 |
|
||
|
gc index operation
|
|||
|---|---|---|---|
|
#18+
SY, Quote id генерируется не сиквенсом? Кстати, для похожих write-only таблиц я ещё использовал такой подход: добавлял автоматически заполняемое поле instance_id и секционировал по нему. В крайне редких случаях, когда были нужны все данные предикат по instance id просто не заполнялся. Для всяческих логов генерируемых в диком количестве и используемых крайне редко для анализа - самое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2020, 16:19 |
|
||
|
|
start [/forum/topic.php?fid=52&fpage=39&tid=1880995]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 138ms |
| 0 / 0 |
