Назад | Перейти на главную страницу

Пропускная способность Haproxy на виртуальной машине

Я новичок в HAProxy, но мне удалось наладить функциональность, хотя я не получаю ожидаемой пропускной способности.

Моя установка включает в себя 5-узловой кластер хранения (с Riak CS, хранилище в стиле S3) и другую виртуальную машину с HAProxy с roundrobin. Все виртуальные машины используют VirtualBox, каждая на выделенном компьютере. Виртуальная машина HAProxy работает под управлением Windows 7, а остальные - под управлением Windows 10. Все это находится в одной гигабитной сети, и я протестировал как 1.4, так и 1.5 для HAProxy.

У меня есть сценарий (python + boto), который загружает без сохранения на диск файлы размером 100 МБ снова и снова, и я считаю, что каждый из них должен сводиться к простому запросу на получение, и я запускаю этот сценарий локально 3 раза для дополнительной нагрузки.

Если я наведу их все на IP-адрес HAProxy, я получу примерно 4-500 Мбит / с загрузки, в то время как я могу получить до 900+ Мбит / с, если я НЕ использую HAProxy и укажу каждый на отдельный IP-адрес.

При выполнении этого теста похоже, что HAProxy максимально использует одно ядро ​​и становится узким местом. Для одного запущенного скрипта, который, как я считаю, является одним подключением, он потребляет 20-40% ядер процессора на HAProxy, что кажется подозрительным?

Это звучит как HAProxy может справиться с высокой пропускной способностью поэтому я пытаюсь отладить, где я мог неправильно настроить все, либо в Ubuntu, либо в файле конфигурации HAProxy. Я вижу минимальное улучшение, используя nbproc 3 в конфигурации нагрузка определенно не сбалансирована между 3 процессами, так как один все еще исчерпан.

Что-нибудь в этой настройке, например виртуальные машины, может стать красным флажком? Звучит ли моя конфигурация haproxy виновником? Или мои общие настройки Ubuntu? Также стоит спросить, хороший или плохой вариант использования HAProxy?

РЕДАКТИРОВАТЬ

Мне нужно еще покопаться, но сейчас я чувствую, что это специфично для виртуальной машины, возможно, в драйвере Ethernet (e1000)? Мне удалось перенести настройку HAProxy на физический компьютер (не виртуальную машину), и на одном ядре он почти не зарегистрировал какое-либо использование процессора с моим предыдущим тестовым примером ...

полная конфигурация

global
    #log 127.0.0.1   local0
    #log 127.0.0.1   local1 notice
    maxconn 256000
    spread-checks 5
    daemon 
    nbproc 4 
    cpu-map 1 2
    cpu-map 2 3
    cpu-map 3 4
    cpu-map 4 5

defaults
    option dontlog-normal
    option  redispatch
    option  allbackups
    no option   httpclose
    retries 3
    maxconn 256000
    contimeout  5000
    clitimeout  5000
    srvtimeout  5000

    option forwardfor except 127.0.0.1

frontend riak_cs
    bind          *:8098
    bind          *:8080
    mode          http
    capture       request header Host len 64

    acl d1 dst_port 8098
    acl d2 dst_port 8080

    use_backend   riak_cs_backend_stats if d1
    use_backend   riak_cs_backend if d2



backend riak_cs_backend
    mode http 
    balance roundrobin
    option httpchk GET /riak-cs/ping
    timeout connect 60s
    timeout http-request 60s

    stats enable
    stats uri /haproxy?stats

    server riak1 192.168.80.105:8080 weight 1 maxconn 1024 check inter 5s 
    server riak2 192.168.80.106:8080 weight 1 maxconn 1024 check inter 5s
    server riak3 192.168.80.107:8080 weight 1 maxconn 1024 check inter 5s
    server riak4 192.168.80.108:8080 weight 1 maxconn 1024 check inter 5s
    server riak5 192.168.80.109:8080 weight 1 maxconn 1024 check inter 5s

backend riak_cs_backend_stats 
    mode http
    balance roundrobin
    timeout connect 60s
    timeout http-request 60s

    stats enable 
    stats uri /haproxy?stats

    server riak1 192.168.80.105:8098 weight 1 maxconn 1024 
    server riak2 192.168.80.106:8098 weight 1 maxconn 1024
    server riak3 192.168.80.107:8098 weight 1 maxconn 1024
    server riak4 192.168.80.108:8098 weight 1 maxconn 1024 
    server riak5 192.168.80.109:8098 weight 1 maxconn 1024 

Мне не нравится отвечать на свой вопрос, но я думаю, что мой вывод таков, что мой тест ограничен виртуальной машиной. Я не могу точно сказать, как именно так, но использование процессора HAProxy через мою виртуальную машину было намного, намного выше, и, как я отмечал выше, тестирование на физическом оборудовании с той же конфигурацией, даже удаление nbproc часть, я вижу едва заметную загрузку процессора в HAProxy.

В мои задачи не входило запускать что-либо производственное через виртуальные машины, но они намного удобнее для тестирования (в ожидании реального оборудования) и изучения того, как это работает.

Поскольку вы не показали ни свою конфигурацию, ни используемую версию (см. Мой комментарий), это немного похоже на «стрельбу в темноту». В любом случае, вы можете попробовать закрепить каждый HAProxy процесс на одно конкретное ядро, чтобы попытаться максимально использовать их все и выровнять нагрузку между ними.

Цитата из документов:

cpu-map <"all"|"odd"|"even"|process_num> <cpu-set>...

В Linux 2.6 и выше можно привязать процесс к определенному набору ЦП. Это означает, что процесс никогда не будет запущен на других процессорах. В cpu-map Директива определяет наборы ЦП для наборов процессов. Первый аргумент - это номер процесса для привязки. Этот процесс должен иметь номер от 1 до 32 или 64, в зависимости от размера слова машины, и любые идентификаторы процесса выше nbproc игнорируются. Можно указать сразу все процессы, используя all, только нечетные числа с использованием odd или даже числа с использованием even, как и с bind-process директива. Второй и последующий аргумент - это наборы ЦП. Каждый набор ЦП представляет собой либо уникальный номер от 0 до 31 или 63, либо диапазон с двумя такими числами, разделенными тире ('-'). Можно указать несколько номеров или диапазонов ЦП, и процессам будет разрешено связываться со всеми из них. Очевидно, несколько cpu-map директивы могут быть указаны. Каждый cpu-map Директива заменит предыдущие, когда они перекрываются.

Итак, если вы используете три процесса, проверьте следующее:

cpu-map 1 0
cpu-map 2 1
cpu-map 3 2