====== Настройка радиус ====== \\ Настройка радиуса будет касаться данных строк: max_request_time = 9 cleanup_delay = 10 max_requests = 2097152 ... thread pool { start_servers = 1 max_servers = 128 min_spare_servers = 8 max_spare_servers = 32 max_requests_per_server = 3000 max_queue_size = 1048576 auto_limit_acct = no } \\ Рассмотрим эти параметры: \\ **max_request_time** \\ Максимально время за которое ядро биллинга должно обработать запрос и вернуть результат \\ \\ **cleanup_delay** \\ После получения результата, радиус будет хранить этот "результат" у себя в памяти на случай если результат не дойдет до BRAS сервера и BRAS заново отправит запрос. \\ \\ **max_requests** \\ Размер того самого хранилища для результатов, которые радиус будет хранить в памяти пока не очистит \\ \\ **start_servers** \\ Минимальное кол-во возможных потоков для обработки запросов авторизации \\ \\ **max_servers** \\ Максимальное кол-во потоков для обработки запросов авторизации \\ \\ **min_spare_servers** \\ Минимальное кол-во потоков которое может находится в состоянии "ожидания" \\ \\ **max_spare_servers** \\ Максимальное кол-во потоков которое может находится в состоянии "ожидания" \\ \\ **max_requests_per_server** \\ Максимальное кол-во запросов которое может обработать один поток, после чего он будет перезапущен ( 0 - без ограничения ) \\ \\ **max_queue_size** \\ Размер очереди для запросов авторизации (1048576 это максимальное значение, при таком значении радиус потербляет на ~1Gb больше памяти) \\ \\ **auto_limit_acct** \\ Ограничение accounting запросов \\ \\ \\ \\ Теперь посмотрим на изображение ниже {{:billing:radius_threads.png?700|}} \\ У радиуса есть “очередь” куда он помещает все запросы. Размер этой очереди определяет параметр **max_queue_size**. \\ Если очередь будет переполнена, то любые новые запросы будут отклонены в silent режиме (то есть без каких либо уведомлений в логи). \\ \\ Как и написано в документации радиуса, переполнение очереди возможно при медленной обработке запросов и при резком скачке запросов авторизации. \\ Обработкой запросов в очереди занимаются “рабочие потоки”, задача которых: * взять запрос из очереди * отправить его на ядро биллинга (через модуль perl) * дождаться ответа. \\ После чего цикл повторяется. Соответственно чем больше потоков тем лучше. ====== Как подобрать параметры ====== \\ Для начала посмотрим на это изображение, на нем показано как работают параметры **start_servers**, **max_servers**, **min_spare_servers**, **max_spare_servers** {{:billing:radius_config.png?700|}} \\ При минимальной нагрузке будет создано 8 потоков (min_spare_servers), по мере нагрузки они могут увеличиться максимум до 32 потоков (max_servers). \\ Если нагрузка начнет уменьшаться то количество потоков будет уменьшено до 24 (max_spare_servers). \\ Если нагрузка не достигла 24 потоков (max_spare_servers), то уменьшать кол-во потоков радиус не будет. \\ 1 поток способен обработать до 20-25 запросов в секунду (тесты ниже). \\ ядро билинга автоматически создает дочерний процесс под каждый поток радиуса, по этому на каждом радиус сервере нужно высчитывать примерное кол-во запросов. К примеру при 4000 онлайна значения будут: \\ 4000 онлайна разделяем на 20 (столько в среднем может обработать ядро билинга за 1 секунду) умноженное на 9 (максимальное время для авторизации). \\ 4000 / (20*9) = 22 \\ В итоге получаем число 22, примерно столько нужно потоков что бы обработать все 4000 запросов за отведенное время \\ Так как max_servers не может быть меньше max_spare_servers, то max_servers можно сделать немного больше чем max_spare_servers. \\ В итоге получаем значения: * max_spare_servers = 22 * max_servers = 32 ====== Тесты ====== Конфигурация сервера на котором проводились тесты * Дата выпуска: Q1 2012 * CPU: 2х Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz * Cores: x16 * RAM: DDR3 16gb * SSD: SAMSUNG MZ7KM480HAHP-0E005 ===== Тест 1: влияние кол-ва потоков радиуса ===== Параметры теста * Radperf: 200 потоков * Кол-во запросов авторизации: 10000 Посмотрим график производительности модуля mbcore {{:billing:t0_1.jpg?500|}} {{:billing:t0_2.jpg?500|}} Как видно на графике, повышение кол-ва потоков увеличивает производительность и сокращается время требуемое на обработки всех запросов ==== Тест 2: максимальная производительность ==== В данных тестах мы прогоняли от 1000 до **1.000.000** запросов авторизации Параметры теста #2 * Radperf: 128 потоков * Радиус: 128 потоков * RAM: DDR3 16gb Посмотрим график производительности модуля mbcore {{:billing:t1_1.jpg?500|}} {{:billing:t1_2.jpg?500|}} Как видно на графике удалось разогнать packets/s до 2954, на 1.000.000 было замечено падение производительности. Параметры теста #1 * Radperf: 256 потоков * Радиус: 256 потоков * RAM: DDR3 32gb {{:billing:t2_1.jpg?500|}} {{:billing:t2_2.jpg?500|}} Как видно на графике удалось разогнать packets/s до 4583, на 1.000.000 было замечено падение производительности и более высокая нагрузка на MySQL. ==== Дополнительно: время обмена между хостами ==== Это разъяснение о важности иметь **максимально низкие** тайминги обмена данными между ядром биллинга и MySQL. В последнее время все чаще стали сталкиваться с конфигурациями где mysql вынесли на отдельный сервер, что как бы очень даже верное решение, но одновременно с этим не позаботились о хорошей связи с данным сервером, в итоге задержки при отправке данных на такой сервер составляли 10-30 ms что хоть и кажется не существенным но давайте рассмотрим это чуть подробнее. Итак, мы знаем что один поток ядра способен обработать ~20 запросов в секунду (тесты выше), в данных тестах все находилось на одном сервере и обмен данными ядра биллинга с MySQL производился с минимальными задержками по сокетам (<0.001 ms). Но что если между ядром и MySQL будет задержка в 20 ms ? В теории один запрос авторизации выполняется за 1000/20 = 50 ms, если к этим 50 ms добавить 20 ms от задержки связи, то 1 запрос будет выполнятся уже 70 ms а это в свою очередь снижает производительность ядра до 14 запросов в секунду. И это при условии что ядро делает только 1 запрос к базе, а так как ядро делает 3 запроса минимум (а в среднем около 10-15) то эти 20 ms спокойно превращаются в 60-300 дополнительных ms к обработке запроса, в итоге производительность ядра может упасть чуть ли не к 3-9 запросам авторизации в секунду. ==== Заключение ==== Логика в настройке радиуса проста: больше потоков => больше производительность, но не стоит забывать что каждый поток потребляет ресурсы сервера и если "заиграться" и выставить слишком большое кол-во потоков то можно добиться обратного эффекта снизив производительность.