Много dropped пакетов на интерфейсе.[linux]
ethtool более подробную статистику показывает
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
inet 111.111.111.111 netmask 255.255.252.0 broadcast 111.111.111.255
inet6 fe80::16da:e9ff:feb7:1cd9 prefixlen 64 scopeid 0x20<link>
ether f8:d1:11:01:7a:62 txqueuelen 1000 (Ethernet)
RX packets 2704192505 bytes 1708330892842 (1.5 TiB)
RX errors 5 dropped 28052 overruns 0 frame 5
TX packets 2797185455 bytes 3022339474826 (2.7 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 48 base 0xc000
Решил проверить, у меня, оказывается, тоже куча dropped. Присоединяюсь к вопросу.
Из доп. инфы, на этом интерфейсе где-то неделю-две назад кольцо было в прилежащей к нему сети, возможно этим dropped и обусловлено.
[fe02 ~]# ethtool -S eth0
NIC statistics:
rx_bytes: 20214478644
rx_error_bytes: 0
tx_bytes: 55583731204
tx_error_bytes: 0
rx_ucast_packets: 144601651
rx_mcast_packets: 4341
rx_bcast_packets: 1498
tx_ucast_packets: 87499432
tx_mcast_packets: 4018
tx_bcast_packets: 123
tx_mac_errors: 0
tx_carrier_errors: 0
rx_crc_errors: 0
rx_align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
tx_deferred: 0
tx_excess_collisions: 0
tx_late_collisions: 0
tx_total_collisions: 0
rx_fragments: 0
rx_jabbers: 0
rx_undersize_packets: 0
rx_oversize_packets: 0
rx_64_byte_packets: 0
rx_65_to_127_byte_packets: 133025184
rx_128_to_255_byte_packets: 296108
rx_256_to_511_byte_packets: 5884523
rx_512_to_1023_byte_packets: 37429
rx_1024_to_1522_byte_packets: 5364246
rx_1523_to_9022_byte_packets: 0
tx_64_byte_packets: 7384
tx_65_to_127_byte_packets: 50659956
tx_128_to_255_byte_packets: 705538
tx_256_to_511_byte_packets: 2828210
tx_512_to_1023_byte_packets: 26980
tx_1024_to_1522_byte_packets: 33275505
tx_1523_to_9022_byte_packets: 0
rx_xon_frames: 0
rx_xoff_frames: 0
tx_xon_frames: 0
tx_xoff_frames: 0
rx_mac_ctrl_frames: 0
rx_filtered_packets: 25393
rx_ftq_discards: 0
rx_discards: 0
rx_fw_discards: 1086921
Нашёл вроде баг в багзиле редхата. http://bugzilla.redhat.com/show_bug.cgi?id=484667
Но он пофикшен стопицот лет назад. Да и рядом у меня пачка таких же серверов на том же ядре работают без сбоев.
$ uname -a
Linux ***********.ru 2.6.32-220.7.1.el6.x86_64 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
rx_filtered_packets: 25393ну вот походу твои дропы
rx_fw_discards: 1086921
погугли теперь, что это означает
фильтеред это айпитэйблс. по дроппедам я бегло погуглил - нагуглил тот баг что привёл.
http://bugzilla.redhat.com/show_bug.cgi?id=640026 - тут вроде интересней
duplex одинаковый с двух сторон?
гигабит же
гигабит жеНу ладно. Я просто чего-то выше не узрел, что гигабитный линк.
rx_fw_discards это человеческим языком "no buffers", то есть на момент прихода пакета, все дескрипторы уже были заполнены и не обслужены драйвером. Не справляется твоя машина с нагрузкой.
Странно. Нагрузка ничтожна для такого сервера. Сам видишь, что траффика пару десятков гигабайт. А могут какие-то пакеты создавать такой эффект? Проблема в том что каталист на другом в конце не в моей юриксдиции и посмотреть что там нельзя.
а ты крутил настройки, как по моей ссылке делать предлагали?
убедился, что твой драйвер с фиксом, про который там говорят?
убедился, что твой драйвер с фиксом, про который там говорят?
Такая проблема может возникать и при load average 0.01, суть в том, что операционная система по какой-то причине не успевает разгребать дескрипторы. В современных ОС, где гонятся за производительностью, входящие пакеты обрабатываются непосредственно в контексте прерывания. В прошлом прерывание только перекладывало пакет из ринга сетевой карты в софтварную очередь и скедулило софтварное прерывание. Такая обработка гарантировала быструю отработку прерывания, однако перекладывание в очередь, её локинг и переключение в другой контекст всё это давало низкую производительность. Поэтому сейчас непосредственно прерывание заходит в сетевой стек и там работает. Если там оно блокируется на чём-то (а вариантов очень много) даже на непродолжительное время, то сетевая карта переполняется. Классическая проблема - пуржинг каких-то кешей, он может длиться значительное время и держать при этом мьютексы, которые также нужны и тредам осуществляющим обработку входящих пакетов. Это всё общие теории, но я думаю, что в линуксе, скорее всего всё так же.
Это всё общие теории, но я думаю, что в линуксе, скорее всего всё так же.Скорее нет. В контексте прерывания не делается нифига, насколько я понимаю, так как сейчас везде NAPI.
По моей ссылке рассуждают о том, что карточка задерживает прерывания (что обычное дело для современных карт, и величина задержки настраивается за это время приходит дофига пакетов, а хост ничего не разгребает, поэтому лишние отбрасываются. Надо крутить эти настройки (насколько задерживать, и какой размер буфера).
руки не дошли. завтра может попробую.
Это? http://en.wikipedia.org/wiki/New_API#NAPI_compliant_drivers Не вижу чем это отличается от обычного polling, который у нас был уже 10 лет как. 
Если всё так, как написано в wikipedia, то вероятность получить no buffers ещё выше, чем с прерываниями. Если ядро по какой-то причине слишком редко поллит, то no buffers гарантированы.
Если всё так, как написано в wikipedia, то вероятность получить no buffers ещё выше, чем с прерываниями. Если ядро по какой-то причине слишком редко поллит, то no buffers гарантированы.
Не вижу чем это отличается от обычного polling, который у нас был уже 10 лет как.Основное отличие в том, что у вас его не доделали (помнится надо было руками указывать частоту опроса и долю процессорного времени - что годится только для роутера, который больше ничего не делает) и (насколько я понял) бросили, а в линуксе это давно стандартная модель драйвера. Штука адаптивная: при малой нагрузке классическая схема, при большой - прерываний становится меньше вплоть до нуля, буфера разгребаются специальным тредом.
Если ядро по какой-то причине слишком редко поллит, то no buffers гарантированы.При малой нагрузке причина проста - interrupt mitigations в железке, что и предлагается крутить.
При малой нагрузке причина проста - interrupt mitigations в железке, что и предлагается крутить.Ты же сам выше говоришь что от прерываний вообще не зависит, да и wikipedia подтверждает.
Ты же сам выше говоришь что от прерываний вообще не зависит, да и wikipedia подтверждает.Не, я говорю, что в контексте прерывания не делают опрос железки, а только будят тред softirq (или не тред, там есть ещё какие-то механизмы - я несколько отстал от жизни, так как давно не хакал ядро).
В википедии написано что-то странное. Они наверное хотели сказать, что прерывания от сетевой карты запрещены, пока работает метод poll, но если нагрузка невелика, то он быстро завершается, и прерывания опять включаются.
То, что прерывания идут, можно проверить непосредственно. При большой нагрузке их меньше, это тоже можно проверить, но сложнее - нужна собственно нагрузка.
Оставить комментарий
YUAL
Господа, подскажите чем может быть вызвано такое кол-во дропнутых пакетов? Я так понимаю что если бы была проблема в физической передаче сигнала (кабель хреновый то было бы много error`ов. Куда вообще копать?