photon Опубликовано 6 июня, 2015 (изменено) · Жалоба Для снижения числа cache misses в дополнение к RPS нужно включить hardware-accelerated RFS, если сетевуха поддерживает: http://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-rfs.html . Но это все разрабатывалось для распределения нагрузки на прикладные сервисы, а не для NAT/shaping. Низкоуровневые манипуляции с пакетами выполняются внутри обработчиков softirq. Для производительности надо отключить iptables и использовать stateless NAT средствами iproute2. Наиболее оптимально это будет через ingress filter actions с хэш-фильтрами. Но опять же, лучше это делать на отдельной машине, чтобы не усложнять правила шейпинга. Изменено 6 июня, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 11 июня, 2015 · Жалоба Происходит что-то странное Запустил на сервере один только шейпер. При нагрузке до 1 гигабита загрузка ЦП состовляет всего 3%. Но стоит трафику перевалить за 1G (было 1.6Г) и сразу 2 из 8 ядер начинают грузиться на 40-60%. остальные в районе 3-5% работают. Возможно это никак с шейпингом не связано, просто кроме шейпинга сервер ничего не делает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 июня, 2015 · Жалоба И может кто нибудь скажет в двух словах, что именно делают эти магические команды Ссылку давали. И там расписано, что команду надо не магически вводить, а правильно поменять параметры. У меня команда работает и помогает стопроцентно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 11 июня, 2015 (изменено) · Жалоба То что по ссылке я читал и если правильно все понял, то это не наш метод. в конце статьи сказано For network devices with multiple queues, there is typically no benefit to configuring both RPS and RSS, as RSS is configured to map a CPU to each receive queue by default. However, RPS may still be beneficial if there are fewer hardware queues than CPUs, and RPS is configured to use CPUs in the same memory domain. а карта поддерживает очереди. Но вопрос сейчас не в этом. На данный момент больше интересует почему превышение порога в 1G сводит систему с ума. Изменено 11 июня, 2015 пользователем mirk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...