PRVF-5636 : The DNS response time for an unreachable node exceeded "15000" ms on following nodes

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: <div style="color:rgb(0,61,91); font-family:Simsun; font-size:12px"><span id="pt1:sd_r1:0:dv_rDoc:ot71" style="color:black"></span> <p style="line-height:22px"><strong>In this Document</strong><

In this Document

  Purpose
  Details
  References

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

APPLIES TO:

Oracle Server - Enterprise Edition - Version 11.2.0.1 and later
Information in this document applies to any platform.

PURPOSE

The note explains what to look for when experiencing the following error:

PRVF-5636 : The DNS response time for an unreachable node exceeded " 15000" ms on following nodes: racnode1

 



DETAILS

Cluster Verification (cluvfy or CVU) detects whether DNS is configured properly by looking up an unknown host and expecting the command to finish in less than 15 seconds.

$ nslookup unknown-not-reachable-node

Case 1: nslookup takes too long time

In below example, it takes over 18 seconds thus the error is generated:

time nslookup unknown-not-reachable-node
;; connection timed out; no servers could be reached
.
real    0m18.020s
user    0m0.001s
sys     0m0.005s


As nslookup is OS tool, please engage System/Network Administrator to find out why it takes so long and fix it.

REFERENCES

BUG:11775332 - CLUVFY FAILS WITH PRVF-5636 WITH DNS RESPONSE TIMEOUT ERROR
NOTE:1480242.1 - PRVF-5637 : DNS response time could not be checked on following nodes
目录
相关文章
|
6月前
|
Kubernetes 容器
Warning FailedScheduling 14m (x12 over 16m) default-scheduler 0/1 nodes are available: 1 node(s
Warning FailedScheduling 14m (x12 over 16m) default-scheduler 0/1 nodes are available: 1 node(s
122 0
|
分布式数据库 Hbase
File /hbase could only be replicated to 0 nodes instead of minReplication (=1). There are 30 datanode(s) running and no node(s) are excluded in this
原因: hdfs-site.xml中的配置为: dfs.datanode.du.reserved 400000000000  dfs.datanode.du.reserved值太大了,预留近400G。 设小一点就可以了10737418240,例如10G。
2578 0
|
6天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
21 2
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
67 0
|
1月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
54 0
|
1月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
60 0
|
1月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
83 0
|
7天前
|
存储 安全 Linux
Golang的GMP调度模型与源码解析
【11月更文挑战第11天】GMP 调度模型是 Go 语言运行时系统的核心部分,用于高效管理和调度大量协程(goroutine)。它通过少量的操作系统线程(M)和逻辑处理器(P)来调度大量的轻量级协程(G),从而实现高性能的并发处理。GMP 模型通过本地队列和全局队列来减少锁竞争,提高调度效率。在 Go 源码中,`runtime.h` 文件定义了关键数据结构,`schedule()` 和 `findrunnable()` 函数实现了核心调度逻辑。通过深入研究 GMP 模型,可以更好地理解 Go 语言的并发机制。
|
19天前
|
消息中间件 缓存 安全
Future与FutureTask源码解析,接口阻塞问题及解决方案
【11月更文挑战第5天】在Java开发中,多线程编程是提高系统并发性能和资源利用率的重要手段。然而,多线程编程也带来了诸如线程安全、死锁、接口阻塞等一系列复杂问题。本文将深度剖析多线程优化技巧、Future与FutureTask的源码、接口阻塞问题及解决方案,并通过具体业务场景和Java代码示例进行实战演示。
39 3

相关产品

  • 云解析DNS
  • 推荐镜像

    更多