服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 港铁报告分析
Intereting Posts
如何判断一个工具在哪个Ubuntu软件包中 某些apache线程的CPU负载是> 10％，其他线程是0.2％ 生产环境中的Linux软件RAID-1 Apache 2.4转换.htaccess重写为vhost.conf 如何查看在Apache / Ubuntu的tcp连接错误 ASP经典+ IIS7的问题 然后Nginx前面apache IIS网站标识和ServerBindings有什么区别？ 是否有可能使用代码启动一个EC2实例？ 运行oracle DBD :: Oacle安装得到这个“无法find或打开文件：/lib32/crt0_64.o” 我如何授予一个帐户的权限以在Active Directory中创build/修改/删除OU？ 惠普智能arraysE200i控制器 我可以告诉MySQL存储特定的数据库在特定的文件夹？ 相同的JavaScript文件，但不同的文件大小取决于服务器？ 核心OS群集的负载平衡如何工作？

港铁报告分析

我们有两个不同的路由到服务器。

  • 一个有20000毫秒延迟的延迟。 另一个没有它。
  • 延迟恰好在相同的路由和同一节点中发生。
  • 当用户通过这条路线到达服务器时，用户抱怨networking性能。

我的问题是，这种延迟实际上是造成这个问题还是我们不得不考虑其他因素。

注：我们有一个很好的带宽监控系统，我们知道是否有任何工作站的带宽滥用。

第1天路线 

Start: Sun Oct 8 13:52:18 2017 HOST: gw131 Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 3.3% 30 0.2 0.3 0.2 0.9 0.0 2.|-- 172.16.65.97 0.0% 30 0.5 0.5 0.4 1.2 0.0 3.|-- 202.53.163.113 0.0% 30 0.4 0.5 0.4 1.0 0.0 4.|-- 103.12.172.217 0.0% 30 1.1 0.8 0.5 5.9 1.0 5.|-- 103.12.172.237 0.0% 30 0.8 0.8 0.5 4.6 0.7 6.|-- ix-ge-2-0-1-0.tcore3.MLV- 3.3% 30 87.4 87.6 87.3 90.6 0.6 7.|-- if-ae-4-2.tcore1.MLV-Mumb 0.0% 30 185.0 185.7 184.9 190.6 1.2 8.|-- if-ae-9-5.tcore1.WYN-Mars 0.0% 30 204.3 203.9 203.6 205.8 0.5 9.|-- if-ae-8-1600.tcore1.PYE-P 0.0% 30 184.7 185.8 184.5 204.9 3.8 10.|-- if-ae-11-2.tcore1.PVU-Par 0.0% 30 203.2 203.1 202.8 206.4 0.6 11.|-- 80.231.153.66 0.0% 30 185.2 185.9 185.2 196.7 2.1 12.|-- ae-2-3601.ear2.Washington 70.0% 30 24311 23996 23078 24311 412.9 13.|-- SUNGARD-NET.ear2.Washingt 0.0% 30 263.0 262.4 260.8 293.2 5.8 14.|-- phl3cr1-te-0-0-1-2.sgns.n 0.0% 30 282.5 282.5 282.1 285.6 0.6 15.|-- smy1cr1-te-0-0-0-2.sgns.n 3.3% 30 277.8 278.3 277.6 286.4 1.5 16.|-- dal2cr1-te-0-1-0-2.sgns.n 6.7% 30 281.5 281.8 281.5 284.7 0.5 17.|-- 66.179.229.126 0.0% 30 284.7 284.7 284.2 291.5 1.3 18.|-- ??? 100.0 30 0.0 0.0 0.0 0.0 0.0

第2天路线： 

 Start: Mon Oct 9 21:32:07 2017 HOST: gw131 Loss% Javg Last Avg Best Wrst StDev 1.|-- gateway 0.0% 0.7 0.2 0.6 0.1 4.9 1.0 2.|-- 172.16.65.97 0.0% 1.3 0.5 1.1 0.3 9.4 1.8 3.|-- 202.53.163.113 0.0% 3.1 0.8 2.1 0.4 37.1 6.7 4.|-- 103.12.172.217 0.0% 1.7 0.5 1.5 0.5 6.1 1.7 5.|-- 103.12.172.249 0.0% 1.7 0.6 1.7 0.5 8.1 1.9 6.|-- 103-16-155-89-noc.bsccl.c 0.0% 1.4 1.1 1.8 1.0 9.1 1.8 7.|-- 103-16-152-30-noc.bsccl.c 0.0% 1.7 1.2 2.2 1.0 10.3 2.1 8.|-- 103-16-152-34-noc.bsccl.c 0.0% 1.5 5.9 6.5 5.5 14.5 1.8 9.|-- 116.51.31.233 0.0% 0.9 58.0 58.8 58.0 60.9 0.5 10.|-- ae-17.a00.sngpsi05.sg.bb. 0.0% 2.3 58.1 59.6 57.7 66.8 2.3 11.|-- ae-0.level3.sngpsi05.sg.b 16.7% 3391 7458. 3324. 73.2 7738. 3008.0 12.|-- ae-2-3601.ear2.Washington 63.3% 271. 23772 23481 22938 24086 373.8 13.|-- SUNGARD-NET.ear2.Washingt 0.0% 16.4 309.7 304.5 288.8 353.5 16.1 14.|-- phl3cr1-te-0-0-1-2.sgns.n 0.0% 9.2 310.4 324.5 310.4 340.9 10.7 15.|-- smy1cr1-te-0-0-0-2.sgns.n 0.0% 11.1 328.1 317.0 305.9 335.9 9.6 16.|-- dal2cr1-te-0-1-0-2.sgns.n 0.0% 9.4 310.3 321.1 310.2 334.2 9.2 17.|-- 66.179.229.126 0.0% 10.0 312.3 323.6 312.3 342.3 10.1 18.|-- 95-216.205.157.appsitehos 0.0% 15.2 335.8 342.6 325.9 391.6 17.3

第3天路线： 

 gw131 (0.0.0.0) Tue Oct 10 14:36:21 2017 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Javg Last Avg Best Wrst StDev 1. 202.53.167.129 0.0% 0.4 0.2 0.4 0.1 6.8 0.7 2. 172.16.65.97 0.0% 0.5 0.5 0.7 0.4 5.4 0.7 3. 202.53.163.113 0.0% 2.0 2.1 1.9 0.4 22.6 4.2 4. 103.12.172.217 0.0% 0.7 0.6 0.9 0.5 9.1 1.2 5. 103.12.172.249 0.0% 0.6 0.7 1.0 0.5 7.7 0.8 6. 103-16-155-89-noc.bsccl.com 0.0% 1.0 1.3 1.7 1.0 9.3 1.3 7. 103-16-152-30-noc.bsccl.com 0.0% 23.1 1.5 12.9 1.1 1002. 105.5 8. 103-16-152-34-noc.bsccl.com 0.0% 0.7 5.8 6.1 5.5 13.6 1.1 9. 116.51.31.233 0.0% 23.3 58.4 70.0 57.9 1063. 105.9 10. ae-17.a00.sngpsi05.sg.bb.gin.ntt.net 0.0% 2.4 58.0 59.4 57.6 77.7 3.2 11. ae-0.level3.sngpsi05.sg.bb.gin.ntt.net 15.6% 4179 7084. 3128. 69.5 7247. 2939. 12. ae-2-3601.ear2.Washington1.Level3.net 26.7% 748. 23577 23876 17859 27371 1073. 103-16-155-89-noc.bsccl.com 13. SUNGARD-NET.ear2.Washington1.Level3.net 0.0% 8.1 312.6 305.7 288.8 335.4 10.6 14. phl3cr1-te-0-0-1-2.sgns.net 0.0% 8.8 311.1 327.1 309.8 344.1 9.1 15. smy1cr1-te-0-0-0-2.sgns.net 0.0% 8.0 327.6 322.1 305.3 344.3 9.7 16. dal2cr1-te-0-1-0-2.sgns.net 0.0% 8.2 332.2 328.0 309.4 356.0 9.5 17. 66.179.229.126 0.0% 10.7 334.8 329.5 311.9 359.7 10.2 18. 95-216.205.157.appsitehosting.com 0.0% 38.0 331.8 352.5 311.3 1329. 106.2

如果有的话，任何networking上的20 秒延迟都将成为任何交互式工作的性能灾难 。 但是你没有。

您在从远程主机的旅程中获取一个路由器的traceroute响应时遇到高延迟（和丢包）。 这种情况并不罕见，尤其是在使用基于ICMP的跟踪路由时，因为大多数networking设备的优先级实际上是通过发送ICMP ttl超出关于随机死亡的PING来优化路由stream量 。 正如您从该主机（13-17）的远端跳跃中看到的那样， 通过主机的stream量没有这样的延迟。 您最大的单跳到跳时延是在跳数6和7之间，这似乎是您的ISP内部的点对点链路，可能是饱和的。 您可能会考虑监控并向您的ISP抱怨，如果这种情况持续了一段时间（没有ISP会回应您提出跟踪路由，看到链路问题的投诉，而没有正确的回应）。

至于什么是“ networkingperformance ”造成的问题，就是这样一个没有量化的问题，不可能推测。 如果你能从用户那里得到一个更清晰的问题陈述，那么可以devise实验来阐明它。

另外，请不要发布文字输出的图像; 链接腐烂，证据丢失到你的问题，他们是不可测量的，因为文本是不可能的。 我已经把图像放到了你的问题中（你没有做代表的东西，我怀疑这不是你的错） – 但最好的做法是把文本剪切并粘贴到你的问题中。