Open 372046933 opened 1 year ago
用的是什么样的业务?是example么?怎样的测试?
不是example,场景是一个分布式训练任务,打开RDMA开关后会出现。有没有啥辅助日志可以帮助排查的,类似TF VLOG那种?
这类错误可能是多个线程同时访问一个IOBuf导致的。先禁掉zero copy看看是否还必现?rdma_recv_zerocopy=false(禁用接收端zerocopy),rdma_zerocopy_min_size=[比较大的值](禁用发送端zerocopy)。先确认下是rpc内部竞争了,还是rpc和上面的应用之间竞争了。
设置了rdma_recv_zerocopy=false
, rdma_zerocopy_min_size=1073741824
. 还是会出现异常
服务端:
W0530 12:26:38.156749 812 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=678 fd=1331 addr=10.156.8.33:51496:19269} (0x562e43640000) due to unknown message: 7\D80\B5\B6\B6\E0\B8\B5k\8A\AE7H\CF\B27\F1\7F\947\92\E8\0F\B6\D1\A1\816\85j%\B7V\D6\BF7\C6\C0T\B7\9EP\80\B7`h\033\A5\BF68lG\F76\9E^\877\F5\B2w...<skipping 7205 bytes>
客户端:
[E1014]Got EOF of Socket{id=12 fd=1354 addr=10.156.8.33:12455:33556}
是每次报错都来自server端吗?能否提供更多的复现方法或者问题触发时的特征?
每次都是Server端先报错:Close socket...
,客户端此时会出现成片的RPC 失败。我在客户端增加了重试逻辑,RPC是可以成功的,但是重试前发生了啥?有没有副作用? 我还在确认中。
在使用TCP时,没有出现过类似报错
客户端此时会出现成片的RPC 失败
是一个客户端的多个RPC失败,还是多个客户端的RPC失败?
前者,一个客户端的多个RPC失败
rdma_recv_zerocopy=false(禁用接收端zerocopy),rdma_zerocopy_min_size=[比较大的值](禁用发送端zerocopy)
抱歉,我刚查了一下代码,上面这个说法有问题。rdma_zerocopy_min_size=[比较大的值]禁用的仍然是接收端zerocopy。发送端zerocopy暂时没法通过Flag禁用。我去做个版本,支持下关闭发送端zerocopy你再试试
https://github.com/apache/brpc/pull/2267 可以试下这个PR。
这种IOBuf数据问题debug确实有些困难。如果打log数据量太大了
BRPC_WITH_RDMA=true
, 检查不出来禁用send_zerocopy之后,
W0601 12:06:39.288266 18290 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:1412] Fail to handle RDMA completion, error status(4): Socket{id=8589934594 fd=1337 addr=127.0.0.1:1234:24360} (0x0x5640308974c0): Resource temporarily unavailable
2023-06-01 12:06:39.288390: W ./tensorswitch/client/handle_base.h:119] Method:[Ping] Fail to get response from shard#0 [E3001]RDMA completion error(4) from Socket{id=8589934594 fd=1337 addr=127.0.0.1:1234:24360} (0x0x5640308974c0): RDMA verbs error, retry#9 request:
你使用的rdma相关的flag都有哪些?能否贴一下看看
rdma_recv_zerocopy=true
rdma_zerocopy_min_size=512
rdma_send_zerocopy=false
其他的flag有设置吧?block size什么的
没有,~发现同时禁用send/recv zerocopy可以跑了,不能单独禁用send_zerocopy~
多节点运行还是不行
Fail to handle RDMA completion, error status(4): Socket{id=32 fd=1334 addr=10.156.1.16:24615:18398} (0x0x5637deabe800): Resource temporarily unavailable
程序里面是否有调用RegisterMemoryForRdma专门注册其他内存?
有的,关闭zerocopy之后,不能再调用RegisterMemoryForRdma?
那就是程序内有使用append_user_data直接使用了外部的内存,并且做了单独的注册对吧?不过你这个错误我目前还没在本地复现出来。还有别的线索吗
那就是程序内有使用append_user_data直接使用了外部的内存,并且做了单独的注册对吧?不过你这个错误我目前还没在本地复现出来。还有别的线索吗
是的,区别只是rdma_send/recv_zerocopy传false,传true能跑,传false不能
我目前仍然无法本地复现这样的问题。你们的程序里是否主动调用了ibverbs的发送?这个错误显示的是发送的数据没有在被注册的Memory Region内。
我目前仍然无法本地复现这样的问题。你们的程序里是否主动调用了ibverbs的发送?这个错误显示的是发送的数据没有在被注册的Memory Region内。
有获取brpc::rdma::GetRdmaPd
, 接着调用ibv_reg_mr
,没有主动调用ibv send/recv相关 API
如果是裸调ibv_reg_mr的,注册下来的mkey是通过append_user_data_with_meta传进去的是吧?
是的,不然禁用zerocopy之前,也跑不起来
应该是没commit全。再试试呢
和之前的问题没有关系。是禁用zero_copy的时候复用了这个函数。
和之前的问题没有关系。是禁用zero_copy的时候复用了这个函数。
上面那个不改,master分支有问题吗?
不开send zero copy就没啥问题。如果出问题会出Fail to handle RDMA completion, error status(4)这类错误。
不开send zero copy就没啥问题。如果出问题会出Fail to handle RDMA completion, error status(4)这类错误。
默认send_zerocopy=True,这是master有问题的意思吗?
master没有问题
send/recv zerocopy=false,还是会出现异常日志
W0602 23:10:01.090063 1031 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=8589934610 fd=294 addr=10.156.122.18:17758:23081} (0x55d5ce252880) due to unknown message: \FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F...<skipping 32576 bytes>
W0602 23:10:01.090279 1031 external/brpc/src/brpc/policy/baidu_rpc_protocol.cpp:265] Fail to write into Socket{id=8589934610 fd=294 addr=10.156.122.18:17758:23081} (0x55d5ce252880): Invalid argument
W0602 23:10:01.198151 1108 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:565] Fail to read Hello Message from client:Socket{id=3842 fd=288 addr=10.156.122.18:18296:23081} (0x0x55ddf4440000) 10.156.122.18:18296: Got EOF
I0602 23:18:31.035560 1103 external/brpc/src/brpc/socket.cpp:2451] Checking Socket{id=14 addr=10.156.8.16:22455} (0x55d5ce251f80)
I0602 23:18:31.036291 998 external/brpc/src/brpc/socket.cpp:2511] Revived Socket{id=14 addr=10.156.8.16:22455} (0x55d5ce251f80) (Connectable)
E0602 23:24:01.236915 1047 external/brpc/src/brpc/input_messenger.cpp:122] Fail to parse response from 10.156.8.12:29267 by baidu_std at client-side
W0602 23:24:01.236942 1047 external/brpc/src/brpc/input_messenger.cpp:247] Close Socket{id=8589934599 fd=296 addr=10.156.8.12:29267:65416} (0x55d5ce250fc0): absolutely wrong message
I0602 23:24:01.340163 1038 external/brpc/src/brpc/socket.cpp:2451] Checking Socket{id=8589934599 addr=10.156.8.12:29267} (0x55d5ce250fc0)
I0602 23:24:01.340711 849 external/brpc/src/brpc/socket.cpp:2511] Revived Socket{id=8589934599 addr=10.156.8.12:29267} (0x55d5ce250fc0) (Connectable)
另外提供个信息,切换到RDMA之后,训练不正常了(IOBuf传的是一堆float,切换到RDMA后接收端出现很多NaN)。怀疑数据发送过程中出现了异常。
还是因为iobuf的数据乱了。需要更多的信息。看能否在出错的地方出个core?
出现这个日志的时候,客户端没捕捉到,是不是哪里错误没有回传?
很多的NaN,根据那些不是NaN的,能判断出是什么数据吗
打印的时候按照float解析IOBuf内容的,不好判断
当某个节点出现异常日志是,另一端(10.156.8.16)上没有任何异常日志
W0607 18:08:44.002235 661 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=8589934640 fd=1395 addr=10.156.8.16:25696:10643} (0x5616d4012c00) due to unknown message: \00\00\00\00\00\00\80?\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80?\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80?...<skipping 8096 bytes>
W0607 18:08:44.002683 661 external/brpc/src/brpc/policy/baidu_rpc_protocol.cpp:265] Fail to write into Socket{id=8589934640 fd=1395 addr=10.156.8.16:25696:10643} (0x5616d4012c00): Invalid argument
W0607 18:08:44.106501 626 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:564] Fail to read Hello Message from client:Socket{id=2149 fd=1395 addr=10.156.8.16:26662:10643} (0x0x561c9d2e8480) 10.156.8.16:26662: Got EOF
当某个节点出现异常日志是,另一端(10.156.8.16)上没有任何异常日志
W0607 18:08:44.002235 661 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=8589934640 fd=1395 addr=10.156.8.16:25696:10643} (0x5616d4012c00) due to unknown message: \00\00\00\00\00\00\80?\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80?\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80?...<skipping 8096 bytes> W0607 18:08:44.002683 661 external/brpc/src/brpc/policy/baidu_rpc_protocol.cpp:265] Fail to write into Socket{id=8589934640 fd=1395 addr=10.156.8.16:25696:10643} (0x5616d4012c00): Invalid argument W0607 18:08:44.106501 626 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:564] Fail to read Hello Message from client:Socket{id=2149 fd=1395 addr=10.156.8.16:26662:10643} (0x0x561c9d2e8480) 10.156.8.16:26662: Got EOF
这个问题没有本地复现的话不是很容易定位。上面显示的unknown的数据有什么特征吗?错误发生的时间前后有什么迹象吗?错误的发生和规模、执行时长、数据长度有什么关联吗?上层业务调用rpc的模式是否可能用rdma的example来表达?
很随机,有时十几分钟出现,有时要几个小时才能出现。用RPC example模拟是个办法,完全实现相同逻辑成本有点高。
时序上是
先出现 Close Socket
Close Socket{id=8589934931 fd=1341 addr=10.156.1.11:61768:25823} (0x55f2f6f6c000) due to unknown message: \B6\80\F5#8\D1$\A3\B6\0C\E7\CE6\DA;\018J\E3\B1\B7Q\EE\FD\B7\F8\01\0B8U\1Bn\B8\11,\t\B8d\18W\B6~+\04\B8 \B9\E16k\E0$\B7\C1\13\E1\B7~"\91\B4\E5\8BS...<skipping 200964 bytes>
然后 Fail to write into Socket
Fail to write into Socket{id=8589934931 fd=1341 addr=10.156.1.11:61768:25823} (0x55f2f6f6c000): Invalid argument
然后 Fail to read Hello message
Fail to read Hello Message from client:Socket{id=3842 fd=1341 addr=10.156.1.11:18802:25823} (0x0x55fb763c8000) 10.156.1.11:18802: Got EOF
成片RPC失败
[E1014]Got EOF of Socket{id=4 fd=1336 addr=10.156.8.29:25823:61768} (0x0x55aa6dfb8900) [R1][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R2][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R3][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R4][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R5][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R6][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R7][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R8][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R9][E112]Not connected to 10.156.8.29:25823 yet, server_id=4 [R10][E112]Not connected to 10.156.8.29:25823 yet, server_id=4
还有个思路是接受目前的Socket异常,应用层做好重试,由于每次RPC都是有Side effect. 这样的话需要Server端做好重复请求的去重
跟RDMA开启后, TCP连接没有活动有关系吗?是不是设置一下socket keep alive就不会出现socket意外关闭的情况了
@Tuvie 如果socket突然中断,Controller的request_attachment IOBuf会失效吗?
W0614 17:27:19.743685 648 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=8589936515 fd=1391 addr=10.156.0.21:10526:23795} (0x5581768c8480) due to unknown message: \A2=\D6\1C\DB=\00\00\00\00\B9\F9\17>!xG=\04E\B8>\00\00\00\00V\83\B1>\80\9D6=O\8B\BA>\FB\BD\A5\BE\D8p\90\BE\BB\D7\B0\BE0\9F\85\BE\D1\EC\BA>\03\94$\BEH[...<skipping 16256 bytes>
2023-06-14 17:27:19.744594: F tensorswitch/data_channel.cc:89] Got NaN requst:src_channel_id: 262145 src_peer_id: 2 packet_id: 245 request_id: 1668912995582877696
Fatal Python error: Aborted
跟RDMA开启后, TCP连接没有活动有关系吗?是不是设置一下socket keep alive就不会出现socket意外关闭的情况了
应该没有关系。现在server出了问题,会主动关闭连接,所以client看到一系列的rpc失败。
如果socket突然中断,Controller的request_attachment IOBuf会失效吗?
不会。socket和controller基本上是解耦的。
跟RDMA开启后, TCP连接没有活动有关系吗?是不是设置一下socket keep alive就不会出现socket意外关闭的情况了
应该没有关系。现在server出了问题,会主动关闭连接,所以client看到一系列的rpc失败。
如果socket突然中断,Controller的request_attachment IOBuf会失效吗?
不会。socket和controller基本上是解耦的。
我这边能明显的看到socket中断时,IOBuf内容失效(其中的float变成NaN)。通过Controller IsCanceled判断连接状态后,可以绕过这个问题。
@Tuvie 这个地方的PostRecv在RTR之前,实际不生效。需要放到QP RTR之后吗? https://github.com/apache/brpc/blob/2729272ae5ee69e4c4142d14b7fafbf800944316/src/brpc/rdma/rdma_endpoint.cpp#L1171
RTR是说ready to receive packet,post receive是可以的。你说不生效是测试报错了吗
没有报错,就是想问下,实际上这些WR会等到RTR状态再处理的对吧?
另外想请教下,类似Socket EOF的报错,应该怎么排查呢?我不太清楚这里面的状态机咋维护的。看日志有点像socket状态流转不对。
W0724 15:26:52.624647 564 external/brpc/src/brpc/input_messenger.cpp:240] Close Socket{id=8589935851 fd=1410 addr=10.156.8.30:64506:16619} (0x55b62c9a4400) due to unknown message: \FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\00\00\00\00\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF\FF\7F\FF\FF...<skipping 7358 bytes>
W0724 15:26:52.624847 564 external/brpc/src/brpc/policy/baidu_rpc_protocol.cpp:265] Fail to write into Socket{id=8589935851 fd=1410 addr=10.156.8.30:64506:16619} (0x55b62c9a4400): Invalid argument
I0724 15:26:52.727919 551 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:559] Start handshake on Socket{id=8589935271 fd=1410 addr=10.156.8.30:26734:16619} (0x0x55b5ed984240)
W0724 15:26:52.727974 551 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:567] Fail to read Hello Message from client:Socket{id=8589935271 fd=1410 addr=10.156.8.30:26734:16619} (0x0x55b5ed984240) 10.156.8.30:26734: Got EOF
I0724 15:26:52.728424 542 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:559] Start handshake on Socket{id=8589937304 fd=1410 addr=10.156.8.30:26736:16619} (0x0x55b62e366000)
I0724 15:26:52.733604 560 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:695] Handshake ends (use rdma) on Socket{id=8589937304 fd=1410 addr=10.156.8.30:26736:16619} (0x0x55b62e366000)
I0724 15:20:20.888519 1066 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:559] Start handshake on Socket{id=2490 fd=1339 addr=10.156.0.33:47142:25191} (0x0x5630d760a900)
W0724 15:20:20.888569 1066 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:567] Fail to read Hello Message from client:Socket{id=2490 fd=1339 addr=10.156.0.33:47142:25191} (0x0x5630d760a900) 10.156.0.33:47142: Got EOF
I0724 15:20:25.786496 1085 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:559] Start handshake on Socket{id=2491 fd=1423 addr=10.156.0.33:47152:25191} (0x0x5630d760ab40)
I0724 15:20:25.793311 1090 external/brpc/src/brpc/rdma/rdma_endpoint.cpp:695] Handshake ends (use rdma) on Socket{id=2491 fd=1423 addr=10.156.0.33:47152:25191} (0x0x5630d760ab40)
RTR状态之前不会处理的。 你是指上面的问题是发生在连接刚刚创建,是吗?
不是发生在刚刚创建。在通信过程中发生的,会不会是send/recv pair错乱了导致?从我的出现频率看,QPS高了之后比较容易出现
Describe the bug (描述bug)
To Reproduce (复现方法) master分支,RDMA打开的情况,数小时之内必现
Expected behavior (期望行为)
Versions (各种版本) OS: Compiler: brpc: protobuf:
Additional context/screenshots (更多上下文/截图)