Archive for November, 2013

设置变量GIT_CURL_VERBOSE可以帮助调试git出错

今天操作git的时候又出错了:

error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed

 

之前用公司的http代理上git, 

#git config -l

http.proxy=http://web-proxy.oa.com:8080

 

设置变量GIT_CURL_VERBOSE可以看到详细的出错情况:

#export GIT_CURL_VERBOSE=1

# git pull
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
*   Trying 10.14.36.100...
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0) 
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
*   Trying 10.14.36.100...
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0) 
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed

copyright blog.ykyi.net

 

 

 

Be the first to comment - What do you think?  Posted by zausiu - November 27, 2013 at 12:43

Categories: Uncategorized   Tags:

packet captured和packet received by filter到底有什么区别

我用的是linux. 结论是 packet received by filter是tcpdump从内核中拿到的且匹配命令上行指定的过滤条件的包, packet captured是经由pcap_loop, 或 pcap_dispatch 或 pcap_next,把包交给回调处理过的包的数量。这两个数字的差值是tcpdump抓到的,还来不及处理的包。

下面是讨论的一些细节:

/////////////

tcpdump的最后输出. 592个包captured,  1184个包received by filter。。这个差值是不是表示有多少包tcpdump没来得及处理.

man tcpdump上写得好复杂,received by filter的数字取决于OS... 1. 包匹配不匹配命令行上指定的filter都算,如果匹配,有没有被tcpdump读出都算..   2. 只有匹配命令行上指定的filter的包才算,有没有被tcpdump读出都算.   3. 只有匹配filter才算,只有被tcpdump读出才算.

我的理解是:如果是第3种,那captured的数字和received by filter的数字就是一样的。 第2种的差值表示tcpdump来不及处理的包数量,理想状态上差值能为0.   第1种情况,基本上总是有差值。

我猜测我用的linux上应该是第2种情况. 

wangbin579() 10:18:54 
应该是匹配的才算received by filter,但奇怪的是,为啥你的系统,captured怎么少?
wangbin579() 10:19:30 
[root@hz0-12-157 ~]# tcpdump -i any tcp and port 36524 or 3306 -w all.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10757 packets captured
11171 packets received by filter
334 packets dropped by kernel
wangbin579() 10:20:07 
我们这边系统,基本可以认为packets received by filter=packets captured + packets dropped by kernel

siu¹ººººººº() 10:23:38 
/homemus/tmp # time time tcpdump -i tunl0:1  -w tmp
tcpdump: listening on tunl0:1, link-type RAW (Raw IP), capture size 96 bytes
19508 packets captured
39021 packets received by filter
0 packets dropped by kernel
0.01user 0.02system 0:17.04elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+506minor)pagefaults 0swaps

real    0m17.139s
user    0m0.012s
sys     0m0.028s
wangbin579() 10:26:03 
如果是差是丢包,那么通过查看抓包文件,应该能看出很多不完整的session
siu¹ººººººº() 10:28:46 
我觉得差值是来不及写入磁盘的包.
siu¹ººººººº() 10:29:04 
再研究看看了。。谢谢啦/..
wangbin579() 10:30:03 
packets captured是pcap_loop所设置的回调函数所调用的,一旦调用回调函数,就用统计
wangbin579() 10:30:37 
有可能内核态部分和用户态部分,速度上不匹配,有延迟导致的?
siu¹ººººººº() 10:32:33 
我现在理解, received by filter是pcap库从内核中拿到的又匹配命令行上filter的包的数量, packets captured是经由pcap_loop, pcap_dispatch之类通过callback交付出去的包数量. 差值就是还没来得及处理的.
wangbin579() 10:32:48 
17s,每秒也就2000多个,不算多,用户态程序应该来得及处理

wangbin579() 10:33:58 
我这边系统很破,处理速度也比这个快,也没有来不及处理
wangbin579() 10:34:45 
看看我的:
wangbin579() 10:34:47 
[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:35:52 
量比你大7倍多,也没有出现来不及处理啊,当然我的是物理机,3G内存,
siu¹ººººººº() 10:36:59 
 那你觉得这个差值不是来不及处理的包么?。我觉得应该还是来不及处理的。我在想,可能是写到的磁盘文件系统是NFS之类的 ....我继续排查一下。
wangbin579() 10:37:43 
有可能,我的是写入本地磁盘。
wangbin579() 10:37:58 
你这种情况,我还是第一次碰到
siu¹ººººººº() 10:39:05 
我先去运维那边了解下情况...多谢啦 
wangbin579() 10:39:18 
算涨见识了,还以为一般dropped by kernel为0就代表不丢包呢,居然还有你这种情况。
你可以看看抓包文件,session是不是很多不完整,如果不完整,你的推测是对的
siu¹ººººººº() 10:39:58 
嗯。呵呵~~ 做IT,每天都会碰到挑战宇宙规律的现象。
siu¹ººººººº() 10:40:07 

мe(~ o мe(632813052) 10:41:09 
呵呵
wangbin579() 10:41:24 
其实,网络方面的问题,最复杂了。
我现在已经陷入到网络的汪洋大海之中了,各种各样的问题都会有,而且没有尽头。
早知道如此,3年前我就不搞这一块了
siu¹ººººººº() 10:42:30 
同感。写一点点代码,都非常难以调试。各种认为理所当然的假设,通通是bug的温床

@wangbin579  麻烦你在tcpdump前加个time,。。把输出贴出来。我好像看出问题来了。

[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:56:03 
不是加了time了吗?
wangbin579() 10:57:15 
[root@hz0-12-157 ~]# time time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C202061 packets captured
202523 packets received by filter
369 packets dropped by kernel
0.66user 2.50system 0:11.99elapsed 26%CPU (0avgtext+0avgdata 24208maxresident)k
0inputs+105656outputs (0major+660minor)pagefaults 0swaps

real    0m11.999s
user    0m0.661s
sys     0m2.506s
wangbin579() 10:57:26 
加两个,结果如上
siu¹ººººººº() 10:59:29 
问题找到的。我这边运行的tcpdump,根本就没有抢到cpu时间来处理.
wangbin579() 11:00:05 

siu¹ººººººº() 11:00:06 

Real  0m3.914s

User  0m0.008s

Sys   0m0.000s

跑了4秒钟,用户空间才抢到0.008秒,内核态几乎是0 ....
siu¹ººººººº() 11:00:25 
那个差值确实是没有来得及处理的包的数量。
wangbin579() 11:00:41 
奥,那你系统这么繁忙啊

siu¹ººººººº() 11:02:22 
所以,解决了一个问题又会有新的颠覆宇宙规律的问题...系统负载很高,但cpu使用率很低。。

copyright blog.ykyi.net

 

Be the first to comment - What do you think?  Posted by zausiu - November 22, 2013 at 13:22

Categories: Unix / Linux   Tags:

昨天解决了tcpcopy的一个小却很重要的bug.

tcpcopy的基础函数有个bug,流量比较大的时候,内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。然后加入了tcpcopy的QQ群,和作者稍稍讨论了一点时间。问了关于写论文和tc_session.c过于复杂的问题。

(wangb) 10:00:55 
https://github.com//tcpcopy/pull/162
(wangb) 10:01:04 
The bug arises when send system call returns with part of data transfered
and part of data still need to be sent again.
(wangb) 10:01:13 
常见于压力比较大的场合
(wangb) 10:02:14 
当然如果系统参数设置好的话,这样的情况不常见。这也是为啥我这边无法重现的原因所在
(wangb) 10:02:46 
当然昨天在开发gryphon,貌似遇到过一次
(wangb) 10:03:06 
gryphon给的压力,有时候真不是一般快和大
siu1ooooooo(16236914) 10:03:14 
我在tcpcopy上作二次开发。碰到了个bug,最后追踪到了 tc_socket_send函数。
siu1ooooooo(16236914) 10:03:52 
流量比较大的时候,内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。
siu1ooooooo(16236914) 10:05:21 
希望能贡献更多代码的。。但是tc_session.c这个模拟tcp状态机的代码太难看懂了。
(wangb) 10:05:49 
有些bug,程序员自身很难发现,往往需要依赖于用户的反馈,当然有上面的bug提出,就更好了
tc_session.c这个模拟tcp状态机,其实不仅模拟tcp状态机,而为复杂的是模拟上层应用交互
光模拟tcp状态机,是远远不够的
siu1ooooooo(16236914) 10:07:27 
有个想法, 把TCP的11个标准状态加入到tc_session中。可不可以做的。.
(wangb) 10:09:13 
数据是死的,但测试服务器是活的。应该可以吧,但加入可能会更复杂。tc_session.c这个会进一步改进的,代码需简化和功能需独立,使其易懂
siu1ooooooo(16236914) 10:09:31 
🙂
(wangb) 10:10:33 
2010~2012.5月,初步探索阶段;2012.5~2014.5,为进一步探索阶段 2014.5~以后,进一步优化
因为tcpcopy刚开始,开发人员是无法知道复杂的互联网的各种应用的特性的,只有积累到一定程度,才能进一步优化。与其说是开发,不如说是探索
siu1ooooooo(16236914) 10:12:10 
期待工程paper  
siu1ooooooo(16236914) 10:12:43 
tcpcopy稳定到了一个版本。先别加功能了。写paper吧  
siu1ooooooo(16236914) 10:13:01 
投中EI应该问题不大。
siu1ooooooo(16236914) 10:13:55 
中了paper,贡献者会迅速增多。
wangb() 10:15:43 
其实写过sigcomm论文,但被拒,说应该投USENIX ATC
wangb() 10:16:18 
I don't think that the research contribution of the paper is a good match for Sigcomm. Perhaps it would be a better match for 
a more practice-oriented conference like USENIX ATC. 
siu1ooooooo(16236914) 10:16:50 
后来呢
wangb() 10:17:05 
确实,tcpcopy是基于实践的,从实践中摸索爬行的。后来我就先不写论文了
siu1ooooooo(16236914) 10:17:22 
嗯。这是个工程实践性很强的探索啊
wangb() 10:17:27 
要写论文,必须要有条件
siu1ooooooo(16236914) 10:17:45 
喔。
wangb() 10:18:06 
从交换机或者其它设备。镜像过来,这样测试系统和在线系统就没有关联,这样的论文是能够中USENIX ATC

wangb() 10:19:13 
tcpcopy最高端的应用,就是在交换机,利用分光镜或者其它镜像设备,利用高性能硬件,把用户的请求数据包复制给测试系统,可惜我没有这样的条件
wangb() 10:19:38 
要是有这样的条件,我肯定要写论文了
siu1ooooooo(16236914) 10:19:55 
呃。。没怎么看懂  
siu1ooooooo(16236914) 10:21:49 
是说复制的流量要非常非常大才能中论文么
siu1ooooooo(16236914) 10:21:59 
而非常大的流量需求硬件支持
wangb() 10:22:02 
twitter梦想的测试环境,其实完全可以用我们的tcpcopy来实现。交换机上面不是有来来往往的数据包吗?在那上面把请求数据包镜像到测试系统,测试系统搭一个跟在线类似的完整系统,这样测试系统跟在线系统承受类似的压力
wangb() 10:22:17 
高端大气,才能中论文
wangb() 10:22:48 
屌丝环境,写论文,还不被批啊
siu1ooooooo(16236914) 10:23:14 
呃。是 。。。明白了。。想起以前学校的事情,懂了。
wangb() 10:24:38 
总之,tcpcopy值得你去研究,期望有更多接班人把思想传承下去,代码可以推掉重来
wangb() 10:25:10 
只要tcp协议还存在,这个思想,应该是最先进的,无法再先进了
siu1ooooooo(16236914) 10:26:11 
需要好多的开发时间啊。..嗯。先上班了啊。多谢wangbin....
wangb() 10:27:16 
慢慢来,这方面反正国外没有人做

copyright blog.ykyi.net

Be the first to comment - What do you think?  Posted by zausiu - November 20, 2013 at 10:48

Categories: Network, Tech Articles   Tags:

Next Page »