一、 当客户端不能连接到它们的服务器时
1）客户端和服务器广播地址不匹配
确认在服务器主机和在客户端主机上的广播地址是相同的。在UNIX上用"netstat -i"或者"ifconfig -a"；在vxWorks上用ifShow；在Windows上用ipconfig检查这个。如果客户端和服务器不是直接连接到相同IP子网，广播地址不相同是正常的，并且在这种情况中必须设置EPICS_CA_ADDR_LIST。否则，如果客户端和服务器是在相同IP子网，则问题可能是在网卡配置中未正常设置IP子网掩码。在大多数操作系统中，当主机的IP地址被设置后，也设置主机的IP子网掩码。
2）未配置客户端使用服务器的端口
确认客户端和服务器使用相同的UDP端口。通过运行"netstat -a | grep nnnn"检查服务器的端口，此处nnnn是在客户端中配置的端口好。如果你没有设置EPICS_CA_SERVER_PORT或者EPICS_CAS_SERVER_PORT，则默认端口是5064。
orangepi@orangepizero2:~$ netstat -a | grep 5064
tcp 0 0 0.0.0.0:5064 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:5064 0.0.0.0:*3）在EPICS_CA_ADDR_LIST中的单播地址没有可靠的连接在相同主机上共享相同UDP端口的服务器端口。
两台服务器可以以相同服务器端口号运行在相同主机上，但有限制。如果主机有一个现代的IP内核，让两台或多台服务器共享相同UDP端口是可能的。对于这些服务器，要使用相同TCP端口运行在相同主机上是不可能的。如果CA服务器库发现一台服务器正在启动与一个已有CA服务器相同的端口上启动，则两台服务器将使用相同的UDP端口，并且第二台服务器将被分配一个临时TCP端口。注意，但如果有两台服务器运行在共享UDP端口的相同主机上，则它们都将接收到作为广播被发送的UDP搜索请求，但(由于大多数IP内核实现的弱点)一般仅一台服务器接收到被发送给单播地址(即：单个特定主机的IP地址)的UDP搜索请求。
4）客户端没有看到服务器的Beacons
两种冲突需要特别强调。首先，如果客户端没有看到服务区的beacons，则它将使用更多的网络和服务器资源发送周期的健康状态消息。第二，如果一个客户端没有看到一个新引入的服务器beacon，则它将最多使用EPICS_CA_MAX_SEARCH_PERIOD来查找新引入的服务器。从EPICS 3.14.7开始，在见到一个异常beacon前，在100词失败尝试后，客户端库不挂起搜索。因而，如果客户端库是来自EPICS 3.14.7版本前，并且它尝试查找一台其beacon不能被客户端库看到的服务器超时了，则为了连接到这台beacon超范围的服务器，需要重启这个客户端应用程序。客户端看不到服务器的beacon的一般情况是在客户端与服务器不是在相同IP子网，并且没有修改客户端的EPICS_CA_ADDR_LIST，因而服务器的beacon未被客户端接收到。
5）服务器的IP地址被更改了
当在虚电路上的通信超时了，则连接这个虚电路的每个通道进入一个未连接状态并且调用未那个通道指定的disconnect回调处理程序。但，在TCP/IP的内部(一般长持续时间)保活计时器超时前，虚电路未被断开。断开的通道保持连接到beleaguered电路并且不进行搜索或者一条重建新电路的尝试。如果在之后某个时间，这个电路再次有响应了，则被连接的通道再次进入一个连接状态并且reconnect回调处理程序被调用。任何monitor订阅接收一条更新消息，而断开的通道也被刷新。如果在任何时候，这个库从来自操作系统接收一个beleaguered电路已经关闭或者断开了的指示，则这个库将立即再次尝试未每个通道查找服务器并且连接电路到它们。
以上行为的一个众所周知的负作用是CA客户端在以下场景下(以下所有发生)在重连之前将等待TCP/IP的内部保活计时器完整的持续时间：
- 一台服务器的(IOC)操作系统崩溃(或者突然被关闭)或者通过任意方式停止一个vxWorks系统
- 这个操作系统没有使用相同的IP地址立即重启。
- 一个服务器(IOC)副本被启动，以一个不同IP地址出现。
任何理性组织在一个生产系统中采用以上场景是不可能的。在控制系统开发中可能会困扰用户。有人感到在系统集成中健壮性增强使得孤立的困扰合理化并且检查以上场景最可能发生的活动。
以上行为与R3.14.5之前发行板的CA客户端库相比较，在R3.14.5之前，当通过beleaguered电路上的通信超时时，这个电路立即被关闭。立即搜索任何连接的通道，并且在连续的搜索响应达到时，进行构建新电路的尝试。这种行为导致在CPU周期/网络/IP内核缓存拥塞时源自周期的电路设置和销毁开销的不想要的资源消耗。
6） 就在进程终止出现前写请求要被忽略
发出一个CA写请求的短存在时间并且立即退出这个进程(从main或调用exit)的CA客户端应用程序会发现那个请求未被执行。要确保请求被发送，在终止这个程序前，调用ca_flush_io()，接着ca_context_destroy()。
- 连接客户端总数多。每个活动的套接字需要专用mbufs用于协议控制块，以及在操作系统中用于在给定时间等待传输给通道访问或者网络可能的任何数据。如果你增加vxWorks对文件描述符最大数目的限制，则也需要增加mbuf池的大小。
- 服务器有多个连接，服务器在这些连接上的持续时间(monitor订阅更新)产生率高于客户端或网络的持续事件消耗率。这消耗了mbufs的每个套接字用于等待通过网络传递给客户端的数据的配额。如果有多个客户都安订阅了monitor事件，但没有调用ca_pend_event()或ca_poll()来处理它们的CA输入队列，则在服务器中明显的mbuf消耗积压会发生。
- 服务器没有获得运行的机会(因为某个其它更高优先级线程在运行)并且CA客户端通过TCP或UDP发送大量数据。这消耗了服务器中每个套接字的mbufs的配额(它未被服务器套接字read系统调用减少)。
- 服务器有多个旧连接。当客户端突然关闭或者从网络断开，并且一个内部"保活"计时器在操作系统中虚电路还未超时，旧连接出现，并且因而mbufs会专用于未被使用的虚电路。如果有与旧连接相关联的有效monitor订阅，这将对每个电路可用的配额快速增加专用mbufs数目。
- 当站点换到vxWorks 5.4 IP内核，它们频繁遇到网络池耗尽问题。这可能因为原来的vxWorks IP内核在运行时根据需要扩展网络池，而新的内核池在编译时静态配置，并且在运行时没有按需扩展。在某些站点，与vxWorks网络驱动池耗尽的问题也被报道(这也会导致ENOBUF诊断消息)。
二、ENOBUSF消息
很多Berkley UNIX派生的网络协议(IP)内核使用一个内存管理方法，具有一个称为"mbuf"的固定大小的低级别内存分配量。有关"ENOBUFS"的消息是一个你IP内核的mbuf缓冲区不足的指示。IP内核mbuf不足情况会导致暂时的IP通信中断或者降低的吞吐量。这个问题到目前主要与vxWorks系统相关联，谣传在更早vxWorks版本的VxWorks系统上mbuf不足导致永远的IP通信中断，只能通过系统重启解决。频繁使用mbufs的IP内核允许初始的和最大的mbufs数目被配置。不同OS之间，甚至相同OS不同版本之间的配置过程不同，参考你的OS的文档。
相关的诊断
- EPICS命令"casr [interest level]"显示有关CA服务器以及连接了多少客户端的信息。
epics> casr
Channel Access Server V4.13
No clients connected.
epics> casr 1
Channel Access Server V4.13
No clients connected.
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
epics> casr 2
Channel Access Server V4.13
1 client connected:
TCP client at 192.168.50.181:57046 'main-machine':
User 'blctrl', V4.13, Priority = 0, 1 Channel
Channel: 'GPIO:LOSET'
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Last name requested by 192.168.50.181:50701:
User '', V4.13, Priority = 0, 0 Channels
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
epics> casr 3
Channel Access Server V4.13
1 client connected:
TCP client at 192.168.50.181:57046 'main-machine':
User 'blctrl', V4.13, Priority = 0, 1 Channel
Channel: 'GPIO:LOSET'
field_type=DBF_LONG (4 bytes), dbr_type=DBF_LONG, 1 element, no filters
# on eventq=1, access=rw
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Last name requested by 192.168.50.181:50701:
User '', V4.13, Priority = 0, 0 Channels
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
epics> casr 4
Channel Access Server V4.13
1 client connected:
TCP client at 192.168.50.181:57046 'main-machine':
User 'blctrl', V4.13, Priority = 0, 1 Channel
Task Id = 0xffff4c005f00, Socket FD = 3
6.95 secs since last send, 6.95 secs since last receive
Unprocessed request bytes = 0, Undelivered response bytes = 0
State = up
Channel: 'GPIO:LOSET'
field_type=DBF_LONG (4 bytes), dbr_type=DBF_LONG, 1 element, no filters
# on eventq=1, access=rw
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Last name requested by 192.168.50.181:50701:
User '', V4.13, Priority = 0, 0 Channels
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
Free-lists total 316904 bytes, comprising
6 client(s), 511 channel(s), 511 monitor event(s), 0 putNotify(s)
14 small (16384 byte) buffers, 4294967295 jumbo (16408 byte) buffers
Server resource id table:
Bucket entries in use = 1 bytes in use = 32832
Bucket entries/hash id - mean = 0.000244 std dev = 0.015623 max = 1
epics> casr 5
Channel Access Server V4.13
1 client connected:
TCP client at 192.168.50.181:57046 'main-machine':
User 'blctrl', V4.13, Priority = 0, 1 Channel
Task Id = 0xffff4c005f00, Socket FD = 3
15.44 secs since last send, 15.44 secs since last receive
Unprocessed request bytes = 0, Undelivered response bytes = 0
State = up
Channel: 'GPIO:LOSET'
field_type=DBF_LONG (4 bytes), dbr_type=DBF_LONG, 1 element, no filters
# on eventq=1, access=rw
656 bytes allocated
Send Lock:
epicsMutexId 0xffff4c000c60 source ../rsrv/caservertask.c line 1259
pthread_mutex_t* uaddr=0xffff4c000c20
Put Notify Lock:
epicsMutexId 0xffff4c000cd0 source ../rsrv/caservertask.c line 1260
pthread_mutex_t* uaddr=0xffff4c000c90
Address Queue Lock:
epicsMutexId 0xffff4c000d40 source ../rsrv/caservertask.c line 1261
pthread_mutex_t* uaddr=0xffff4c000d00
Event Queue Lock:
epicsMutexId 0xffff4c000db0 source ../rsrv/caservertask.c line 1262
pthread_mutex_t* uaddr=0xffff4c000d70
Block Semaphore:
epicsEvent 0xffff4c000bb0: empty
pthread_mutex = 0xffff4c000bb0, pthread_cond = 0xffff4c000be0
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Last name requested by 192.168.50.181:50701:
User '', V4.13, Priority = 0, 0 Channels
Task Id = 0xaaab194d5840, Socket FD = 8
45.55 secs since last send, 45.55 secs since last receive
Unprocessed request bytes = 0, Undelivered response bytes = 16
State = up
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
Free-lists total 316904 bytes, comprising
6 client(s), 511 channel(s), 511 monitor event(s), 0 putNotify(s)
14 small (16384 byte) buffers, 4294967295 jumbo (16408 byte) buffers
Server resource id table:
Bucket entries in use = 1 bytes in use = 32832
Bucket entries/hash id - mean = 0.000244 std dev = 0.015623 max = 1
epics> casr 6
Channel Access Server V4.13
1 client connected:
TCP client at 192.168.50.181:57046 'main-machine':
User 'blctrl', V4.13, Priority = 0, 1 Channel
Task Id = 0xffff4c005f00, Socket FD = 3
2.70 secs since last send, 2.70 secs since last receive
Unprocessed request bytes = 0, Undelivered response bytes = 0
State = up
Channel: 'GPIO:LOSET'
field_type=DBF_LONG (4 bytes), dbr_type=DBF_LONG, 1 element, no filters
# on eventq=1, access=rw
656 bytes allocated
Send Lock:
epicsMutexId 0xffff4c000c60 source ../rsrv/caservertask.c line 1259
pthread_mutex_t* uaddr=0xffff4c000c20
Put Notify Lock:
epicsMutexId 0xffff4c000cd0 source ../rsrv/caservertask.c line 1260
pthread_mutex_t* uaddr=0xffff4c000c90
Address Queue Lock:
epicsMutexId 0xffff4c000d40 source ../rsrv/caservertask.c line 1261
pthread_mutex_t* uaddr=0xffff4c000d00
Event Queue Lock:
epicsMutexId 0xffff4c000db0 source ../rsrv/caservertask.c line 1262
pthread_mutex_t* uaddr=0xffff4c000d70
Block Semaphore:
epicsEvent 0xffff4c000bb0: empty
pthread_mutex = 0xffff4c000bb0, pthread_cond = 0xffff4c000be0
CAS-TCP server on 0.0.0.0:5064 with
CAS-UDP name server on 0.0.0.0:5064
Last name requested by 192.168.50.181:50701:
User '', V4.13, Priority = 0, 0 Channels
Task Id = 0xaaab194d5840, Socket FD = 8
62.91 secs since last send, 62.91 secs since last receive
Unprocessed request bytes = 0, Undelivered response bytes = 16
State = up
280 bytes allocated
Send Lock:
epicsMutexId 0xffff50001550 source ../rsrv/caservertask.c line 1259
pthread_mutex_t* uaddr=0xffff50001510
Put Notify Lock:
epicsMutexId 0xffff500015c0 source ../rsrv/caservertask.c line 1260
pthread_mutex_t* uaddr=0xffff50001580
Address Queue Lock:
epicsMutexId 0xffff50001630 source ../rsrv/caservertask.c line 1261
pthread_mutex_t* uaddr=0xffff500015f0
Event Queue Lock:
epicsMutexId 0xffff500016a0 source ../rsrv/caservertask.c line 1262
pthread_mutex_t* uaddr=0xffff50001660
Block Semaphore:
epicsEvent 0xffff500014a0: empty
pthread_mutex = 0xffff500014a0, pthread_cond = 0xffff500014d0
Sending CAS-beacons to 2 addresses:
192.168.3.255:5065
192.168.50.255:5065
Free-lists total 316904 bytes, comprising
6 client(s), 511 channel(s), 511 monitor event(s), 0 putNotify(s)
14 small (16384 byte) buffers, 4294967295 jumbo (16408 byte) buffers
Server resource id table:
Bucket entries in use = 1 bytes in use = 32832
Bucket entries/hash id - mean = 0.000244 std dev = 0.015623 max = 1
- vxWorks命令"inetstatShow"指明了在mbufs中多少字节待发送并且间接地(根据列出地电路数目)已经消耗了基于mbuf地协议控制块。vxWorks命令mbufShow，netStackSysPoolShow和netStackDataPoolShow表明在网络栈池中还有多少空间。
- RTEMS命令"netstat [interest level]"显示了mbuf消耗统计的网络信息。
三、服务器订阅更新队列
如果订阅更新产生者在服务器中生产订阅更新快于订阅更新消费者在客户端消耗它们，则如果在服务器中缓存不允许增加到无限大小，则事件必须被丢弃。
做什么取决于CA服务器的版本。所有服务器版本在任何时候对订阅更新队列上可用的最大订阅更新数目做了配额限制。如果达到了限制，居间更新被丢弃，支持更新的更新。取决于服务器的版本，快速更新订阅用受限方式被允许或不被允许使用使用慢速更新订阅的配额。然而，在队列中总是有用于每个订阅的最少一个更新的空间。这保证了最新更新总是被发送。
1109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
