Просмотр Исходного

h3. Здесь приведены примеры реальных серверов Carbon Reductor с указанием нагрузки, которую они обрабатывают.

Учтите, что нагрузка на сервер увеличивается не линейно, при увеличении объема трафика. Поэтому если сервер из таблицы нагружен на 50% - это не значит, что он сможет обработать в 2 раза больше трафика\!

Нагрузку в таблице мы определяем по показателю %si - проценту, сколько система тратит на обработку пакетов. Это немного грубо, т.к. не учитывает нагрузку приложений, но их влиянием при большой расчете нагрузки можно принебречь.


Как производить замеры.
* Замеры проводятся в 13 по МСК
* На одной консоли запускается top, на второй network-top. "Прогревается" 10 секунд. Обе программы останавливаем одновременно и потом записываются данные
* Из top списывается общий %si, не конкретного ядра. *Не перепутайте %sy и %si. *
* Данные из network-top записываются только из последнего замера. time_squeeze записывается минимальный/максимальный/средний по ядрам (не по замерам)
* Обязательно заполняется поле "Замер номер"

|| Замер номер \\ || Процессор \\ || Сетевая карта \\ || Остальная конфигурация сервера || Объем трафика (пакетов/сек) \\ || Объем трафика (мбит/сек) \\ || %si Сколько процессор тратит времени на обработку пакетов \\ || time_squeeze min/max/avg \\ || Особые опции \\ || ||
| \#364867 | Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz 8 ядер \\ | . | . | 1 441 462 pps | 7 805 mbits \\ | 42% \\ | ?/?/5 \\ | . | . |
| \#364867 | 2 x Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz по 8 ядер | . | . | 2 225 351 pps | 12 666 mbits | 5,2% \\ | 0/0/0 \\ | Включены оптимизации FWBOOST | |
| | | | | | | | | | |