Alex's Blog

В предыдущей статье я описывал концентратор доступа @Net ATLAC, и приводил некоторую статистику нагрузки, снятую с помощью vmstat. Естественно, голые числа не дают полноценной картины.

Вашему вниманию предлагается статистика нагрузки "живого" концентратора @Net ATLAC, работающего 24/7, несмотря на beta-версию (beta7). Под ссылкой "читать далее" находятся графики мониторинга системы, конфигурация сервера, и некоторые комментарии.

...

1. Конфигурация сервера, на котором запущена beta7-версия @Net ATLAC

CPU: Intel(R) Xeon(R) CPU E5502 @ 1.87GHz (2 ядра)
MHz: 1866.773
Cache Size: 32 KB L1, 256 KB L2, 4096 KB L3
BogoMIPS: 3733.54
RAM: 4GB (2x2) DDR3-1333
OS: CentOS 5.4 (Linux 2.6.18-164.11.1.el5 SMP x86_64)
Platform: Hewlett-Packard ProLiant DL320 G6
NIC: 2xEthernet controller: Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3), Etherchannel (LACP) 2x1Gbps

Сеть: используется QinQ, на сервер по Etherchannel приходят 4 "верхних" тега VLAN, в которых заключены до 4094 "нижних" тега абонентов, число активных "нижних" тегов заранее неизвестно. Выход во внешний мир организован отдельным VLAN на том же Etherchannel. Для маршрутизации используется BGP, несколько внешних маршрутизаторов, число маршрутов в маршрутной таблице - более 800.

2. Графики нагрузки за день

3. Комментарии к графикам

Сначала о простом. Как видим, пик нагрузки составил почти 300 мбит в обе стороны, и 383 одновременных PPPoE-сессии. Количество PPPoE сессий не такое большое, как могло бы быть, но общую оценку работе системы дать позволяет. Кроме того - такое количество PPPoE-сессий подразумевает существенную динамику подключений-отключений.

Стоит отметить момент равномерности загрузки сети. Вход и выход равномерен, ибо весь трафик абонентов (вместе с PPPoE) идет по одному Etherchannel интерфейсу, только на разных VLAN, а сам LAC почти не использует канал (BGP по сравнению с трафиком абонентов - это мелочь).

Теперь о насущном. Наибольший интерес представляет график загрузки процессора. Для начала скажу, что нагрузка почти что равномерно распределяется по двум ядрам процессора, поэтому отдельных графиков по ядрам приводить смысла нет. Поясню, откуда берется та или иная нагрузка.

Самая "жирная" часть - красная. Она дополняется небольшой фиолетовой "границей". Это обработка и пропускание трафика. Собственно фиолетовая граница - это обработка трафика сетевыми адаптерами, а красная секция - это "обмолот" трафика системой, включая всю классификацию и шейпинг.

Мы видим, что с лавинообразным ростом трафика фиолетовая часть становится чуть более выраженной, а рост красной части - коррелирует менее выраженно, тут очевидно сказывается то, что трафик обрабатывается группами пакетов, и при меньшем объеме трафика система тратит примерно то же время на обработку, ибо размеры групп становятся меньше. Характер трафика - абонентский. Это и торренты, в т.ч. с мелкими пакетами (UtP), это и массивный файловый трафик, и игры, и т.д. К сожалению, нет точной статистики пропускаемых PPS, однако эти замеры будут сделаны в дальнейшем.

Где-то до 200 Мбит в обе стороны роста почти не наблюдается, очевидно, на обработку групп пакетов уходит меньше, чем на прерывание для обработки, после 200 Мбит начинается небольшой рост (с 18 до 24% при росте трафика с 200 до 300 Мбит), что позволяет предположить, что допустимый порог в 70% будет пройден где-то при 1000 Мбит в обе стороны при линейном характере роста загрузки. Есть также основания предполагать, что сохранится некоторая нелинейность роста - "полочки" загрузки в зависимости от количества пакетов, передаваемых на обработку за прерывание.

Голубая и светло-голубая полоски - это нагрузка системных вызовов (ядра) и пользовательских процессов соответственно. Эти две составляющих напрямую зависят от числа абонентов и периодичности аккаунтинга, поскольку основную нагрузку дает именно настройка шейпера при подключениях-отключениях (tc дает нагрузку в виде системных вызовов), и сбор статистики с того же tc, включая разбор собранных данных PHP-скриптом и отсылку (тут - некоторое число системных вызовов того же tc, и основная масса времени пользовательских процессов).

В работе использовался интервал аккаунтинга в 5 минут, и порядка 3 сервисных группы на пользователя с общей длиной фильтра 15-25 единиц. Как видим, на почти 400 пользователей этот показатель не превышает 8% загрузки процессора. Т.е. расчетная типовая емкость системы при данном интервале аккаунтинга и наборе сервисных групп составляет примерно 2000-3000 пользователей и 1Гбит трафика(загрузка от скриптов составит около 30-40%, от трафика - порядка 70%). Если увеличить интервал аккаунтинга, то емкость системы  можно довести до 4000-5000 пользователей без особого труда.

Слишком оптимистичный взгляд? Нет. У этого показателя нагрузки есть еще одна хитрая характеристика - "линейчатый спектр". На графике мы видим усредненный показатель нагрузки, с интервалами в 5 минут. На деле этот показатель нагрузки представляет собой "всплески" крайне небольшой продолжительности, с занятием до 80% процессорного времени (сколько остается от прогона трафика). Поэтому вполне возможно несколько "прижать" эти процессы "полкой" трафика, работоспособность системы при этом практически не пострадает. Натурный эксперимент такого характера будет проведен позже. Фактически, возможное при недостатке ресурсов запаздывание обработки настроек шейпера приведет только к тому, что абонент получит пару секунд на скорости выше заявленной тарифом. Небольшое запаздывание аккаунтинга не критично в принципе. Хотя, чтобы вызвать хоть какое-то запаздывание, нагрузка на процессор от трафика должна составлять более чем 70%, при более чем 1600 работающих абонентах и гигабите трафика в обе стороны.

Зеленую и кое-где наблюдающиеся серые полосы оставим без внимания. Это IOWait - время ожидания доступа к устройствам (очевидно, при работе скриптов), и niced-процессы (очевидно, запускаемые мной при тестировании программы). Кстати, небольшие всплески User Processes около 0 и 5 часов вызваны именно запуском некоторых скриптов. В 0 часов активизируется SSG-управление (меняет параметры некоторых абонентов по заявкам), в 5 - сбор логов.

Итого мы рассмотрели нагрузочную характеристику системы @Net ATLAC. Для расчетной задачи (2000U/1Gbit) она вполне удовлетворительна, кроме того, в beta7 есть огромный простор для оптимизации некоторых вещей, поэтому общая нагрузка на систему, вероятно, будет сокращаться по мере этой самой оптимизации.

---

Дополнено 01.03.2010

Еще немножко графиков с ATLAC в динамике.

Эта серия графиков прекрасно подтверждает выводы, сделанные в первой части статьи. На 280 Мбит/с в обе стороны затраты на проброс трафика составляют около 24% загрузки процессора (рост нелинеен). Рост числа абонентов до 411 не привел к линейному росту затрат на системные вызовы и приложения, т.е. нагрузку по данному критерию надо изучать дополнительно - она так же нелинейна.

В статистику по CPU добавлены числовые характеристики минимума, максимума и усредненного показателя за период, они достаточно наглядны. Кроме того, убран минимум масштаба (50%).

Резкий выброс (пик) нагрузки с последующим спадом активности в районе 00:00 - это массовая (!!!) отработка запросов SSG/ISG: 1 числа месяца производятся многочисленные изменения скоростных характеристик, а также разрыв всех сеансов связи для корректного подведения биллинговых итогов по сессиям.

---

Следите за дальнейшими новостями.