Interesting that Oracle uses the GDB approach to capture stack traces (pstack -
wrapper for GDB). GDB suspends the process (based on ptrace() syscall)
and is known to have an impact on communication to kernel or other processes.
They could use much better (and safer) tools like perf.
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK
Martin Klier - Performing Databases GmbH <martin.klier@xxxxxxxxxxxxxxxxx> hat--
am 20. Juni 2017 um 14:59 geschrieben:
Hi Listers,
just in case you are about to put a 12.2 RAC in service, maybe you are
interested in a little twist to make it more reliable when running degraded
(Node down / unavailable).
I had unexpectedly high load on a surviving node, and wondered why gdb is
running wild there. Seems that there is a new debug function in CHM with
a serious bug that was not in in beta3, and that should be fixed in first
PSU, as I was told. A workaround is available:
Link:
http://www.usn-it.de/index.php/2017/06/20/oracle-rac-12-2-high-load-on-cpu-from-gdb-when-node-missing/
All comments are appreciated, as well as explanations about the background I
may have missed.
Best regards
--
Martin Klier | Performing Databases GmbH
Managing Partner | Senior DB Consultant
Oracle ACE
martin.klier@xxxxxxxxxxxxxxxxx | http://www.performing-databases.com
