Как улучшить пропускную способность интерфейса TUN при использовании Erlang TUNCTL
Я использую TUNCTL с {active, true} для получения пакетов UDP от интерфейса TUN. Процесс получает пакеты и отправляет их другому процессу, который работает, и отправляет их еще одному процессу, который выталкивает их в другой интерфейс с помощью gen_udp. Тот же процесс повторяется в обратном направлении, я использую gen_udp для получения пакетов и отправки их на интерфейс TUN.
Я начинаю видеть переполнения на входящем интерфейсе TUN, когда загрузка процессора близка к 50%, около 2500 пакетов / сек. Я не теряю пакетов на стороне gen_udp, только с помощью Tunctl. Почему мое приложение не получает все пакеты от интерфейса TUN, когда процессор не перегружен? Мой процесс не имеет сообщений в очереди сообщений.
Я играл с приоритетами процесса и размерами буфера, что мало что дало. Общая загрузка процессора имеет значение. Мне удалось снизить нагрузку на процессор, но, несмотря на небольшое увеличение пропускной способности интерфейса TUN, теперь он, кажется, максимально увеличивается при более низкой загрузке процессора, скажем, 50% вместо 60%.
TUNCTL/Procket не может читать пакеты достаточно быстро или TUNCTL/Procket не получает достаточное количество процессорного времени по какой-то причине? Моя теория состоит в том, что Erlang Scheduler не знает, сколько ему нужно времени, поскольку он вызывает NIF, и он не знает о количестве необработанных сообщений на интерфейсе TUN. Нужно ли мне пачкать руки с C++ и / или писать свой собственный NIF? MSANTOS HELP!
1 ответ
Как и ожидалось, проблема была в том, что TUNCTL не получал достаточное количество процессорного времени, когда активен true. Я использовал procket: read, который получает пакет из буфера TUN. Использование этого подхода позволяет указать, как часто следует проверять буфер, который сообщает Erlang Scheduler, сколько времени требуется вашему процессу. Это позволило мне загрузить CPU до 100%, если это необходимо, и позволило мне получать все пакеты с интерфейса TUN, который мне был нужен. Узкое место решено.