Обновить
188
0.1

Пользователь

Отправить сообщение
Ну это зависит от количества пользователей. Сотня пользователей в одном бродкаст-домене (L2) — ничего особо страшного. Тысяча — катастрофа, одним бродкаст-пингом можно положить всю сеть. Конечно, активное сетевое оборудование может бороться с штормами, но не стоит делать большие бродкаст-домены, полагаясь только на эту защиту.
Смотря что считать извращением :)
Если Client-VLAN, то для того, чтобы не использовать привязки по MAC.
Если DHCP Option82, то для того, чтобы автоматически выдавать настройки абонентам.
Однако, например, на сервере мониторинга — актуально. Тот же Nagios постоянно запускает пинги и прочие тесты.
Ничего не поломается, но после обновления prelink необходимо запустить снова.
Спасибо за исправление, добавил ссылку на Ваш комментарий в пост.
Спасибо за корректировку, добавил ссылку на Ваш комментарий в пост.
Ок, обновлю график.
mmx включить стоит. А если есть интерес, то потестить с отключенным mmx и с включенным. Только нужно выбрать ПО, которое mmx активно использует.
-mfpmath=sse заставляет GCC для вычислений с плавающей точкой генерировать инструкции sse.
Чтобы полнее нагружать процессор. Не всегда один поток грузит один процессор на все 100%.
А также трафик будет обрабатываться с немного большими задержками.
Дело в том, что беготня сетевых пакетов из ядра в юзерспейс будет давать много излишней нагрузки на систему.
Добавил заявленный список поддерживаемых протоколов.
Это вся заметка. А что можно написать в продолжении? :)
Использование модуля максимально простое:
iptables -A FORWARD -m opendpi --protocol -j DROP
Подставить --protocol из списка iptables -m opendpi --help и все.
Параметр InterruptThrottleRate (если значение >100) задает количество прерываний, генерируемых в секунду. Эффект аналогичен заданию значений rx-usecs tx-usecs утилитой ethtool, что является более гибким вариантом, поэтому этот параметр e1000 не описывал. Задержки между прерываниями позволяют снизить нагрузку за счет увеличения задержек обработки трафика. Я рекомендую снижать их как можно сильнее, вплоть до ноля, пока нагрузка в часы пик будет в пределах нормы. Соответственно параметр InterruptThrottleRate повышать, пока нагрузка в пределах нормы.
Один поток Apache делает вот что: получает запрос от клиента, обрабатывает запрос, выдает результат клиенту. Один поток занимается одним клиентом и больше ничем. Т.е. с параметрами, которые Вы привели выше, Apache не сможет обработать более двух клиентов параллельно.
А один поток nginx работает иначе: в бесконечном цикле он пробегается по массиву сокетов, при необходимости считывает/записывает небольшой блок данных из/в сокет(а). Т.е. за каждый цикл он обслуживает сразу кучу клиентов (не более значения опции worker_connections). Это принцип работы poll. epoll работает еще эффективнее, но суть примерно такая же.
Распределение прерываний по ядрам поможет и в этом случае. Еще стоит оптимизировать правила с использованием ветвлений.
Дело в том, что поток Apache занимается лишь одним клиентом — такая архитектура. Поток же nginx в цикле пробегает по коннектам и уделяет каждому понемногу времени. Объясняю своими словами, надеюсь корректно описал суть :)
Спасибо, обязательно попробую. Вообще ссылка на проект ipt_netflow уже с месяц висит в списке «Посмотреть, потестить», но никак руки не доходят.
Преимущество ручного раскидывания — группировка определенных очередей на одном ядре.
А когда на одном из серверов использовал irqbalance — неоднократные кернел паники, после чего он был отключен.
Опция CONFIG_IRQBALANCE отсутствует начиная с версии 2.6.27, т.к. признана устаревшей.
Да, в комментах это не указал, но в статье написал. Увеличивать кэш ARP стоит только тогда, когда столкнетесь с сообщение в dmesg: «Neighbour table overflow».

Информация

В рейтинге
3 841-й
Откуда
Varna, Varna, Болгария
Зарегистрирован
Активность