RE: RAC node "has a disk HB, but no network HB" but traceroute

  • From: "CRISLER, JON" <JC1706@xxxxxxx>
  • To: "dmarc-noreply@xxxxxxxxxxxxx" <dmarc-noreply@xxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 11 Jan 2017 01:00:03 +0000

Let me add a few tips- I have run into issues such as yours many times.
Increase fragment assembly  buffer per your earlier mention
Check your /etc/sysctl.conf for optimum sizing for UDP
- net.core.netdev_budget tuning
- net.core.netdev_max_backlog
Check overall CPU and load average to make sure the LMS processes are getting 
enough processing time, and make sure _HIGH_PRIORITY_PROCESSES includes LMS and 
LGWR. Check that oradism is functioning properly.
Have your network people run an audit to make sure jumbo frames is turned on 
end to end (OS, switch etc).  10G and jumbo frames are a must for high volume 
and low latency. Even at 1 gb Ethernet you need jumbo frames.
- assuming you are using 10G , make sure the card can deliver the bandwidth as 
well using a IP test tool that can pass UDP : my preference is netperf .
- checking for fragment drops -  ethtool -S ethX | grep frags
- make sure server and Ethernet card firmware is up to date and all firmware 
matches- i.e. prerequisits and corequisits
I think you mentioned 11.2.0.3 - 11.2.0.4 has a few patches for subtle bugs 
affecting the interconnect

Make sure you go line by line and check everything in this Oracle Support 
document- Troubleshooting gc block lost and Poor Network Performance in a RAC 
Environment (Doc ID 563566.1)
And lastly-  completely erasing UDP drops, errors etc is impossible .  UDP by 
design is not error free, so the application must be tolerant of some UDP 
issues- in this case it’s the LMS process in RAC, which will retry lost packets.
Your goal is to minimize any errors as much as possible

Here is an example of a sysctl.conf -  This covers UDP tuning and kernel tuning 
for the network stack.   There are some good RedHat docs on this topic, and 
this doc is a must read-
RedHat solution 1241943 ‐ monitor status of  /proc/net/softnet_stat

Sample /etc/sysctl.conf for very large RAC config, RedHat 6 and RAC 11gR2
net.core.rmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
net.core.netdev_max_backlog = 2000
net.core.netdev_budget = 600
net.ipv4.ipfrag_high_thresh = 16777216
net.ipv4.ipfrag_low_thresh = 15728640

Good luck- Jon


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Yong Huang
Sent: Thursday, January 05, 2017 5:09 PM
To: oracle-l@xxxxxxxxxxxxx
Cc: justin@xxxxxxx; jure.bratina@xxxxxxxxx; martin.a.berger@xxxxxxxxx
Subject: Re: RAC node "has a disk HB, but no network HB" but traceroute

Thanks, Justin, Jure and Martin. Martin's article is great. Interpreting "no 
network HB" as "there are 2 or more processes which missed to communicate" 
instead of a network problem is the key. That's exactly what I meant in the SR 
I opened by saying "We begin to doubt about the meaning of the "no network HB" 
message". So far the SR hasn't gone anywhere after uploading various types of 
logs.

Our log does show fast increase in IP packets that need reassembly and all 
these reassemblies failed:
$ egrep '^zzz|reassembl' <OSWatcher netstat log> ...
zzz Sun Dec 18 02:01:58 CST 2016
555539624 reassemblies required
100653307 packets reassembled ok
60026 packet reassembles failed
zzz Sun Dec 18 02:02:28 CST 2016
555545702 reassemblies required
100653307 packets reassembled ok
66103 packet reassembles failed
zzz Sun Dec 18 02:02:58 CST 2016
555551748 reassemblies required
100653307 packets reassembled ok
72149 packet reassembles failed

Of all the documents I found, Red Hat "IP fragmentation fails and fragmented 
packets get dropped" at
https://access.redhat.com/solutions/1498603
is a good one. But you have to login to read it. In short, if I understand the 
confusing Root Cause section correctly, kernel-2.6.32-477.el6 or RHEL6.6 has a 
bug that incorrectly calculates IP fragmentation memory, which causes false 
evictions (i.e. drop) of IP fragments on systems with many CPUs. (Our problem 
server has 80 CPUs. Other servers have much less.) Upgrade of the kernel or Red 
Hat release version is the solution. An easy workaround is to increase the 
fragmentation buffer size. The article says doubling the fragmentation 
thresholds is enough, i.e. from the default 4M to 8M. We'll set the IP 
fragmentation buffer low and high values to 15 and 16 MB per Oracle note 
2008933.1. I think the counter "fragments dropped after timeout" in `netstat 
-s' is related to /proc/sys/net/ipv4/ipfrag_time and ours seems to be fairly 
stable even before the crash, I'll leave that parameter alone for now.

Now I think I know why our OSWatcher did not report a traceroute problem at the 
last crash: the default packet size used by traceroute is only 60 bytes. To 
detect the problem, we should append a packet length parameter to the 
traceroute command with a value greater than 1500, the Ethernet MTU.

Yong Huang
--
//www.freelists.org/webpage/oracle-l


Other related posts: