查看: 386|回复: 5
为什么一到凌晨2，3点，玩LOL就会延迟的很严重。
签到天数: 3 天[LV.2]偶尔看看I
如题：各位大大们。你们曾经有没有试过网吧。一到晚上通宵。就会有一大批客人说游戏延迟很厉害。
我查过网络了。网速很正常。而且就算很少人的时候都会有人投诉说玩英雄联盟会延迟。
所以排除了网速问题，接着我又查了一下，会不会是他们有一些服务器的问题。
但是也试过。在不同的服务器，都会出现同时延迟的情况。
所以也排除了这个原因。。。
剩下的。。应该估计是网络掉包的问题了。。因为都会出现，因为延迟所以导致游戏掉线，然后再重新启动。
所以我想有可能是网络掉包。。但是现在问题还没找清楚。。所以希望各位大大们。有没有类似的经验。好跟小白我分享一下。
在这里谢谢各位大哥啦。。。。
签到天数: 557 天[LV.9]以坛为家II
有人看黄网站??
签到天数: 557 天[LV.9]以坛为家II
有人看黄se网站??
签到天数: 1186 天[LV.10]以坛为家III
楼主什么地区 用的什么路由器呢
签到天数: 759 天[LV.10]以坛为家III
应该是撸累了要休息了
签到天数: 121 天[LV.7]常住居民III
我也有这种情况，我也烦脑了一年，我做了3家网吧都是我 自己做的软路由同一 个版本，都是一条100M的光纤，同样的 机子每天到夜里2-3点就会卡，我怎么找就找不出问题两家网吧唯一不同就是服务器，后来我就把热门游戏盘也换成固态盘但是客人还是说卡，后来以为是电信问题也找过也没用，我琢磨了一 年啥办法都找不出来，后来我就看唯一部同就 是软路由的硬件了，之前的软路由是一代的845主板，512内存，后来我就换成第3代主板，2G内存后来问题就解决了，所以说软路由的硬件也是要考虑的不是能用就可以
网盟推荐 /2
天下网盟自2012年5月正式上线以来，一直以打造优质服务与信誉为宗旨，这几年一直得到网盟会员的大力支持。截至，网盟增值平台注册用户突破30000大关。
天下网盟一年一度的网吧行业发展暨网民上网习惯有奖调查活动将于盛大启动，本次活动的奖品异常丰富，除了有肾6、数码相机等价值数千元的礼品外，还有主板、显卡、手机充值卡等壕礼相送。
Powered by查看: 1596|回复: 5
关于解决--万兆环网-丢包-延时的问题!认真看看
签到天数: 40 天[LV.5]常住居民I
关于解决--万兆环网-丢包-延时的问题!认真看看★& & 方案产品清单：网络位置名称机型简介核心层万兆三层交换机 UK5704-52TC
国家专利产品300G高背板带宽，线速三层交换包转发率达到223.2Mpps。Broadcom服务感知流量控制(SAFC)技术，采用BCM 芯片分压设计，提供48个10/100/1000M RJ45电口，4个复用1000M SFP光口，4个万兆口（2个集成万兆口、2个BCM分压万兆口）.万兆配件万兆光纤模块UK-FXG300M-SR850万兆SFP+多模模块-(850nm,0.3km,LC) 进口模块质保三年，敢保3年的模块都不用多说。万兆高速光纤跳线125-3.0MM-3M万兆OM3,长度3米,LC-LC,多模双芯,插入损耗≤0.3dB,回波损耗≥35dB,光缆外径φ3.0建议每个接点都使用光纤模块，因为高速电缆成本虽然低，但是超过3米会有延时，损耗。寿命短。服务器万兆双端口光纤网卡 UK-A2XGS
国家专利产品处理器芯片：英特尔 82599&&具有汇聚功能插槽类型:PCI-E 8x （PCIE-E 16x自动兼容）只要服务器主板上有PCI-E 8x 或者PCI-E 16x的插槽就行。总线速率 (x8, 编码速率):单向 20 Gbps&&双向 40Gbps 网络接口类型:2个SFP+插槽，2个 LC 光纤接头&&用配套的万兆模块插上就OK。数据速率支持光纤: 1G/10G光纤模块自适应。LED灯:通了灯会亮，亮绿灯为10G，黄灯为1G。注意：盗版的windows 2003系统缺少一个补丁，有时候会显示网卡为1G。方案详解：环网呢，没有接入层，比起万兆主干，千兆接入层来说，没有带宽瓶颈。但是缺点呢，广播风暴比星网严重。广播风暴产生的概率跟网吧正在使用的机器成正比。什么是广播风暴？参考资料：/view/86490adc50ee5b.html实际上在网吧网络故障中，由于网络广播风暴引起的网络故障，占网吧故障的九层以上，还有一层是人为的。一般就是技术人太水，无盘软件设置不恰当。广播风暴的产生原因以及针对性的克制：1.网络设备的原因：网络稍微繁忙的时候肯定会产生广播风暴.因为大家都知道，现在无盘数据的传输协议是基于TCP/IP协议，而不是UDP协议。打个比喻就是 TCP/IP协议是负责任的，在发出一个数据包之后要确认收到没有。而UDO协议是发出去就不管了，就算第一个数据包没收到也接着发第二个。前者更安全，不容易丢包。后者更快速，容易丢包。那么在环网中，当连接服务器的那台交换机流量满载的时候，服务器得不到确认，下面一直发数据包，就形成了广播风暴了。一般环网中，接服务器的那台交换机经常会发生这种情况，因为它压力太大，下面有好几个交换机的流量经过它。对于此问题，这款交换机在后置面板设计了bcm 芯片的模块化分压扩展卡。大家都知道bcm芯片在三层安全应用以及带机量都高于其它芯片。而且对于广播帧有很好的抑制作用。传统环网交换机采用一个芯片带48个1000M电口和4个万兆口。由于接服务器的交换机经常会出现流量满载，cpu一直超频，芯片承受不了这么大压力，就会丢包，延时，甚至温度过高，使用寿命减少。而增加了2块BCM芯片做分压。从很大程度上减少了接服务器这台交换机的压力，从而最大限度的避免了这个问题，那么广播风暴在这个问题上自然可以规避了。2.网卡损坏如果网络机器的网卡损坏也同样会产生广播风暴。损坏的网卡不停向交换机发送大量的数据包产生了大量无用的数据包产生了广 播风暴。由于网卡物理损坏引起的广播风暴，由于损坏的网卡一般还能上网，所以故障比较难排除.针对此问题，这款交换机会实时检测数据包状态，以及帧数状态。如下图：
假如某个端口帧数量和错误包同时增多的话。那么基本上可以确定这个端口上的网线---网卡段出问题了。很容易的让技术员找到问题所在。那么解决问题无非就是换张网卡，换条网线而已。3、网络环路曾经在一次的网络故障排除中发现一个很可笑的错误一条双绞线两端插在同一个交换机的不同端口上导致了网络性能急骤下降 打开网页都非常困难。这种故障就是典型的网络环路。网络环路的产生一般是由于一条物理网络线路的两端同时接在了一台网络设备中。还有一种情况比较蹊跷，是由于网线里面的铜丝短路了，也会出现这种情况。这个问题是比较简单的，把交换机里面的打开。产生回路后系统自动会down掉那2个口子。并在端口配置里面亮红灯。如下图。端口概述里面也不是显示已插的线路：如下2图
4、网络病毒目前网维大师和易游一些比较流行的无盘软件中，寄生着很多如Funlove、震荡波、RPC等病毒一旦有机器中毒后会立即通过网络进行传播。网络病毒的传播就会损耗大量的网络带宽引起网络堵塞引起广播风暴。对于此问题呢，建议大家baidu一下什么叫& & “Broadcom服务感知流量控制(SAFC)技术”& & 如下图：用过优肯的都已经知道了，但是还是要大概说下。就是对128字节以上的数据包进行检测，优先回写，优先外网数据包，以及对一些不正常特征的数据包进行抑制。不过话说回来，假如病毒够牛逼，就是天王老子来了都没用。这个只是防一些根本的。不过已经足够了，牛逼的病毒金山毒霸，卡巴斯基以及360会帮我们解决的。。。
其实这个broadcom的技术在网吧来说是非常有用的，以前也有一些交换机厂家---OEM---过broadcom的交换机，就拥有这个技术，并且得到广大用户的认可。后来可能是为了脸面，就不OEM了。可惜了，不过也说明了个别刚起步的交换机厂家还是知道要脸的！
具体的功能，以及故事背景，想了解全面的就百度“Broadcom服务感知流量控制(SAFC)技术”或者咨询下如下图：
5、黑客软件的使用目前一些上网者经常利用网络执法官、网络剪刀手以及比较流行的P2P终结者等黑客软件对网吧的内部网络进行攻击由于这些软件的使用网络也可能会引起广播风暴。这个属于人为的，一些懂点技术的人上网，嫌慢。就会下这些东西来攻击别人的端口，抑制别人的上网速度，加快自己的。对于这个问题，在交换机设置里，把port和MAC进行绑定。IP跟MAC在无盘服务器上绑定。环环相扣，交换机端口隔离。管它什么arp欺骗，DDOS攻击。以及洪水攻击都是假的。6.可能大家会有个疑问，假如我有5-10台的交换机，那岂不是得一台台设置？那不是要麻烦死人，而且容易出错？对的，对于环网得用很多个交换机的问题，我们假如了软堆叠功能。如下图：把这些环网的交换机都进行软堆叠。所有的交换机就可以进行一个WEB界面统一管理。这样能避免技术员在繁杂的工作上出错。提高整个网络的安全性。以上因素做好，网吧基本没有什么故障，除非是山寨交换机，电容电阻以及滤波器是人工焊接的，造成不兼容的硬件自身问题。或者是环路的交换机太多了。再好的网络设备，环得太多也需要计算时间，接服务器那台压力特别大。就算我们把路由功能锁定了（因为网吧的环境太复杂，路由得专业的）以及其它网吧完全用不上的功能给锁定了，用来节约CPU的使用率以及加上BCM芯片的分压。假如串了10多20个交换机，效果还是会不理想的。
也许，大家对BCM分压还有些陌生，大家都知道，在环网里面，接服务器的那台交换机承受着网吧所有的流量，所以压力会很大，VSC芯片承受不了这么大压力，所以做的环网就会出现丢包，延时。据使用者的测试，正常的时候，丢包率5%-10%,满载的时候，丢包率甚至高达50%。就是说根本没有办法玩，网吧几乎瘫痪。延时大概100ms-200ms吧。而采用broadcom芯片分压，接服务器，完全不会有这种现象。妥妥的，安逸得很。
最近有很多人问我：
石总，最近我做的环网丢包，延时特别严重，系统从做了好几次，网线也检测了好几次，都一样。有没有什么办法解决？？？
我也不好怎么回答，看了上面说的，你就懂了。
因为一些新兴厂家没有技术做broadcom芯片的交换机，你说怎么解决。。。
也许大家可能不相信，也可能是ping的小数据包。假如你近期做的环网，不是
broadcom分压的，请打开运行---输入CMD---ping 服务器ip。数据包尽量大点，比如 ping 65400 字节的数据包，事实就在那里。。。
所以此方案建议在500台以下。
对于500台以上的，要想效果好，只有唯一一个方案： 此方案用44万兆口的交换机做主干。然后万兆光纤汇聚或者万兆单线到48个1000M电口2个万兆光口的接入层。没有了带宽的瓶颈，没有了严重的广播风暴。这才是真正意义上的万兆网吧。由于目前造价太高，全国只有少数几家600-2000台的大网吧采用此方案。优肯也是在中国除 华为，思科，中兴，外，第四个拥有电信级的全万兆交换机的品牌。也是网吧行业第一个拥有并且已经在 云南，山西，河南等地有了样板工程的品牌。
最近有很多用户处于水深火热中，又找不到问题原因，所以深夜2点写了这篇文章，让大家找到问题所在，然后去解决。如果大家做过环网，或者想做环网，觉得有用就转转，让更多没有解决问题的人们找到解决问题的办法。
优肯西北代理 矩网科技 刘涛&&&&电话&&
签到天数: 40 天[LV.5]常住居民I
为什么发不上去去图片？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
签到天数: 1237 天[LV.10]以坛为家III
LZ你到底在干什么？
签到天数: 1237 天[LV.10]以坛为家III
你发的是石总的那篇日志？
签到天数: 744 天[LV.9]以坛为家II
根本就看不到。
签到天数: 131 天[LV.7]常住居民III
分析的不错 加油努力
网盟推荐 /2
天下网盟自2012年5月正式上线以来，一直以打造优质服务与信誉为宗旨，这几年一直得到网盟会员的大力支持。截至，网盟增值平台注册用户突破30000大关。
天下网盟一年一度的网吧行业发展暨网民上网习惯有奖调查活动将于盛大启动，本次活动的奖品异常丰富，除了有肾6、数码相机等价值数千元的礼品外，还有主板、显卡、手机充值卡等壕礼相送。
Powered by下次自动登录
现在的位置:
淘宝hdfs从1.0升级到2.0遇到的问题
第一阶段升级过程中遇到的主要问题:
1)hdfs升级为2.0后,需要同时升级下hive版本(hive-0.9.0-cdh4.1),之前使用老版本hive jar编译的任务需要使用新版本jar包重新编译
2)mr1任务要运行在hdfs 2.0上部分任务会运行失败，主要是2.0中将原来的class换成了interface,需要重新编译即可，少量代码需要添加下throws IOException，依赖的hadoop-core jar包也被拆分成了几个(common,hdfs,mr1等)
3)hdfs shell命令差异，主要是针对mkdir或者touchz等中间如果有不存在的路径不会自动创建
4)从云梯distcp数据由于hdfs版本不兼容，必须使用hftp的方式,且因hftp不支持密码访问，后来patch解决
5)升级hdfs 2.0后集群整体读I/O升高明显，从而导致特别是I/O需求高的build任务延时
原因是2.0对dfs.client.read.shortcircuit的调整，在检查是否有权限(dfs.block.local-path-access.user中配置的用户名)进行shortcircuit读取时如果没有权限会将本地的datanode作为deadnode处理，然后数据通过远程读取
又因为hbase中dfs.client.read.shortcircuit.buffer.size设置的值不合适导致多读了很多无谓的数据，导致整个集群I/O升高
设置dfs.client.read.shortcircuit.buffer.size=16K与hbase的block的大小相匹配
详细的分析过程见:
第二阶段升级遇到的主要问题:
1)升级到yarn后，Capacity Schedule进行了更新，job提交只需要指定叶子queue名字即可，指定全路径会报错
2)没有了map/reduce slots的概念，集群只需配置可用的内存大小，主要的参数:
yarn.nodemanager.resource.memory-mb：
一个nodemanager上可分配给container使用的物理内存大小
yarn.scheduler.minimum-allocation-mb：
resource manage分配内存的最小粒度，暂设成1024，job提交需要内存必须为此参数的整数倍
yarn.scheduler.capacity.&queue&.maximum-am-resource-percent：
am所占资源比例，可按queue设，暂设成0.3
yarn.scheduler.capacity.&queue&.user-limit-factor：
单个用户提交job限制，可按queue设，单用户如要抢占最大资源，需要设大
mapreduce.map.memory.mb,mapreduce.reduce.memory.mb：
map，reduce的内存数，默认是，如需设大，必须是1024的整数倍,可以简单理解为之前的slots数配置
mapreduce.map.java.opts,mapreduce.reduce.java.opts：
java child进程的jvm heap大小，比上面的值小些
mapreduce.job.pletedmaps：
对于map数较多需要跑多轮，可以设大此值，延迟reduce启动避免占用资源
3)yarn中不在兼容commons-cli-2.0-SNAPSHOT.jar，之前通过将该jar文件copy到hadoop classpath中使用的应用需要部署到各自应用的相关目录下，并在提交任务的时候引用
4)一些使用0.19等老版本的hadoop-streaming.jar需要更换为新版本
5)container内存超配被kill掉,考虑到job内存的自然增长及一些使用共享内存的任务，所以设置yarn.nodemanager.vmem-pmem-ratio=false关闭物理内存检查
6)客户端向AM获取job status报错:IOException
原因是AM内存设置太小，频繁GC导致,通过调大yarn.app.mapreduce.am.resource.mb解决
7)c2c_merge任务在yarn上运行缓慢
经过排查分析是因使用的mmap文件在pagecache中频繁换进换出导致,根本原因还是18与32内核的差异，因为集群升级过程中也对内核进行了升级，通过修改应用代码
去除madvise设置的MADV_SEQUENTIA后问题解决，参考:
8)IPV4和IPV6差异引起的长短机器名问题及job data local比例低的问题
在yarn resource manager下显示部分机器是长机器名，部分机器是短机器名
hbase集群下显示全是长机器名,原因是yarn与hbase获取机器名调用的方法不一样，得到的结果也不一样，导致resourcemanager在分配container时进行优先的host匹配是匹配不上，最后变成任意匹配导致
获取机器名差异的根本原因经过分析是java处理ipv6有bug和yarn脚本bug共同导致
解决方案1是修改yarn脚本，并提交issue到社区:
解决方案2就是给集群配置上机架感知，且让一个机器一个rack的虚拟机架配置，通过rack匹配绕开任意匹配，在 中有详细分析
9)由于我们当时在方案1还未得出结论前临时采用方案2快速解决线上data local低的问题后发现有部分任务提交失败报错: Max block location exceeded for split
原因是:配置了一个节点一个机架后CombineFileInputFormat获取split的block localtion时会根据block分布在哪些rack上获取locations信息，由于机架数等同于机器数，获取到的localtions数会超过集群的默认配置:
mapreduce.job.max.split.locations = 10，而yarn上修改了代码会在超出这个配置值时抛出异常，所以任务提交失败
解决方案1:增大mapreduce.job.max.split.locations和集群节点数一致
解决方案2:patch修改JobSplitWriter中超过配置值抛异常为打印警告日志，与升级前一致
10)gcih不能正常工作
不能正常工作的原因有两个:
l 集群升级到yarn后，nm管理job临时目录和distribute file的方式与tt不同，导致GCIH会生成多个mmap文件gcih.dat
l 在修复上述问题的过程中，发现散列到不同磁盘上task，jvm classpath加载顺序不一致，导致GCIH不能正常工作
解决方案，升级GCIH
将gcih.dat生成到gcih.jar软连对应的源目录下，这样一个job只会有一个
调整gcih.jar的加载顺序，放到preload里
11)集群资源使用100%,job一直hang住
当集群root跑满100%而下面的子queue未满时（因为希望集群的资源共享竞争，queue的最大可用资源会进行适当的超配)
不会触发抢占reduce资源的过程
l 不同queue的大任务尽量避开运行
l 后续patch修改在root满时触发抢占
详细分析过程见:
12)load任务写hbase偶尔会卡住
原因是当集群中有节点挂掉或者网络等出现异常可能会导致hbaseclient在select时无线等待，而锁无法释放
解决方案：
在hbase client的代码里设置超时时间
具体原因分析见:
13)集群有节点出现问题，上面的任务一直失败，后续别的任务起来后还会将container分配到这个节点
原因是yarn和之前mr1黑名单机制发生了改变
mr1是全局的黑名单，一旦被加入黑名单后续任务不会再分配
yarn的黑名单是在AM上的，也就是任务级别的，被AM加入黑名单后可以保证当前任务不会被分配上去，但是其他任务的AM中是没有这个信息的，所以还是会分配任务上去
解决方案:等待NM将节点健康信息汇报给RM,RM将节点从集群摘除
如果一直无法汇报，可以通过yarn支持的外围用户脚本来做健康检查和汇报(需要在yarn配置中配置该脚本)
详细分析见:
1)out join被拆成多个job
问题发现：loader在做多表join的过程时原来的一个job被hive拆成了8个job，耗时由原来的3分钟变成30分钟
通过patch解决,参考:
2)设置mapreduce.map.tasks不生效
分析是Hive的InputFormat的问题
如InputFormat设置为org.apache.hadoop.hive.bineHiveInputFormat，需要设置mapreduce.input.fileinputformat.split.maxsize来控制map的个数
如InputFormat设置为org.apache.hadoop.hive.ql.io.HiveInputFormat，则此参数生效
解决，将hive配置中默认的InputFormat配置成org.apache.hadoop.hive.ql.io.HiveInputFormat
3)写redis的hive job拆成了两个job
hive默认设置中，当map输出文件太小，会新起一个job合并小文件
解决方案:set hive.merge.mapfiles=
仍然存在待解决的问题:
1)有部分job会导致单disk io到100%,拖慢这个任务
2)机器出现异常问题，task全部都在localizing，job一直pending,只能kill掉重新提交
3)job或者task被kill掉后，日志也被删除，history中看不到该job的信息，排查问题困难
集群HADOOP 2.0的升级，在更好的支持现有业务:主搜，商城，店铺内，PORA个性化，尼米兹平台，中文站(offer,company,minisearch),国际站(ae,sc,p4p,aep4p,scp4p)的基础上为后续离线dump平台：ADUMP的建设夯实了基础。
一个统一存储，模块插件化设计，减少各业务线之间数据冗余，避免重复开发，同时支持快速响应各条业务线新需求的全新平台ADUMP将在3月底左右上线，紧跟集群升级的节奏，离线DUMP也将马上进入2.0时代，敬请期待!
【上篇】【下篇】
您可能还会对这些文章感兴趣！
您必须才能发表留言！
同分类最新文章
日志：196篇
分类：19个
运行：288天
最后更新：日}