Мои узлы данных в моем кластере hbase запускают некоторые tcp rcvpruned и время от времени пропускают отставание:
Кажется, есть как минимум два угла, чтобы подойти к этому:
Мне интересно лучше понять эти две метрики и дать какие-либо действенные советы по любому из этих двух путей. Может ли кто-нибудь посоветовать конкретные дальнейшие шаги?
tcp_v4_rcv
[0] звонков sk_add_backlog
и если это не удается, он увеличивается TCPBacklogDrop
2014 } else if (unlikely(sk_add_backlog(sk, skb,
2015 sk->sk_rcvbuf + sk->sk_sndbuf))) {
2016 bh_unlock_sock(sk);
2017 NET_INC_STATS_BH(net, LINUX_MIB_TCPBACKLOGDROP);
2018 goto discard_and_relse;
2019 }
sk_add_backlog
терпит неудачу, только если sk_rcvqueues_full
[1]:
801 /* The per-socket spinlock must be held here. */
802 static inline __must_check int sk_add_backlog(struct sock *sk, struct sk_buff *skb,
803 unsigned int limit)
804 {
805 if (sk_rcvqueues_full(sk, skb, limit))
806 return -ENOBUFS;
807
808 __sk_add_backlog(sk, skb);
809 sk->sk_backlog.len += skb->truesize;
810 return 0;
811 }
Базовая функция __sk_add_backlog
недавно [2] разрешил прохождение хотя бы одного пакета:
+ * Do not take into account this skb truesize,
+ * to allow even a single big packet to come.
Я полагаю, применение этого патча к вашему ядру должно решить проблему. Также вы можете попытаться увеличить размер буфера rcv по умолчанию как в ОС, так и в приложении (setsockopt
SO_RCVBUF
)
И ваш второй вопрос о RcvPruned
- Linux увеличивает этот стат внутри tcp_prune_queue
[3]. Эта функция обычно вызывается, когда сокет выходит за пределы rcv. Итак, вы снова можете увеличить свой rmem
/SO_RCVBUF
и / или настроить ваше приложение на более частые вызовы read () (я предполагаю, что ваши отбрасывания тесно связаны с паузами Java Stop-The-World GC. Итак, настройте свой GC).
[0] http://lxr.free-electrons.com/source/net/ipv4/tcp_ipv4.c?v=3.15#L2014
[1] http://lxr.free-electrons.com/source/include/net/sock.h?v=3.15#L802
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0fd7bac6b6157eed6cf0cb86a1e88ba29e57c033
[3] http://lxr.free-electrons.com/source/net/ipv4/tcp_input.c?v=3.15#L4662