Использование Flume для получения данных и хранения данных в канале памяти и отправки данных в kafka.Хотя vmstat нашел потоки Java много переключений контекста.Используя jstack для поиска идентификатора потока, в конце концов обнаружил, что потоки netty io и потоки отправителя kafka производят множество переключений контекста.
Мой senario выглядит следующим образом:
Один экземпляр потокана одной физической машине (32 ядра ЦП, 128 ГБ памяти, пропускная способность сети 1 ГБ как внутри, так и снаружи).
Прослушивание 4141 с использованием протокола Avro для получения данных, источник Avro использует нетто-сервер внутри, настроить 1 поток босса и 20 рабочих потоков.
Наличие 200 TCP длинных соединений от 100 агентов.Каждый агент открывает 2 подключения к этому серверу Flume, отправляя большое количество данных на этот сервер Flume, поскольку на агентском сервере генерируется большое количество журналов.
При получении скорости до 150 МБ / си скорость передачи 200 МБ / с, загрузка ЦП Flume-сервера 27 (не так ли высока, верно? потому что у него 32 ядра), но ОС cswch / s до 100000+ и nvcswch / s до 60000+.В то же время мы обнаружили, что некоторые агенты больше не могут отправлять данные.
Linux tcp сокеты r_mem и другие параметры уже настроены на 16 МБ.
Мои вопросы следующие:
Действительно ли узкое место меняет контекст?Должен ли я использовать BIO от netty из-за большой передачи данных, высокой пропускной способности и длинных TCP-соединений 200-300?Но сколько потоков я должен использовать для BIO, чтобы полностью использовать высокую полосу пропускания?
NIO epoll вызовет много переключений контекста, потому что как только один сокет будет готов к чтению, он будет сигнализировать чтение рабочих потоков, называемых LT в netty, верно?
У нас есть 200-300 розеток, и каждая розетка активна почти все время.Netty хорош в звуках коротких TCP-соединений и небольшой передачи данных, верно?
Как разрешить рабочему потоку читать как можно больше данных без такого большого количества сигналов epoll?