Потрібен вступ до Транзакційних Черг Подій (TxEventQ)? Перегляньте мою вступну статтю про TxEventQ.
Налаштування продуктивності є критично важливим для забезпечення ефективності, надійності та чутливості обробки подій TxEventQ. Коли системи масштабуються і обсяг подій збільшується, погані оптимізації можуть призвести до затримок, вузьких місць або навіть збоїв системи. Використовуючи техніки, описані в цій статті, адміністратори TxEventQ можуть значно покращити пропускну здатність, зменшити затримки та покращити стабільність додатків, орієнтованих на події.
Розподіл (Partitioning)/Шардинг і кілька споживачів
Oracle Database автоматично керує розподіленням (також відомим як шардинг) черги, що відповідає розділу таблиці. Коли повідомлення ставляться в чергу, кожне повідомлення маршрутизується до конкретного розділу черги. Повідомлення в межах одного розділу зберігають суворий порядок на рівні сеансу.
Якщо обсяг черги змінюється, розділи можуть бути динамічно створені за потребою, наприклад, коли таблиця черги розширюється через чергу повідомлень. Коли всі повідомлення зняті з черги і більше не потрібні, розділ обрізається і стає доступним для повторного використання. Більша кількість розділів для кожної черги покращує продуктивність зняття повідомлень через паралелізацію споживачів, але потребує додаткової пам'яті та ресурсів бази даних.
Якщо ви хочете вручну встановити кількість розділів для черги, ви можете зробити це за допомогою процедури SETQUEUEPARAMETER. Нижче наведений SQL скрипт створює чергу та налаштовує її на 5 розділів/шардів і встановлює маршрутизацію повідомлень за ключем. Маршрутизація за ключем дозволяє виробникам маршрутизувати повідомлення до конкретного шардо, надаючи ключ повідомлення під час постановки в чергу.
begin
dbms_aqadm.create_transactional_event_queue(
queue_name => 'partitioned_queue',
queue_payload_type => DBMS_AQADM.JMS_TYPE,
multiple_consumers => true
);
-- Встановіть кількість розділів/шардів у черзі на 5
dbms_aqadm.set_queue_parameter('partitioned_queue', 'SHARD_NUM', 5);
-- Розділ/шард для поставлених повідомлень визначається за ключем повідомлення
dbms_aqadm.set_queue_parameter('partitioned_queue', 'KEY_BASED_ENQUEUE', 1);
-- Запустіть чергу
dbms_aqadm.start_queue(
queue_name => 'partitioned_queue'
);
end;
/
Рекомендується уникати створення глобальних індексів на розподіленій таблиці, що підтримує чергу. Локальні індекси також зазвичай не рекомендуються і можуть призвести до зниження продуктивності.
Створення розподіленої теми Kafka
Наступний фрагмент Java коду створює тему TxEventQ з 5 розділами, використовуючи Kafka Java Client для Oracle Database Transactional Event Queues. Тема my_topic може мати до 5 окремих потоків споживачів на кожну групу споживачів, що збільшує паралелізацію.
Properties props = // Параметри підключення до Oracle Database
NewTopic topic = new NewTopic("my_topic", 5, (short) 1);
try (Admin admin = AdminClient.create(props)) {
admin.createTopics(Collections.singletonList(topic))
.all()
.get();
} catch (ExecutionException | InterruptedException e) {
// Обробка помилки створення теми
}
Зверніть увагу, що ви можете використовувати будь-яку кількість виробників на тему, як потрібно, хоча рекомендується переконатися, що споживачі здатні споживати повідомлення принаймні так швидко, як вони виробляються, щоб уникнути створення черги повідомлень та зниження пропускної здатності повідомлень.
Кеш повідомлень
TxEventQ включає спеціалізований кеш повідомлень, який дозволяє адміністраторам балансувати використання System Global Area (SGA) і продуктивність черги.
Управління використанням SGA в TxEventQ сприяє підвищенню пропускної здатності, зменшенню затримок та дозволяє збільшити паралельність. У поєднанні з розподіленням, кешування повідомлень зменшує потребу в певних запитах, операціях DML та індексах. Кеш найбільш ефективний, коли споживачі можуть встигати за виробниками, і коли він достатньо великий, щоб зберігати повідомлення (включаючи вантаж) для всіх споживачів і виробників, що використовують TxEventQ.
Кеш повідомлень використовує пул Oracle Database Streams. Ви можете налаштувати виділення пам'яті для пулу Streams, використовуючи процедури DBMS_AQADM SETMINSTREAMS_POOL та SETMAXSTREAMS_POOL.
Налаштування системних параметрів
Системні параметри можна змінювати відповідно до вашої установки бази даних та обсягу подій для покращення продуктивності TxEventQ. У цій секції описано основні параметри для оптимізації TxEventQ та надано основи роботи з системними параметрами.
Щоб оновити системний параметр, використовуйте команду ALTER SYSTEM. Наступний запит встановлює параметр SGA_TARGET на 2 ГБ.
alter system set sga_target = 2G scope = both;
Область дії параметра може бути MEMORY, SPFILE або BOTH:
- MEMORY: зміни застосовуються до поточної інстанції без оновлення файлу параметрів.
- SPFILE: зміни застосовуються до файлу параметрів і доступні після наступного перезапуску.
- BOTH: зміни застосовуються динамічно до поточної інстанції, оновлюючи як пам'ять, так і файл параметрів.
Наступний запит повертає поточне значення параметра SGA_TARGET:
select name, value, isdefault, issys_modifiable, ismodified
from v$parameter
where name = 'sga_target';
DBBLOCKSIZE
Рекомендується використовувати стандартний розмір блоку 8k. Розмір блоку бази даних не можна змінити після її створення.
JAVAPOOLSIZE
Параметр JAVAPOOLSIZE вказує розмір (в байтах) пулу Java, який використовується менеджером пам'яті Java для операцій, пов'язаних з Java, таких як визначення методів і класів, а також Java об'єктів під час виконання. Якщо параметр SGATARGET не встановлений, за замовчуванням він становить 24 МБ. Параметр JAVAPOOL_SIZE можна змінювати через ALTER SYSTEM, і його діапазон залежить від операційної системи.
OPEN_CURSORS
Параметр OPENCURSORS визначає максимальну кількість відкритих курсорів, яку може мати сеанс в Oracle. Значення за замовчуванням — 50, і його можна налаштувати в межах від 0 до 65535. Якщо у вас велика кількість виробників і споживачів, дуже важливо встановити це значення достатньо високим, щоб уникнути вичерпання курсорів. Ви можете змінити OPENCURSORS, використовуючи команду ALTER SYSTEM.
PGAAGGREGATETARGET
Параметр PGAAGGREGATETARGET вказує на загальну кількість пам'яті, доступної для Program Global Area (PGA), яку використовують серверні процеси для таких задач, як сортування та об'єднання. За замовчуванням він становить 10 МБ або 20% від розміру SGA, залежно від того, яке значення більше. Він модифікований і допомагає оптимізувати SQL операції шляхом коригування пам'яті для робочих областей. Якщо встановити значення 0, управління пам'яттю переходить у ручний режим.
Щоб встановити жорстке обмеження для агрегованої пам'яті PGA, використовуйте параметр PGAAGGREGATELIMIT.
PROCESSES
Параметр PROCESSES визначає максимальну кількість операційних систем, які можуть одночасно підключатися до бази даних. Це важливо для керування фоновими процесами, такими як блокування, черги завдань і паралельне виконання.
Навантаження з великою кількістю виробників і споживачів може вимагати коригування цього параметра. Налаштування цього значення може потребувати переоцінки пов'язаних параметрів, таких як SESSIONS і TRANSACTIONS.
SESSIONS
Параметр SESSIONS визначає максимальну кількість сеансів, які можуть бути створені в базі даних Oracle. За замовчуванням він розраховується як (1,5 * PROCESSES) + 22 і може бути змінений у діапазоні від 1 до 65,536. Цей параметр впливає на кількість одночасних користувачів і фонових процесів. Для Плагінових Баз Даних (PDB) параметр SESSIONS можна налаштувати, але його значення не може перевищувати значення кореневої контейнерної бази. Ви повинні налаштувати кількість сеансів в залежності від очікуваних з'єднань та фонового навантаження, включаючи навантаження черг.
SGA_TARGET
Параметр SGATARGET вказує на загальний розмір Shared Global Area (SGA) в Oracle, дозволяючи автоматичне керування пам'яттю для її компонентів, таких як кеш буфера, спільний пул та інші. Його значення може бути в межах від 64 МБ до SGAMAXSIZE. Параметр можна змінювати через ALTER SYSTEM. Якщо значення параметра встановлено в нуль, автоматичне налаштування SGA вимкнено. Системи, які активно використовують чергування повідомлень, повинні налаштувати параметр SGATARGET на достатньо велике значення, щоб максимально використовувати кешування повідомлень черги.
Якщо параметр SGA_TARGET вказаний, то наступні пам'ятні пулі автоматично налаштовуються:
- Кеш буфера (DBCACHESIZE)
- Спільний пул (SHAREDPOOLSIZE)
- Великий пул (LARGEPOOLSIZE)
- Пул Java (JAVAPOOLSIZE)
- Пул Streams (STREAMSPOOLSIZE)
- Кеш для передачі даних (DATATRANSFERCACHE_SIZE)
STREAMSPOOLSIZE
Параметр STREAMSPOOLSIZE визначає розмір пулу Streams — спільної пам'ятної області, що використовується для TxEventQ та інших функцій бази даних. Якщо параметри SGATARGET і STREAMSPOOL_SIZE обидва не рівні нулю, то Oracle Database автоматичне керування спільною пам'яттю використовує це значення як мінімум для пулу Streams.
Якщо параметри STREAMSPOOLSIZE і SGA_TARGET обидва встановлені в 0, то при першому запиті на пам'ять пулу Streams буде передано 10% пам'яті від спільного пулу кешу буфера до пулу Streams.
Запитання? Дайте знати в коментарях або зверніться через LinkedIn!
Перекладено з: Performance Tuning Oracle Database Transactional Event Queues