Очистить кэш сетевого адаптера linux

Обновлено: 24.01.2025

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

Как работает сетевой стек

Коротко

Материнские платы могут поддерживать одновременную работу нескольких процессоров, у которых может быть несколько ядер, у которых может быть несколько потоков.
Оперативная память, NUMA. При использовании нескольких процессоров, как правило, у каждого процессора есть “своя” и “чужая” память. Обе они доступны, но доступ в чужую - медленнее. Бывают архитектуры, в которых память не делится между процессорами на свою и чужую. Сочетание ядер процессора и памяти называется NUMA-нодой. Иногда сетевые карты тоже принадлежат к NUMA-ноде.

Сетевые карты можно поделить по поддержке RSS (аппаратное масштабирование захвата пакетов). Серверные поддерживают, бюджетные и десктопные нет. Зачастую, несмотря на диапазон, указанный в smp_affinity_list у обработчика прерываний, прерывания обрабатываются только одним ядром (как правило CPU0). Все сетевые карты работают следующим образом:

IRQ (top-half): сетевая карта пишет пакеты в свою внутреннюю память. В оперативной памяти той же NUMA-ноды, к которой привязана сетевая карта, под неё выделен кольцевой буфер. По прерыванию процессора сетевая карта копирует свою память в кольцевой буфер и делает пометку, что у неё есть пакеты, которые надо обработать. Кольцевых буферов может быть несколько и они могут обрабатываться параллельно.
Softirq (bottom half): сетевой стек периодически проверяет пометки от сетевых карт о необходимости обработать пакеты. Пакеты из кольцевых буферов обрабатываются, проходят, файрволы, наты, сессии, доходят до приложения при необходимости. На этом уровне есть программный аналог аппаратных очередей, который уместен в случае с сетевыми картами с одной очередью.
Cache locality. Если пакет обрабатывался на определённом CPU и попал в приложение, которое работает там же - это лучший случай, кэши работают максимально эффективно.

Подробнее - путь пакета из кабеля в приложение:

Сразу оговорю неточности: не прописано прохождение L2, который ethernet. С L1 как-то сразу в L3 прыгнул.

Выводы

Перед главной задачей, выполняется первостепенная задача - подбор аппаратной части, само собой с учётом того, какие задачи лежат на сервере, откуда и сколько приходит и уходит трафика и т.д.

Есть два способа распределить нагрузку по обработке пакетов между ядрами процессора:

RSS - назначить smp_affinity для каждой очереди сетевой карты.
RPS (можно считать его программным аналогом RSS) - назначить rps_cpus для каждой очереди сетевой карты.
Комбинирование RSS и RPS. Дополнительный буфер с одной стороны - снижает вероятность потери пакета при пиковой нагрузке, с другой стороны - увеличивает общее времени обработки и может за счёт этого увеличивать вероятность потерь. Для сетевых карт с несколькими очередями и равномерным распределением пакетов перенос пакета с ядра на ядро будет использовать драгоценный budget и снизит эффективность использования кэша процессора.

Как подбирать аппаратное обеспечение

Процессоры

Число процессоров:

Однопроцессорный сервер эффективен, если трафик приходит только на одну сетевую карту, в том числе в её порты, если их несколько.
Двухпроцессорный сервер эффективен, если есть больше двух источников трафика, с потоком более 2 Гбит/сек и они обрабатываются отдельными сетевыми картами (не портами).

Не нужно больше ядер, чем максимальное суммарное количество очередей всех сетевых карт.
Hyper-Threading: не помогает, если обработка пакетов - основной вид нагрузки на процессор. Оценивайте процессор по числу ядер, а не потоков.

Размер RX-буферов: чем он больше, тем лучше.
Максимальное число очередей: чем их больше, тем лучше. Некоторые (mellanox) сетевые карты поддерживают только число очередей равное степени двойки. Если у Вас 6-ядерный процессор - имеет смысл подобрать другую сетевую карту.
Бракованные сетевые карты - вероятность мала, но иногда случается. Заменяем одну сетевую карту на точно такую же и всё замечательно.
Драйвер: не рекомендую использовать десктопные карты (обычно D-Link, Realtek).

Мониторинг и тюнинг сетевого стека

Мониторинг можно условно поделить на

краткосрочный - посмотреть как чувствует себя система прямо сейчас;
долгосрочный - с алертами, вот это всё.

Заниматься тюнингом без краткосрочного мониторинга равноценно случайным действиям. Я разработал инструменты для такого мониторинга - netutils-linux, они протестированы и работают на версиях python 2.6, 2.7, 3.4, 3.6, 3.7 и, возможно на более новых. Изначально делал для технической поддержки, объяснять каждому такой объёмный материал - долго, сложно. Есть фраза “код - лучшая документация”, а моей целью было “инструменты вместо документации”.

При возникновении проблем - сообщайте о них на github, а лучше присылайте pull-request’ы.

Мониторинг

network-top

Эта утилита отображает полную картину процесса обработки пакетов. Вы увидите равномерность распределения нагрузки (прерывания, softirqs, число пакетов в секунду на ядро процессора и на сетевой интерфейс) на ресурсы сервера, ошибки обработки пакетов. Аномальные значения счётчиков подсвечиваются красным.

Вверху отображаются источники прерываний, чтобы всё влезало на экран редкие прерывания скрыты. Имена ядер подсвечиваются в зависимости от принадлежности к NUMA-ноде или к процессору.

Посередине находится самое важное - распределение обработки пакетов по CPU:

Interrupts. Суммарное число прерываний на ядро. Лучше держаться не более 10000 прерываний на 1GHz частоты ядра. В случае с hyperthreading - 5000. Настраивается утилитой rss-ladder .
NET_RX. Число softirq на приём пакетов. Настраивается утилитой autorps .
NET_TX. Число softirq на отправку пакетов. Настраивается утилитой autoxps .
Total. Число обработанных данным ядром пакетов.
Dropped. Число отброшенных в процессе обработки пакетов. Отбрасывание приводит медленной работе сети, хосты повторно отправляют пакеты, у них задержки, потери, люди жалуются в техподдержку.
Time squuezed. Число пакетов, которым не хватило времени для обработки и их обработку отложили на следующий виток цикла. Повод задуматься о дополнительном тюнинге.
CPU Collision. times that two cpus collided trying to get the device queue lock. Ни разу не видел на своей практике.

Внизу находится статистика по сетевым девайсам.

rx-errors - общее число ошибок, обычно суммирует остальные. В какой именно счётчик попадает пакет зависит от драйвера сетевой карты.
dropped , fifo , overrun - пакеты, не успевшие обработаться сетевым стеком
missed - пакеты, не успевшие попасть в сетевой стек
crc - прилетают битые пакеты. Часто бывает следствием высокой нагрузки на коммутатор.
length - слишком большие пакеты, которые не влезают в MTU на сетевой карте. Лечится его увеличением: ip link set eth1 mtu 1540 . Постоянное решение для RHEL-based систем - прописать строчку MTU=1540 в файле конфигурации сетевой карты, например /etc/sysconfig/network-scripts/ifcfg-eth1 .

Флаги утилиты

Задать список интересующих девайсов: --devices=eth1,eth2,eth3
Отсеять девайсы регуляркой: --device-regex='^eth'
Сделать вывод менее подробным, спрятав все специфичные ошибки: --simple
Убрать данные об отправке пакетов: --rx-only .
Представление данных об объёме трафика можно менять ключами: --bits , --bytes , --kbits , --mbits .
Показывать абсолютные значения: --no-delta-mode

Альтернативные способы получения этой информации:

Потери могут быть не только на Linux-сервере, но и на порту связанного с ним сетевого оборудования. О том, как это посмотреть можно узнать из документации производителя сетевого оборудования.

Стандартный top

server-info

Если приходится иметь дело с разношёрстными серверами, которые закупались разными людьми, полезно знать какое оборудование у них внутри и насколько оно подходит под текущие нагрузки. Утилита server-info именно для этого и предназначена. У неё два режима:

--show - показать оборудование;
--rate - оценить оборудование.

Вывод в YAML. Примеры:

и оценивать это железо по шкале от 1 до 10:

Вместо --server можно указать --subsystem , --device или вообще ничего, тогда оценка будет вестись по каждому параметру устройства в отдельности.

Тюнинг

maximize-cpu-freq

Плавающая частота процессора плохо сказывается для нагруженных сетевых серверов. Если процессор может работать на 3.5GHz - не надо экономить немного ватт ценой потерь пакетов. Утилита включает для cpu_freq_governour режим performance и устанавливает минимальную частоту всех ядер в значение максимально-доступной базовой. Узнать текущие значения можно командой:

Помимо плавающей частоты есть ещё одно но, которое может приводить к потерям: режим энергосбережения в UEFI/BIOS. Лучше его выключить, выбрав режим “производительность” (для этого потребуется перезагрузить сервер).

rss-ladder

Утилита автоматически распределяет прерывания “лесенкой” на ядрах локального процессора для сетевых карт с поддержкой нескольких очередей.

Если сетевых карт несколько, лучше выделить для каждой очереди каждой сетевой карты одно физическое ядро, ответственное только за неё. Если ядер не хватает - число очередей можно уменьшить с помощью ethtool, например: ethtool -L eth0 combined 2 или ethtool -L eth0 rx 2 в зависимости от типа очередей.

Для RSS по возможности используйте разные реальные ядра, допустим, дано:

1 процессор с гипертредингом
4 реальных ядра
8 виртуальных ядер
4 очереди сетевой карты, которые составляют 95% работы сервера

В зависимости от того как расположены ядра и потоки (узнать можно по выводу lscpu -e ), использовать 0, 2, 4 и 6 ядра будет эффективнее, чем 0, 1, 2 и 3.

rx-buffers-increase

Увеличивает RX-буфер сетевой карты. Чем больше буфер - тем больше пакетов за один тик сетевая карта сможет скопировать с помощью DMA в кольцевой буфер в RAM который уже будет обрабатываться процессором.

Для работы после перезагрузки в RHEL-based дистрибутивах (платформа Carbon, CentOS, Fedora итд) укажите в настройках интерфейса, например /etc/sysconfig/network-scripts/ifcfg-eth1 , строчку вида:

autorps

Утилита для распределения нагрузки на сетевых картах с одной очередью. Вычисляет и применяет маску процессоров для RPS, например:

Настройка драйверов сетевых карт для работы в FORWARD/Bridge-режимах

Опции General Receive Offload и Large Receive Offload в таких режимах могут приводить к паникам ядра Linux и их лучше отключать либо при компиляции драйвера, либо на ходу, если это поддерживается драйвером:

Примеры

1. Максимально простой

Параметр	Значение
Число процессоров	1
Ядер	4
Число карт	1
Число очередей	4
Тип очередей	combined
Режим сетевой карты	1 Гбит/сек
Объём входящего трафика	600 Мбит/сек
Объём входящего трафика	350000 пакетов/сек
Максимум прерываний на ядро в секунду	55000
Объём исходящего трафика	0 Мбит/сек
Потери	200 пакетов/сек
Детали	Все очереди висят на CPU0, остальные ядра простаивают

Решение: распределяем очереди между ядрами и увеличиваем буфер:

Параметр	Значение
Максимум прерываний на ядро в секунду	15000
Потери	0
Детали	Нагрузка равномерна

Пример 2. Чуть сложнее

Параметр	Значение
Число процессоров	2
Ядер у процессора	8
Число карт	2
Число портов у карт	2
Число очередей	16
Тип очередей	combined
Режим сетевых карт	10 Гбит/сек
Объём входящего трафика	3 Гбит/сек
Объём исходящего трафика	100 Мбит/сек
Детали	Все 4 порта привязаны к одному процессору

Одну из 10 Гбит/сек сетевых карт перемещаем в другой PCI-слот, привязанный к NUMA node1.

Уменьшаем число combined очередей на каждый порт до числа ядер одного физического процессора (временно, нужно делать это при перезагрузке) и распределить прерывания портов. Ядра будут выбраны автоматически, в зависимости от того к какой NUMA-ноде принадлежит сетевая карта. Увеличиваем сетевым картам RX-буферы:

Необычные примеры

Не всегда всё идёт идеально:

Проблема	Решение
Сетевая карта теряет пакеты при использовании RSS.	1 RX-очередь для захвата на CPU0, а обработка на остальных ядрах: autorps --cpus 1,2,3,4,5 eth0
У сетевой карты несколько очередей, но 99% пакетов обрабатывается одной очередью	Причина в том, что у 99% трафика одинаковый хэш, такое бывает при использовании QinQ, Vlan, PPPoE и во время DDoS атак. Решений несколько: от DDoS защититься ранним DROP трафика, перенести агрегацию VLAN на другое оборудование, сменить сетевую карту, которая учитывает Vlan при вычислении хэша для RSS, попробовать использовать RPS
Сетевые карты intel X710 начала работать без прерываний, вся нагрузка висела на CPU0.	Нормальная работа восстановилась после включения и выключения RPS. Почему началось и закончилось - неизвестно.
Некоторые SFP-модули для Intel 82599ES при обновлении драйвера (сборка ixgbe из исходников с sourceforge) “пропадают” из списка сетевых карт и даже флаг unsupported_sfp=1 не помогает. При этом в lspci этот порт отображается, второй аналогичный порт работает, а в dmesg на оба порта одинаковые warning’и.	Не нашлось.
Некоторые драйверы сетевых карт работают с числом очередей только равным степени двойки	Замена сетевой карты или процессора.

Блог Олега Стрижеченко

30% личного, 20% linux, 30% наблюдения за разработкой, 5% книги, 10% математика и статистика, 10% шуток

Вместо того, чтобы очистить кэш arp, они, кажется, просто делают записи недействительными (они будут отображаться как incomplete ). Даже через несколько минут ARP-кеш выглядит так:

(MAC-адрес шлюза обновлен - это нормально)

Как я могу действительно очистить кэш ARP, как в «удалить все записи из таблицы»? Я не хочу хранить неполные записи, я хочу, чтобы они были удалены. Это возможно?

РЕДАКТИРОВАТЬ

Это моя система:

Что вы пытаетесь достичь здесь? Или, если быть более понятным, какую проблему вы пытаетесь решить? Вам не хватает записей таблицы ARP? Может быть, есть программа, запрашивающая этот IP, обновляющая эту запись. Проверьте с помощью wireshark или tcpdump . @MichaelMartinez, потому что проблема ху . Кажется вероятным, что вопрос не является коренной проблемой, и может быть некоторая основная проблема, над которой вместо этого должен работать OP. Причина, по которой эта информация не рассматривается, заключается в том, что она не актуальна. Я хочу чистый кеш ARP. Полная остановка. Ты не веришь мне, что я этого хочу, но это твоя проблема, а не моя. Уверяю вас: я хочу чистый ARP-кеш.

Обязательно сделайте все сразу, чтобы не нарушить сетевое подключение, прежде чем вы сможете снова включить ARP.

Нужно сделать это либо в сценарии оболочки, либо на компьютере, так как кажется, что он нарушает соединение после первой команды. Я сделал это в одну строку, и это сработало dev=eth2; ip link set arp off dev $dev; sleep 1; ip link set arp on dev $dev . sleep Не может быть необходимым.

Ваше первое решение работает, просто требуется немного времени (5-10 секунд в моем тесте на Kali), чтобы перейти от "(неполного)" до отсутствия записей.

Предположительно, он находится в каком-то переходном состоянии на пути к удалению.

Для меня (Ubuntu 14.04) это было не так: записи хранятся в течение длительного времени (навсегда?) В неполном состоянии. Я проверю это снова сегодня. Проверено: даже через несколько минут записи все еще там, в неполном состоянии (arp 1.88, net-tools 1.60) Ну, тогда ваша проблема, конечно, нестандартное поведение, может быть, специфическое для Ubuntu 14.04. Правильный способ сделать это в Linux просто не работает для вас. Надеюсь, вы скоро найдете ответ. Можете удалить этот, если хотите. Нет, оставь это, это дает информацию для других. Но я предполагаю, что более «стандартное» поведение можно найти в Ubuntu, а не в Kali, который является дистрибутивом для тестирования на проникновение и имеет значения по умолчанию, специально настроенные для этого варианта использования.

В определенной системе ip команда недоступна.

Так что это альтернатива ip link set arp off dev eth0; ip link set arp on dev eth0 команды.

Если вы хотите удалить все записи из таблицы в одной команде, используйте for loop как в следующем примере.

ПЕРЕД

УДАЛЕНИЕ ARP С ARP -D КОМАНДА

Чтобы решить эту проблему, используйте ifconfig ethx up/down как это

ПЕРЕД

ОТКЛЮЧИТЬ И ВКЛЮЧИТЬ ИНТЕРФЕЙСЫ ETH1 и ETH2 В ОДНОЙ КОМАНДЕ

Пока в Интернете ведутся войны на тему "надо ли вообще сбрасывать кэш в Linux", я для себя ответил на этот вопрос. Да, иногда это необходимо. Предположим, есть сервер, который работает под CentOS и выполняет монотонные несложные задачи ежедневно. Но раз в неделю он единовременно выполняет весьма ресурсоёмкую задачу, которая сильно нагружает процессор и "съедает" всю память (под кэш). Конечно, грамотные люди знают, что такое буфер, и как он работает. Но смысл хранить в памяти файловые данные, которые в лучшем случае потребуются через неделю, а скорее всего - просто устареют уже через пару дней!?

Моё предложение: дополнять скрипты редких ресурсоёмких задач командами очистки кэша.

К ресурсоёмким задачам, забивающим кэш лишней информацией я отношу следующие задачи, при условии их редкого выполнения:

Архивация (в моём случае tar способен "съесть" всю свободную память)
Обновление через yum
Анализ статистики веб-сервера и построение отчётов

Как известно, в версии ядра 2.6.16 (и более свежих) появился механизм, который вынуждает ядро сбросить страничный кэш и/или кэши inode+dentry. После выполнения команды высвобождается существенный объем ОЗУ. Ходят легенды, что издревле несчастные администраторы писали специальные скрипты, которые пытались выделить тонны памяти с единственной целью: чтобы изгнать кэш из памяти :)

Для использования /proc/sys/vm/drop_caches достаточно передать число.

Чтобы сбросить страничный кэш:

Чтобы сбросить кэши dentry и inodes:

Чтобы сбросить страничный кэш, dentry и inodes:

Теперь выполним лабораторную работу.

На веб-сервере, работающем под CentOS 6.6, было замечено, что в обычном режиме достаточно 1 Гб ОЗУ для выполнения всех задач, причем этот лимит никогда не превышается, а файл подкачки постоянно держится на величине 0 Kb. Однако, после выполнения тяжелых задач память целиком забивается, и - самое обидное! - сервер начинает своппить на обычных простых задачах, постепенно забивая файл подкачки и постоянно напрягая жесткий диск. Проведём мониторинг памяти до (красным) и после (синим) выполнения сброса.

Выигрыш очевиден. Если раньше было свободно 87 Мб, то стало свободно 1456 Мб даже при условии, что в качестве параметра сброса мы передавали единицу.

Теперь сервер в состоянии проработать ещё неделю, совершенно не напрягая жесткий диск.

This is a non-destructive operation and will only free things that are completely unused. Dirty objects will continue to be in use until written out to disk and are not freeable. If you run "sync" first to flush them out to disk, these drop operations will tend to free more memory.

Добавить в избранное (1 оценок, среднее: 5,00 из 5)

Однако в некоторых ситуациях, таких как устранение неполадок в сети или после смены преобразователей DNS, вам необходимо очистить кэш DNS. Это очистит кэшированные записи DNS и выполнит последующий поиск для разрешения домена на основе вновь настроенных параметров DNS.

В этой статье приведены инструкции по очистке кеша DNS в разных операционных системах и веб-браузерах.

Очистить/удалить кэш DNS в Windows

Процесс очистки DNS-кэша одинаков для всех версий Windows. Вам нужно открыть командную строку с правами администратора и запустить ipconfig /flushdns.

Windows 10 и Windows 8

Чтобы очистить кэш DNS в Windows 10 и 8, выполните следующие действия:

Введите cmd в строке поиска Windows.
Щелкните правой кнопкой мыши на командной строке и выберите Запуск от имени администратора. Это откроет окно командной строки.
В командной строке введите следующую строку и нажмите Enter:

Windows 7

Чтобы очистить кэш DNS в Windows 7, выполните следующие действия:

Нажмите на кнопку Пуск.
Введите cmd в текстовое поле поиска меню «Пуск».
Щелкните правой кнопкой мыши на командной строке и выберите Запуск от имени администратора. Это откроет окно командной строки.
В командной строке введите следующую строку и нажмите Enter:

Очистить/удалить кэш DNS в Linux

В Linux отсутствует кэширование DNS на уровне ОС, если не установлена и не запущена служба кэширования, такая как Systemd-Resolved, DNSMasq или Nscd. Процесс очистки DNS-кэша отличается в зависимости от дистрибутива Linux и службы кэширования, которую вы используете.

Systemd Resolved

В большинстве современных дистрибутивов Linux, таких как Ubuntu 18.04, используется системный разрешенный сервис для кэширования записей DNS.

Чтобы узнать, запущена ли служба, выполните:

Если служба работает, команда напечатает active, иначе вы увидите inactive.

Чтобы очистить DNS-кэш Systemd Resolved, вы должны ввести следующую команду.

Dnsmasq

Если ваша система использует DNSMasq в качестве сервера кеширования, для очистки кеша DNS вам необходимо перезапустить службу Dnsmasq:

Если ваша система использует Nscd, для очистки кеша DNS вам необходимо перезапустить службу Nscd:

Очистить/удалить кэш DNS на MacOS

Команда очистки кэша в MacOS немного отличается в зависимости от используемой версии. Команда должна быть запущена как пользователь с правами системного администратора (пользователь sudo).

Чтобы очистить кэш DNS в MacOS, выполните следующие действия:

Откройте Finder.
Перейдите в Приложения> Утилиты> Терминал. Это откроет окно терминала.
В командной строке введите следующую строку и нажмите Enter:

Для более ранних версий MacOS команда очистки кэша отличается.

MacOS версии 10.11 и 10.9

MacOS версия 10.10

MacOS версии 10.6 и 10.5

Очистить /удалить кэш DNS браузера

В большинстве современных веб-браузеров есть встроенный DNS-клиент, который предотвращает повторяющиеся запросы при каждом посещении веб-сайта.

Google Chrome

Чтобы очистить DNS-кеш Google Chrome, выполните следующие действия:

Если это не работает для вас, попробуйте очистить кэш и куки.

Этот метод должен работать для всех браузеров на основе Chrome, включая Chromium, Vivaldi и Opera.

FireFox

Чтобы очистить DNS-кэш Firefox, выполните следующие действия:

Если это не работает для вас, попробуйте следующий метод и временно отключите кэш DNS.

Откройте новую вкладку и введите about:configв адресную строку Firefox.
Найдите network.dnsCacheExpiration, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.
Найдите network.dnsCacheEntries, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.

Заключение

Вы узнали, как очистить или очистить кэш DNS в операционных системах Windows, Linux и MacOS.

Linux и MacOS могут использовать команду dig для запроса DNS и устранения проблем с DNS.

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте также: