Вопрос или проблема
У меня есть экземпляр EC2, который я использую для подписки на живые данные. Я хочу собирать данные из нескольких потоков и сохранять их в базе данных postgres. В среднем я получаю около 10000 обновлений каждые 15 секунд (примерно одно обновление каждые 1,5 миллисекунды) для одного потока. Приложение, которое собирает данные, является многопоточным. Распределение числа ожидаемых обновлений довольно плотное: 99-й процентиль нагрузки, вероятно, составляет одно обновление каждую миллисекунду.
Я боюсь собирать слишком много потоков на одном экземпляре EC2, потому что это может вызвать некоторую очередность и/или перегрузки в данных, которые я собираю. Я уже выполняю пакетную обработку полученных обновлений, чтобы мне не нужно было так часто обновлять базу данных.
После проведения некоторых исследований, я считаю, что следующие два варианта являются жизнеспособными решениями. Я бы хотел услышать совет, какой из них может быть лучше, потому что мои знания Unix ограничены.
-
Подписаться на различные потоки на изолированных ядрах, чтобы ни одно ядро не выполняло слишком много работы. Я полагаю, это потребует использования
isolcpu, и я могу выделить одно ядро процессора для набора потоков websocket. Настройки по умолчанию, по-видимому, позволяют процессу выполняться на любых ядрах, которые предпочитает планировщик. -
Не выполнять изоляцию процессора. Запустить другие экземпляры EC2 и выполнять сбор данных на совершенно разных экземплярах EC2.
Какой из этих двух вариантов намного лучше другого, и есть ли какой-то более простой вариант, который я упускаю? Если вариант #1 окажется лучше, есть ли хороший способ определить, сколько потоков может обрабатывать одно ядро?
Спасибо.
Ответ или решение
Сбор данных высокой интенсивности из различных источников: оптимальные стратегии
Перед вами сложная задача по сбору интенсивных потоков данных с нескольких источников на платформе Amazon EC2 и их последующему сохранению в базе данных PostgreSQL. Средняя нагрузка составляет около 10 000 обновлений каждые 15 секунд, что эквивалентно одному обновлению каждые 1,5 миллисекунды. Учитывая, что ваше приложение многопоточное, важно эффективно распределить вычислительные ресурсы для поддержания стабильной работы системы. Рассмотрим ваши варианты более детально.
1. Изоляция процессоров с использованием механизма isolcpu
Этот вариант предполагает использование метода изоляции процессоров для распределения нагрузки. Используя isolcpu, вы можете выделить отдельные ядра CPU для обработки конкретных потоков данных, что позволяет снизить конкуренцию за ресурсы между потоками и минимизировать задержки. Однако данная стратегия требует детального понимания Linux и опыта работы с системными ресурсами, чтобы корректно настроить изоляцию и следить за эффективностью процессов.
Преимущества:
- Уменьшение конкуренции за вычислительные ресурсы.
- Снижение задержек и увеличение предсказуемости выполнения задач.
Недостатки:
- Сложность настройки и поддержки конфигурации.
- Может потребоваться значительное время на оптимизацию и настройку системы под нагрузку.
Как определить количество потока на ядро:
Для определения оптимальной нагрузки на одно ядро рекомендуется проводить нагрузочное тестирование. Вы можете использовать инструменты профилирования, такие как perf или htop, для оценки использования процессора и анализа узких мест.
2. Масштабирование через увеличение количества EC2 инстансов
Второй вариант включает в себя распределение нагрузки с использованием дополнительных инстансов EC2. Благодаря этому вы можете избежать перегрузки одного инстанса, распределив работу между несколькими машинами и повысив общую отказоустойчивость системы.
Преимущества:
- Повышение отказоустойчивости системы.
- Уменьшение риска затрудненного доступа к данным из-за перегрузки одного инстанса.
- Проще в настройке и управлении, не требуются особые знания Unix-систем.
Недостатки:
- Увеличение затрат на инфраструктуру из-за большего количества инстансов.
- Потребность в организации распределенной системы для совместной работы инстансов.
Рекомендация и альтернативные решения
С учетом ограниченных знаний Unix и сложности настройки изоляции процессоров, более практичным и легким в реализации решением будет второй вариант — расширение через развертывание нескольких EC2 инстансов. Это позволит вам быстрее достичь стабильности в работе вашей системы без глубоких изменений в конфигурациях ОС.
Кроме этих двух вариантов, стоит рассмотреть использование инструментов контейнеризации (например, Docker и Kubernetes), которые могут добавить дополнительный контроль над распределением нагрузок и помогут с масштабированием за счет оркестрации контейнеров.
Выбор правильной стратегии — это баланс между сложностью настройки, затратами на инфраструктуру и требованиями к производительности. В вашем сценарии важно учитывать как текущие, так и будущие потребности, например, возможность масштабирования системы по мере роста нагрузки.