Алексей Рагозин "Java и linux борьба за микросекунды"

Deutsche Bank Technology Centre
Deutsche Bank
Java и Linux
Борьба за микросекунды
Алексей Рагозин

1
Deutsche Bank Technology Center
Deutsche Bank Алексей Рагозин
United Dev Conf 2017
Типовая архитектура торговой системы
Client
Connectivity
Order
Management
System
Exchange
Connectivity
Settelment
Risk
Managment
Trade
Life Cycle
Other
Downstreams

1
Ultra Low Latency
Время отклика системы – десятки/сотни микросекунд
Колокация – обработка в рамках одного ЦОД
Специализированное сетевое оборудование
Прямая работа с сетевым стеком из прикладного кода

1
Realtime
Гарантированное время отклика
Требуется поддержка на уровне ОС
Время отклика не обязательно малое
Как правило, hard real time системы не отличаются
высокой производительностью

1
Архитектура

1
Архитектура в стиле JEE
Business
Logic
RDBMS
Message Broker Message Broker

1
Архитектура в стиле JEE
Business
Logic
RDBMS
Message Broker Message Broker
2 Phase Commit
Send message
Commit SQL transaction
Acknowledge message

1
Двухфазный коммит (2PC)
Достоинства
Стандартизация X/Open, XA
Гарантия однократной обработки
Широкая поддержка
Недостатки
Распределённый коммит увеличивает время отклика
Синхронный коммит между разными ресурсами

1
Альтернатива 2PC
Сквозная нумерация сообщений
Брокер хранит диапазон сообщений
Потребитель может “проиграть”
сообщения с произвольного номера
Потребитель сам хранит номер последнего сообщения
Распределённая транзакция не требуется

1
Секвенсирование сообщений
Journal Channel
OutboundInbound
Business
Logic
Sequencing
Channel
Channel
Publishing
DB
Async consumers
Change
Log
?

1
Восстановление после сбоя
Каждый канал хранит номер последней транзакции
При восстановлении
 Находим минимальный номер транзакции по всем каналам
 Проигрываем журнал с этого номера
 Каждый канал игнорирует уже отправленные сообщения
Требуется строго детерменированная бизнес логика!
 Обработка входного сообщения должна быть повторяемой
 Временные метки считаются в момент секвенсирования
 Состояние бизнес объектов хранится в памяти

1
Секвенсирования сообщений
 Нет распределённой транзакции
 Выходные каналы не тормозят друг друга
 Запись в журнал параллельно с бизнес логикой
 Возможность “тёплого” резервирования
 Требование к детерменированной бизнес логике
 Полное состояние бизнес объектов в памяти

1
Прикладной код

1
Конвейерная обработка
Network
Receive
Unmarshal
Business
logic
Jouranling
Network
Send
Marshal

1
Конвейерная обработка
 Однопоточная детерминированная бизнес логика
 Однопоточные структуры данных
 Возможность привязки потоков к ядрам
 Спекулятивное выполнение
 Параллельная обработка только на уровне стадий
 Нельзя применять “блокирующие” операции в бизнес логике

1
Оптимизации времени отклика
Чистка кода
 Логирование
 toString() дорогая операции
 Необходимо проверять включён ли логер перед форматированием сообщения
 Исключения
 Обработка исключений медленная
 Исключения должны использоваться в неисключительной логике
 Reflection
 Минимизация использования рефлекшена
 При использовании надо кэшировать метаданные

1
Мусор
Сборка мусора в JVM неизбежна
 Наша цель – 99ый перцентиль
 Настройка сборщика мусора
Concurrent Mark Sweep алгоритм
Паузы можно укоротить используя больше CPU
Интервал между паузами можно увеличить
 Оптимизации кода
Уменьшение выделения памяти там, где это оправдано
 GC не единственный неконтролируемый источник задержек

1
Garbage free coding
Garbage free
 Проблемы с многопоточностью
 Сложная логика
переиспользования объектов
Immutable objects
 Слишком много мусора
 Неоптимальные
структуры данных
Immutable objects Garbage free
Holistic Low Latency

1
Синхронизация
Стоимость межпоточной синхронизации
Свободный ресурс – быстрый путь
Медленная операция с памятью (compare and set)
Загруженный ресурс – медленный путь
Вход в ядро (context switch)
Ожидание

1
Context Switch Cost
Синхронизация требует вызов ядра ОС,
что требует переключения контекста CPU (context switch)
Стоимость переключение контекста
Переключение контекста – единицы микросекунд
Сброс кэшей CPU – десятки микросекунд
Ожидание в очереди на CPU – сотни микросекунд

1
Context Switch Cost
http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

1
Цена многопоточности
Атомарные операции с памятью < 1 мкс
 Lock free структуры данных
 Блокирующая синхронизация быстрый путь
Быстрое переключение контекста ~ X * 10 мкс
 Выполнение на выделенном ядре
Медленное переключение контекста ~ X * 100 мкс
 Перескакивание по ядрам

1
LINUX

1
“Зелёный” Linux
По-умолчанию, в большинстве дистрибутивов Linux
включён режим энергосбережения
 Уменьшение частоты ядра, при малой загрузке
 Используются специальные режимы ожидания ядер
Это негативно влияет на время отклика

1
Своп
Linux может вытеснять страницы памяти приложения для
дискового кэша.
В случае Java приложений это может серьёзно увеличить
время отклика.
 /proc/sys/vm/swappiness <- 0
 swap off - радикальная мера

1
Привязка потоков
Цель – обеспечить выполнение потоков
конвейера на выделенных ядрах.
 Поток Java – обычный поток OS
 taskset позволяет привязать поток к ядру
 ID потока можно получить через jstack
 Привязанный поток будет выполняться на выделенном ядре

1
Изоляция ядер
Даже если поток привязан к ядру, другие потоки имеют
возможность его вытеснить
 isolcpus – параметр ядра Linux, который позволяет исключить
ядра из пула планировщика
 taskset позволяет потокам выполнятся на isolcpus ядрах

1
NUMA
Non-Uniform Memory Architecture (NUMA)
 Различные ядра имеют разное время доступа
к разным банкам памяти.
 Обычно память процесса распределена по всем банкам
 numactl позволяет ограничить банки памяти используемые
для определённого процесса

1
Стратегия настройки Linux
CPU 0 CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6 CPU 7 CPU 32 CPU 33 CPU 34 CPU 35 CPU 36 CPU 37 CPU 38 CPU 39
NUMA Node 0
Critical threads Default task set
GC Threads
isolcpus
NUMA Node 1
NUMA Node 2
NUMA Node 3

1
Стратегия настройки Linux
Одна NUMA нода целиком выделяется под приложение.
 NUMA нода целиком исключается из планировщика (isolcpus)
 Приложение запускается под numactl и taskset
 Критические потоки привязываются к выделенным ядрам
 Остальные потоки привязываются к пулу свободных ядер на ноде
 GC потоки привязываются ко всем ядра NUMA ноды

1
Результаты оптимизации
Высокая нагрузка Низкая нагрузка
Медиана (Перцентиль 99) Микросекунды
 Исходная версия 1215 (8472) 2878 (23067)
 “Чистка кода” 774 (1273) 1197 (3738)
 Оптимизировано логирование
 Убран рефлекшен
 Включены “спинлоки”
 Настройка Linux 611 (765) 684 (873)
 Зафиксированы частоты ядер
 numactl + taskset + isocpus

1
Спасибо
Алексей Рагозин
http://blog.ragozin.info
alexey.ragozin@gmail.com

1
33
Данный материал не является предложением или предоставлением какой-либо услуги.
Данный материал предназначен исключительно для информационных и иллюстративных
целей и не предназначен для распространения в рекламных целях. Любой анализ третьих
сторон не предполагает какого-либо одобрения или рекомендации. Мнения, выраженные в
данном материале, являются актуальными на текущий момент, появляются только в этом
материале и могут быть изменены без предварительного уведомления. Эта информация
предоставляется с пониманием того, что в отношении материала, предоставленного здесь,
вы будете принимать самостоятельное решение в отношении любых действий в связи с
настоящим материалом, и это решение является основанным на вашем собственном
суждении, и что вы способны понять и оценить последствия этих действий. ООО
“Технологический Центр Дойче Банка" не несет никакой ответственности за любые убытки
любого рода, относящихся к этому материалу.

Алексей Рагозин "Java и linux борьба за микросекунды"

More Related Content

What's hot

Similar to Алексей Рагозин "Java и linux борьба за микросекунды"

More from IT Event

Алексей Рагозин "Java и linux борьба за микросекунды"