查看: 789|回复: 25
全民找Bug!!!运行几十次后就会出现的Bug，谁遇到过？
阅读权限50
结帖率： (3/9)
这个自己之前写的一个小程序，之前没有进行压力测试，最近发现它有个Bug，自己测试了n多次都没能找到原因，希望找Bug高手们来帮忙看下，谢谢！
Bug发现过程：
1、运行程序后先保存足够量（建议10次以上）数据
1.jpg (49.25 KB, 下载次数: 0)
17:13 上传
2、点击开始，进行测试：
2.jpg (71.34 KB, 下载次数: 0)
17:14 上传
3、刚开始是正常的：
33.png (69.37 KB, 下载次数: 0)
17:14 上传
4、运行一段时间后，问题就来了：
6.png (65.85 KB, 下载次数: 0)
17:17 上传
执行到第32次的时候，第4条数据明明是存在的，但写到超级列表框的时候却丢失了一些数据！
个人感觉是超级列表框的Bug不知道各位有没有遇到过这样的问题？？？
麻烦各位高手们帮忙找下Bug，谢谢！！！
补充内容 ( 17:21):
源码在沙发上
(97.99 KB, 下载次数: 0)
17:14 上传
可以解决！联系QQ：
回答提醒：如果本帖被关闭无法回复，您有更好的答案帮助楼主解决，请发表至
可获得加分喔。友情提醒：本版被采纳的主题可在
帖子申请荣誉值，获得 1点 荣誉值,荣誉值可兑换终身vip用户组哦。快捷通道： →
阅读权限70
结帖率： (3/5)
可以解决！联系QQ：
您可以选择打赏方式支持他
阅读权限50
结帖率： (3/9)
刚刚忘记贴源码了，现在补上
17:20 上传
点击文件名下载附件
666.47 KB, 下载次数: 17
您可以选择打赏方式支持他
阅读权限50
结帖率： (3/9)
有没有人啊？？？
您可以选择打赏方式支持他
阅读权限50
结帖率： (3/9)
大神在哪里？？？
您可以选择打赏方式支持他
阅读权限50
结帖率： (3/9)
@冰点 @冰点
您可以选择打赏方式支持他
阅读权限70
结帖率： (8/13)
反复看了楼主的帖子三次，然后并没有看懂楼主到底在问什么。。。。于是帮顶，等其他人看看吧~
您可以选择打赏方式支持他
阅读权限50
结帖率： (3/9)
反复看了楼主的帖子三次，然后并没有看懂楼主到底在问什么。。。。于是帮顶，等其他人看看吧~
就是说，当对超级列表框进行多次操作后，就会出现有些数据无法插入的现象，你看看我那第4步那里，我在控制台调试输出第32次的测试数据时，明显第4条数据是存在的（证明数据没有丢失，是存在的），但通过超级列表框.置标题命令对超级列表框进行插入数据时（如第4步右边的图所示），账号、密码、保存时间、备注等都是空白的，我就是想问这是不是个Bug，明白了吗？
您可以选择打赏方式支持他
阅读权限30
我也来看看，顺便学习下！
您可以选择打赏方式支持他
阅读权限90
结帖率： (5/5)
OMG 写的好乱 - - 懒得找了
您可以选择打赏方式支持他
精易论坛 - 有你更精彩 /1
支持作者开源，请积极给优秀源码评分
拒绝任何人以任何形式在本论坛发表与中华人民共和国法律相抵触的言论，本站内容均为会员发表，并不代表精易立场!
揭阳精易科技有限公司申明:我公司所有的培训课程版权归精易所有，任何人以任何方式翻录、盗版、破解本站培训课程，我们必将通过法律途径解决！
公司简介：揭阳市揭东区精易科技有限公司致力于易语言教学培训/易语言学习交流社区的建设与软件开发，多年来为中小企业编写过许许多多各式软件，并把多年积累的开发经验逐步录制成视频课程供学员学习，让学员全面系统化学习易语言编程，少走弯路，减少对相关技术的研究与摸索时间，从而加快了学习进度！
防范网络诈骗，远离网络犯罪
违法和不良信息举报电话，QQ： ，，邮箱：@
Powered by
粤公网安备 25关注51Testing
使用loadrunner进行压力测试遇到的问题总结
发表于： 11:19 &作者：baiyang & 来源：51Testing软件测试网采编
推荐标签：
　　一、无法生成虚拟用户，运行报错：CCI compilation error -vuser_init.c　　问题出现情景是：loadrunner当天可以正常运行，保存好后，脚本和参数化也保持一致，第二天再次打开不能使用。在controller中，脚本运行，提示错误：LR8.1 Error: CCI compilation error -vuser_init.c&　　直接在loadrunner generator打开之前保存的脚本，点击运行无法执行，在回放日志栏提示：vuser_init.c：No such file or directory&　　分析其原因是，缺少文件　　解决办法：拷贝一个init.c文件放在脚本目录下或者重建一个文件；　　二、Error: Failed to send data by channels - post message failed　　寻找解决办法，多数测试人员给出解答如下：出现这个问题，目前判断是因为lr和测试机环境或者测试服务的兼容性出现了问题，而且一般的这个问题只是在测试大数据访问的时候才会出现。&　　解决办法：在LR的controller负载生成器的菜单栏中的Diagnotics-&configure-&Web Page Diagnotics[max vuser sampling 10%]默认的Enable关掉，重新运行以后这个问题就很少出现了。　　原网loadrunner help center，链接如下：.hk/translate?hl=zh-CN&sl=en&u=http://lrhelp./en/latest/help/WebHelp/Content/Controller/ui_diagnostics_distribution.htm&prev=search　　原因详见下图　　三、服务器监测—top命令　　过程中，利用top命令，对服务器的实时性能进行监测。&　　详解：（Top命令及参数详解，不再赘述）&　　Cpu: 309.0% 用户空间占用CPU百分比&　　对于多核cup，此值是个比例值，相对每个cup内核。当前服务器为24核实机。　　四、服务器性能检测-io峰值，尖峰的原因　　有波动，和开发讨论，有可能是虚拟机垃圾回收了~&　　清理内存时，好像卡了一下，在服务器的监测数据中，明显有尖峰。　　五、响应时间和点击率一直上不去的原因—kv数据添加机制　　针对本次活动，服务端布的环境中，会将用户的deviceid和领奖等信息添加到kv中（相当于一个数据池），具体添加数据到kv时间或时机因需求而异。项目中有每天定时添加数据到kv中的数据信息，也有实时添加到kv的数据信息。&　　KV数据，同步和异步，服务端性能的区别；&　　（1）同步写KV数据，占用耗时，平均响应时间在3~4秒左右；&　　（2）异步写KV数据，请求的响应时间大大降低，在0.3~0.4秒左右；&　　在开始之前，建议需要先和服务端开发沟通相关数据读写细节。　　六、内存回收机制-学习　　关于Linux的内存回收机制，我也在学习中，O(∩_∩)O，感受到了Linux的美！　　七、日志满，无法写log，点击率突降　　测试中，用户不断增加，服务器性能较好，感觉不到什么压力，吞吐量也在增加，稳定一定时间后，点击率突然降低，响应时间骤升，此时测试机性能良好。到达极限后应保持，怎么会突然降低呢？查找原因，是开发将日志写在了一个较小的服务器磁盘中，压测过程中产生大量的日志，在测试一段时间后，当前磁盘已经接近饱和，达到100%，报警！　　这也让我想到，之后的接口测试除了基本的接口参数、功能等基本内容沟通，还要和服务端开发更深入的沟通了解，部署环境的策略以及日志的机制等等，避免此类事情发生，提高测试效率。
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道&>&&>&&>&正文
守望先锋压力测试介绍 压力测试申请方法
11:13:59 来源：爱玩网 作者：爱玩网 编辑：久战成狂　
　　守望先锋压力测试即将开始！暴雪宣布在11月20-23日(北京时间11月21日至24日)开始我们期盼已久的压力测试。还在等什么快去申请吧。
　　这次将邀请更多的玩家参与到这次Beta测试中，并且开放全英雄以及三张地图使用，全英雄包括在2015年暴雪嘉年华上公布的三位新英雄D.Va、源氏以及美。
　　测试周末特别小队：准备战斗吧!
　　从11月20日周五至11月23日周一(太平洋时间)我们将开启第一次测试周末。三天时间，游戏将向更多北美及欧洲范围内受邀请的玩家开放。
　　测试目标：帮助我们对服务器硬件及技术进行压力测试，进行一些对战。
　　我们第一次测试周末开始于11月20日早9点(PST)，结束于11月23日早9点(PST)。(北京时间11月21日凌晨1点至11月24日凌晨1点)
　　为了保证测试效果，我们将在11月19日周四维护前后，提前发放测试周末的资格。我们建议新的测试成员提前准备并安装好测试版本客户端，保证能即使进入测试。
　　如果你获得测试周末的资格，战网客户端中《守望先锋》下面的“安装”按钮将激活。在战网账号管理界面中也会出现守望先锋的许可证。
　　你的注册邮箱也会收到一封邀请邮件，请注意这封邮件可能较慢。
　　测试周末中，所有玩家将可使用21个英雄，在三张地图：花村、国王大街、监测站：直布罗陀进行对战。
　　由于是压力测试，我们关心技术方面的反馈，比如《守望先锋》在你系统运行情况，你的游戏体验，重要Bug的反馈，以及影响游戏的问题。其中一个目标是测试我们硬件的极限，所以如果出现画面错误或游戏崩溃，请不要介意——这是测试的一部分。
　　了解更多测试计划请查看“Beta测试公告”。
安装及游戏指引
　　开始前你需要先下载游戏，请跟随以下步骤指引。注意：如果你已经参加Beta测试，以下步骤可省略。
　　1. 下载战网客户端;
　　2. 使用有资格的账号登录战网;
　　3. 点击《守望先锋》图标;
　　4. 选择所在地区，点击“安装”按钮;
　　5. 周五早上测试周末开始时，点击“开始游戏”。
　　如果你是团队射击游戏的新手，可以在游戏内选择教程学习，或者查看我们的“技能演示视频：熟悉每个英雄的操作。
反馈与Bug汇报
　　我们为测试周末单独开辟了社区版块，用于讨论游戏感受、提交Bug，以及相互交流经验。
　　压力测试反馈——分享关于英雄、场景、系统以及其他的反馈
　　压力测试Bug报告——提交发现的游戏Bug
　　压力测试技术支持——提交游戏时出现的技术问题
　　这些版块需要测试周末资格才能发言，且测试周末一旦结束，测试成员也无法在这些版块发贴或回复。
测试周末FAQ
　　问：测试周末持续多久?
　　答：11月20日上午9点(PST)开始，11月23日上午9点(PST)截止。
　　问：如何知道我是否选入测试周末?
　　答：如果你获得测试周末的资格，战网客户端中《守望先锋》下面的“安装”按钮将激活。在中也会出现守望先锋的许可证。
　　我们也会发放邀请邮件至与战网绑定的邮箱。为防止诈骗邮件，即使你认为你收到的是一封邀请函，也最好避免点击邮件中的任何连接。你可以通过查看战网的“账户管理”来确认资格。
　　问：测试周末如何选择参与者?
　　答：决定因素有很多，包括不限于你的战网所在国家、申请时间、硬件条件，也要有一些运气。
　　问：我该如何申请测试周末资格?
　　答：没有特别通道，我们将从B测申请中抽取。
　　B测申请方式：请在战网“账户管理”的“B测资料设置”(国服无此项)中，将《守望先锋》前的复选框打钩，并点击“更新设置”。或者，你可以直接通过官网进行申请。
　　请注意，申请加入并不能够保证加入测试。
　　问：除了抽选，有其它方式加入测试么?
　　答：目前没有。此外请注意，这次测试也不会有激活码。进入测试的唯一渠道就是账号直接激活。
　　问：测试在哪些地区进行?
　　答：测试目前在美洲与欧洲开放。
　　问：测试支持哪些语言?
　　答：此次测试支持10种语言：英语、法语、德语、西班牙语、波兰语、意大利语、俄罗斯语、西班牙语(拉美)，以及葡萄牙语(巴西)。本地化并没有完全结束，所以测试中部分内容仍旧以英语显示。
　　问：如果我拿到资格，可以通过直播或创作公开内容么?
　　答：当然可以!此次测试没有保密协议。我们鼓励玩家公开截图、直播你的游戏过程、录制视频一起其它你想做的。游戏仍然在开发中，如果游戏中出现Bug、图像错误或其它问题，还请你谅解。
　　问：测试期间可以组织带奖金的比赛么?
　　答：虽然测试周末只有3天，无论有没有奖金的比赛都可以组织。但是，考虑到游戏规模，我们将不允许奖金额超过1万美元的大型活动。
　　如果登录游戏后想要研究比赛计划或者其它的问题，可以随时与我们( )联系。
　　问：测试周末结束会怎样?
　　答：11月23日测试周末结束后，游戏将暂时进行维护。维护中测试周末的资格将被移除。此外，这些玩家将回到无法在B测社区发言的状态。
　　拥有Beta测试资格的玩家不受影响，维护后可继续游戏。
　　问：我在测试周末的账号会保留到正式开放么?
　　答：不会。
　　问：测试的系统要求是什么?
　　答：配置要求如下：
　　最低要求(30帧)：
　　操作系统：Windows Vista/7/8/10 64位(最新SP)
　　处理器：Intel Corei3或AMD PhenomX3 865
　　显卡： NVIDIA GeForce GTX 460，ATI Radeon HD 4850，或Intel HD Graphics 4400
　　内存：768 MB显存, 4 GB内存
　　硬盘：7200转，5 GB空间
　　推荐配置(60帧中等设置)：
　　操作系统：Windows Vista/7/8/10 64位(最新SP)
　　处理器：Intel Core i5或AMD Phenom II X3, 2.8 GHz
　　显卡：NVIDIA GeForce GTX 660或ATI Radeon HD 7950
　　内存：2 GB显存，6 GB内存
　　硬盘：7200转，5 GB空间
　　为了最佳效果，请保证将显卡驱动升级到最新版本。
　　*根据游戏改动，配置要求可能会出现变动。
　　问：《守望先锋》的收费模式是什么?
　　答：《守望先锋》目前可以预订PC、PS4、Xbox One版本，参见网站：
　　问：游戏何时发售?
　　答：2016年春季。
更多相关资讯请关注：
用手机访问
扫一扫，手机浏览
相关新闻：
游戏制作：暴雪
游戏发行：暴雪
游戏平台：PC/XboxOne/PS4
上市时间：
油管主James Lee自制了一段《守望先锋》猎空和麦克雷的动画，受到了不少玩家的追捧，不到一天就有超过了12万次观看。
《守望先锋》官方推特确认今年夏季运动会将于8月9日回归，动感斗球不仅会回归，还增加了竞技模式的动感斗球。除了去年的里约体育场外，还有新的悉尼动感斗球馆。
当《守望先锋》用上《女神异闻录5》战斗UI，制作十分用心，毫无违和感。
动画师Chris Guyot上传了《守望先锋》角色小动画，包括D.VA、小美、托比昂、卢西奥在内多位角色，形象和技能看起来非常可爱。
以前我们常看到相关报道，说一些《守望先锋》的玩家自己打造了一些东西，包括由惟妙惟肖的D.VA机甲。不过之前的那些东西跟今天这个D.VA机甲比起来就有点小巫见大巫了。
《守望先锋》中为了方便玩家交流，设有快捷喊话功能，如果用源氏的游戏语音来打急救电话会怎么样呢？
圣地亚哥漫展正在火热进行中，暴雪带来了《守望先锋》新英雄末日铁拳的官方真人cos。
此前暴雪官方公布了《守望先锋》中D.Va的全新手办，在正在举办的SDCC 2017漫展上，有国外玩家拍到了这款手办的真身。
一位叫Effekted Cosplay的玩家创作出了堪称《守望先锋》最逼真的禅雅塔cos，因为这位禅雅塔并不是人扮的。
《守望先锋》世界杯将于7月14日拉开首战序幕，而《守望先锋》世界杯官方纪录片第一章；英雄集结在今日公开。
《守望先锋》今天推出更新，夏季运动会活动华丽回归。本次夏季奥运会活动新增了动感斗球竞技场、排行榜和竞技比赛，另外官方还推出了7款新皮肤。
圣地亚哥漫展正在火热进行中，暴雪带来了《守望先锋》新英雄末日铁拳的官方真人cos。
随着新英雄末日铁拳的公布，《守望先锋》官网公布了全新的数字漫画《伪装》，讲述了这位新角色的往事。
《守望先锋》周年活动中，暴雪带来了一系列新内容，其中就有源氏的新“原谅侠”皮肤，而这套真人版cos更吸引人眼球。
设计师在新英雄“末日铁拳”的义肢“铁拳”上玩出了新花样，红黄紫绿蓝，再配上变换的肌肤颜色，仿佛调色盘一样。
经历了教练被开除事件之后，IG《守望先锋》战队分崩离析，原有阵容仅剩一人。
今天我们就来欣赏一些风格独特的《守望先锋》插画，无论是男女英雄，浓墨重彩之下都显得十分硬朗。
在近日举办的Anime Expo 2017上，又展出了最新的天使手办，目前还没有放出宣传片和更多的预售信息。
IG《守望先锋》分部教练被开除事件再升级，目前据传王思聪已介入。
《守望先锋》D.Va手办在Anime Expo上展出，根据现场玩家拍摄的照片来看，傲娇神情太诱人。
综合热点资讯
单机游戏下载
游民星空联运游戏《守望先锋》压力测试报错常见问题解决办法
守望先锋已经迎来了全面的压力测试，所有玩家都可以免费进入游戏畅玩这款FPS大作。不过，许多玩家在进入游戏时都遇到了一些技术问题导致无法启动，因此总结了相应的处理方式。如果你还卡在游戏前，那么就不妨来看看吧。
一、更新客户端报错
目前部分玩家在更新客户端时遇到了报错问题，该情况我们的工作人员已经知晓并在积极处理当中，我们建议您确认您的战网Agent版本是否为最新版本2.5.5.4931（您可以点击战网图标-设定，在左下方查看到战网Agent版本号）。若最新版本仍然无法更新，请按下述步骤进行反馈，您提供的信息将给予我们极大的帮助：
下载并运行LogGoblin.exe程序，再启动战网客户端，等待几分钟
收集完毕后，按回车关闭程序，会在相同目录下生成一个BlizzardLogs-[YYYY-MM-DD].[HHMMSS].zip 的文件
麻烦您将文件以附件的形式，发送到 .cn邮箱，并将标题改成：【OW下载更新异常】+战网账号
二、下载进度条卡住、下载速度显示不变、卡在更新中、卡在获取编码表、提示&传输数据遇到了问题，我们会尝试修复，请等待&
一般情况下耐心等待可以解决此类问题。如果长时间等待没有成效，可以尝试关闭战网客户端和后台Agent.exe进程，并优化网络连接后重新打开战网客户端进行安装。
三、连接失败，提示&抱歉，我们无法让你登录战网&
1. 如果您是刚注册的战网账号，请耐心等待一段时间再尝试登录
2. 确保输入了正确的账号密码和安全令，可以登录战网修改一次您的密码
3. 确保网络连接状态良好，可参考优化网络连接
四、客户端未响应，提示&Overwatch Application已停止工作&
1. 确保游戏已更新至最新版本
2. 确保硬件已符合《守望先锋》系统配置要求
3. 游戏启动前请关闭后台其他应用程序和安全软件
4. 尝试创建一个新的管理员帐户运行程序
五、启动游戏时/游戏过程中弹出&渲染设备已丢失&报错
1. 请确保显卡符合要求，请参考《守望先锋》显卡支持列表
2. 尝试更新显卡驱动，请参考驱动更新方法
六、启动游戏时/游戏过程中弹出&暴雪纠错器&报错
1. 在战网上找到【选项】- 选择【扫描和修复】
2. 游戏启动前请关闭后台其他应用程序和安全软件
3. 尝试降低游戏画质、音质
4. 检查内存是否正常
5. 更新显卡驱动
6. 检查硬件温度
延伸阅读：
（责任编辑：）
关注“蚕豆网”微信公众账号
最新鲜的手游资讯，最麻辣的游戏测评，最全面的游戏攻略，还有那领不完的游戏礼包和最绿色的游戏下载，要啥有啥，应有尽有。
蚕豆网好游多
集游戏攻略、热门礼包为一体，为游戏玩家量身定做的手机游戏小伙伴！
永远的7日之都考试关卡攻略 技巧测试神器使选择推荐。下面一起来看看吧。...[]
自从吃鸡玩家和直播观众并肩作战，共同抵抗挂逼主播糯米，已经过去了三个月。尽管成功地维护了大家心中的正...[]
此前曾有消息称，55开卢本伟在直播《绝地求生》时涉嫌开外挂，诸多网友热议，并且上传视频分析，表示自己找...[]
永远的7日之都安线支线一周目攻略，安线支线怎么过，首先一周目进游戏过完剧情，到自己完全可以操控的地方...[]
最近五五开陷入吃鸡开挂漩涡，还被送上热搜，急得五五开第一时间开播力证自己的清白。他也放出了很多视频，...[]
最近关于55开玩吃鸡开挂的新闻刷爆了整个直播圈，各种新闻搞得是沸沸扬扬。原本只是一个视频的实锤，现在因...[]
永远的7日之都芙罗拉支线任务攻略，芙罗拉神器和技能介绍，那么一起来看看吧。...[]
最近，人气主播五五开被爆出吃鸡开挂“实锤”，被推上了舆论的风口浪尖。参加完腾讯TGC回来后，五五开直播...[]
2017lol年度最佳阵容回馈皮肤领取地址 皮肤为什么领不了？lol年度最佳阵容回馈活动地址在哪?有什么奖励?今...[]
永远的7日之都新手安线一周目完美攻略!大家现在摸索的如何了，都打出了什么结局哇，网上很多攻略一些细节方...[]
游戏类型：
剩余数量：
游戏类型：
剩余数量：
游戏类型：
剩余数量：作者：helloworlds链接：/p/来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
4月份的时候看到一道面试题，据说是腾讯校招面试官提的：在多线程和高并发环境下，如果有一个平均运行一百万次才出现一次的bug，你如何调试这个bug？知乎原贴地址如下： .
遗憾的是知乎很多答案在抨击这道题本身的正确性，虽然我不是这次的面试官，但我认为这是一道非常好的面试题。当然，只是道加分题，答不上，不扣分。答得不错，说明解决问题的思路和能力要超过应届生平均水平。
之所以写上面这段，是因为我觉得大部分后台服务端开发都有可能遇到这样的BUG，即使没有遇到，这样的题目也能够激发大家不断思考和总结。非常凑巧的是，我在4月份也遇到了一个类似的而且要更加严重的BUG，这是我自己挖的一个很深的坑，不填好，整个项目就无法上线。
现在已经过去了一个多月，趁着有时间，自己好好总结一下，希望里面提到的一些经验和工具能够带给大家一点帮助。
我们针对nginx事件框架和openssl协议栈进行了一些深度改造，以提升nginx的HTTPS完全握手计算性能。
由于原生nginx使用本地CPU做RSA计算，ECDHE_RSA算法的单核处理能力只有400 qps左右。前期测试时的并发性能很低，就算开了24核，性能也无法超过1万。
核心功能在去年底就完成了开发，线下测试也没有发现问题。经过优化后的性能提升几倍，为了测试最大性能，使用了很多客户端并发测试https性能。很快就遇到了一些问题：
第一个问题是nginx有极低概率（亿分之一）在不同地方 core dump。白天线下压力测试2W qps一般都要两三个小时才出一次core。每次晚上睡觉之前都会将最新的调试代码编译好并启动测试，到早上醒来第一眼就会去查看机器并祈祷不要出core，不幸的是，一般都会有几个到几十个core，并且会发现经常是在一个时间点集中core dump。线上灰度测试运行了6天，在第6天的早上才集中core dump了几十次。这样算来，这个core dump的概率至少是亿分之一了。
不过和面试题目中多线程不同的是，nginx采用的是多进程+全异步事件驱动的编程模式（目前也支持了多线程，但只是针对IO的优化，核心机制还是多进程加异步）。在webserver的实现背景下，多进程异步相比多线程的优点是性能高，没有太多线程间的切换，而且内存空间独立，省去线程间锁的竞争。当然也有缺点，就是异步模式编程非常复杂，将一些逻辑上连续的事件从空间和时间切割，不符合人的正常思考习惯，出了问题后比较难追查。另外异步事件对网络和操作系统的底层知识要求较高，稍不小心就容易挖坑。
第二个问题是高并发时nginx存在内存泄漏。在流量低的时候没有问题，加大测试流量就会出现内存泄漏。
第三个问题，因为我们对nginx和openssl的关键代码都做了一些改造，希望提升它的性能。那么如何找到性能热点和瓶颈并持续优化呢？
其中第一和第二个问题的背景都是，只有并发上万qps以上时才有可能出现，几百或者一两千QPS时，程序没有任何问题。
core dump的调试
首先说一下core的解决思路，主要是如下几点：
gdb及debug log定位，发现作用不大。
如何重现bug？
构造高并发压力测试系统。
构造稳定的异常请求。
gdb及debug log效率太低
因为有core dump ，所以这个问题初看很容易定位。gdb 找到core dump点，btrace就能知道基本的原因和上下文了。
core的直接原因非常简单和常见，全部都是NULL指针引用导致的。不过从函数上下文想不通为什么会出现NULL值，因为这些指针在原生nginx的事件和模块中都是这么使用的，不应该在这些地方变成NULL。由于暂时找不到根本原因，还是先解决CORE dump吧，修复办法也非常简单，直接判断指针是否NULL，如果是NULL就直接返回，不引用不就完事了，这个地方以后肯定不会出CORE了。
这样的防守式编程并不提倡，指针NULL引用如果不core dump，而是直接返回，那么这个错误很有可能会影响用户的访问，同时这样的BUG还不知道什么时候能暴露。所以CORE DUMP 在NULL处，其实是非常负责任和有效的做法。
在NULL处返回，确实避免了在这个地方的CORE，但是过几个小时又core 在了另外一个NULL指针引用上。于是我又继续加个判断并避免NULL指针的引用。悲剧的是，过了几个小时，又CORE在了其他地方，就这样过了几天，我一直在想为什么会出现一些指针为NULL的情况？为什么会CORE在不同地方？为什么我用浏览器和curl这样的命令工具访问却没有任何问题？
熟悉nginx代码的同学应该很清楚，nginx极少在函数入口及其他地方判断指针是否为NULL值。特别是一些关键数据结构，比如&ngx_connection_t&及SSL_CTX等，在请求接收的时候就完成了初始化，所以不可能在后续正常处理过程中出现NULL的情况。
于是我更加迷惑，显然NULL值导致出CORE只是表象，真正的问题是，这些关键指针为什么会被赋值成NULL？
这个时候异步事件编程的缺点和复杂性就暴露了，好好的一个客户端的请求，从逻辑上应该是连续的，但是被读写及时间事件拆成了多个片断。虽然GDB能准确地记录core dump时的函数调用栈，但是却无法准确记录一条请求完整的事件处理栈。根本就不知道上次是哪个事件的哪些函数将这个指针赋值为NULL的,甚至都不知道这些数据结构上次被哪个事件使用了。
举个例子：客户端发送一个正常的get请求，由于网络或者客户端行为，需要发送两次才完成。服务端第一次read没有读取完全部数据，这次读事件中调用了 A，B函数，然后事件返回。第二次数据来临时，再次触发read事件，调用了A，C函数。并且core dump在了C函数中。这个时候，btrace的stack frame已经没有B函数调用的信息了。
所以通过GDB无法准确定位 core 的真正原因log debug的新尝试
这时候强大的GDB已经派不上用场了。怎么办？打印nginx调试日志。
但是打印日志也很郁闷，只要将nginx的日志级别调整到DEBUG，CORE就无法重现。为什么？因为DEBUG的日志信息量非常大，频繁地写磁盘严重影响了NGINX的性能，打开DEBUG后性能由几十万直线下降到几百qps。
调整到其他级别比如 INFO,性能虽然好了，但是日志信息量太少，没有帮助。尽管如此，日志却是个很好的工具，于是又尝试过以下办法：
针对特定客户端IP开启debug日志，比如IP是10.1.1.1就打印DEBUG，其他IP就打印最高级别的日志，nginx本身就支持这样的配置。
关闭DEBUG日志，自己在一些关键路径添加高级别的调试日志，将调试信息通过EMERG级别打印出来。
nginx只开启一个进程和少量的connection数。抽样打印连接编号（比如尾号是1）的调试日志。
总体思路依然是在不明显降低性能的前提下打印尽量详细的调试日志，遗憾的是，上述办法还是不能帮助问题定位，当然了，在不断的日志调试中，对代码和逻辑越来越熟悉。
bug如何重现？
这时候的调试效率已经很低了，几万QPS连续压力测试，几个小时才出一次CORE，然后修改代码，添加调试日志。几天过去了，毫无进展。所以必须要在线下构造出稳定的core dump环境，这样才能加快debug效率。
虽然还没有发现根本原因，但是发现了一个很可疑的地方：
出CORE比较集中，经常是在凌晨4,5点，早上7,8点的时候 dump几十个CORE。
弱网络环境的构造
traffic control
联想到夜间有很多的网络硬件调整及故障，我猜测这些core dump可能跟网络质量相关。**特别是网络瞬时不稳定，很容易触发BUG导致大量的CORE DUMP。**
最开始我考虑过使用TC(traffic control)工具来构造弱网络环境，但是转念一想，弱网络环境导致的结果是什么？显然是网络请求的各种异常啊,所以还不如直接构造各种异常请求来复现问题。于是准备构造测试工具和环境，需要满足两个条件：
并发性能强，能够同时发送数万甚至数十万级以上qps。
请求需要一定概率的异常。特别是TCP握手及SSL握手阶段，需要异常中止。
traffic control是一个很好的构造弱网络环境的工具，我之前用过测试SPDY协议性能。能够控制网络速率、丢包率、延时等网络环境，作为iproute工具集中的一个工具，由linux系统自带。但比较麻烦的是TC的配置规则很复杂，facebook在tc的基础上封装成了一个开源工具，有兴趣的可以试试。
WRK压力测试工具
由于高并发流量时才可能出core，所以首先就需要找一个性能强大的压测工具。
是一款非常优秀的开源HTTP压力测试工具，采用多线程 + 异步事件驱动的框架，其中事件机制使用了redis的ae事件框架，协议解析使用了nginx的相关代码。
相比ab（apache bench）等传统压力测试工具的优点就是性能好，基本上单台机器发送几百万pqs,打满网卡都没有问题。
wrk的缺点就是只支持HTTP类协议，不支持其他协议类测试，比如protobuf，另外数据显示也不是很方便。
nginx的测试用法： wrk -t500 -c2000 -d30s
分布式自动测试系统的构建
由于是HTTPS请求，使用ECDHE_RSA密钥交换算法时，客户端的计算消耗也比较大，单机也就10000多qps。也就是说如果server的性能有3W qps，那么一台客户端是无法发送这么大的压力的，所以需要构建一个多机的分布式测试系统，即通过中控机同时控制多台测试机客户端启动和停止测试。
之前也提到了，调试效率太低，整个测试过程需要能够自动化运行，比如晚上睡觉前，可以控制多台机器在不同的协议，不同的端口，不同的cipher suite运行整个晚上。白天因为一直在盯着，运行几分钟就需要查看结果。
这个系统有如下功能：
1. 并发控制多台测试客户端的启停，最后汇总输出总的测试结果。
2. 支持https，http协议测试，支持webserver及revers proxy性能测试。
3. 支持配置不同的测试时间、端口、URL。
4. 根据端口选择不同的SSL协议版本，不同的cipher suite。
5. 根据URL选择webserver、revers proxy模式。
异常测试请求的构造
压力测试工具和系统都准备好了，还是不能准确复现core dump的环境。接下来还要完成异常请求的构造。构造哪些异常请求呢？
由于新增的功能代码主要是和SSL握手相关，这个过程是紧接着TCP握手发生的，所以异常也主要发生在这个阶段。于是我考虑构造了如下三种异常情形：
异常的tcp连接。即在客户端tcp connent系统调用时，10%概率直接close这个socket。
异常的ssl连接。考虑两种情况，full handshake第一阶段时，即发送 client hello时，客户端10%概率直接close连接。full handshake第二阶段时，即发送clientKeyExchange时，客户端10%概率直接直接关闭TCP连接。
异常的HTTPS请求，客户端10%的请求使用错误的公钥加密数据，这样nginx解密时肯定会失败。
core bug fix小结
构造好了上述高并发压力异常测试系统，果然，几秒钟之内必然出CORE。有了稳定的测试环境，那bug fix的效率自然就会快很多。
虽然此时通过gdb还是不方便定位根本原因，但是测试请求已经满足了触发CORE的条件，打开debug调试日志也能触发core dump。于是可以不断地修改代码，不断地GDB调试，不断地增加日志，一步步地追踪根源，一步步地接近真相。
最终通过不断地重复上述步骤找到了core
dump的根本原因。其实在写总结文档的时候，core dump的根本原因是什么已经不太重要，最重要的还是解决问题的思路和过程，这才是值得分享和总结的。很多情况下，千辛万苦排查出来的，其实是一个非常明显甚至愚蠢的错误。
比如这次core dump的主要原因是：
由于没有正确地设置non-reusable，并发量太大时，用于异步代理计算的connection结构体被nginx回收并进行了初始化，从而导致不同的事件中出现NULL指针并出CORE。
虽然解决了core dump，但是另外一个问题又浮出了水面，就是**高并发测试时，会出现内存泄漏，大概一个小时500M的样子**。
valgrind的缺点
出现内存泄漏或者内存问题，大家第一时间都会想到
valgrind是一款非常优秀的软件，不需要重新编译程序就能够直接测试。功能也非常强大，能够检测常见的内存错误包括内存初始化、越界访问、内存溢出、free错误等都能够检测出来。推荐大家使用。
valgrind 运行的基本原理是：
待测程序运行在valgrind提供的模拟CPU上，valgrind会纪录内存访问及计算值，最后进行比较和错误输出我通过valgrind测试nginx也发现了一些内存方面的错误，简单分享下valgrind测试nginx的经验：
nginx通常都是使用master fork子进程的方式运行，使用&trace-children=yes来追踪子进程的信息
测试nginx + openssl时，在使用rand函数的地方会提示很多内存错误。比如Conditional jump or move depends on uninitialised value，Uninitialised value was created by a heap allocation等。这是由于rand数据需要一些熵，未初始化是正常的。如果需要去掉valgrind提示错误，编译时需要加一个选项：-DPURIFY
如果nginx进程较多，比如超过4个时，会导致valgrind的错误日志打印混乱，尽量减小nginx工作进程,保持为1个。因为一般的内存错误其实和进程数目都是没有关系的。
上面说了valgrind的功能和使用经验，但是valgrind也有一个非常大的缺点，就是它会显著降低程序的性能，官方文档说使用memcheck工具时，降低10-50倍
也就是说，如果nginx完全握手性能是20000 qps,那么使用valgrind测试，性能就只有400 qps左右。对于一般的内存问题，降低性能没啥影响，但是我这次的内存泄漏是在大压力测试时才可能遇到的，如果性能降低这么明显，内存泄漏的错误根本检测不出来。
只能再考虑其他办法了。
AddressSanitizer的优点
address sanitizer（简称asan）是一个用来检测c/c++程序的快速内存检测工具。相比valgrind的优点就是速度快，介绍对程序性能的降低只有2倍。
对Asan原理有兴趣的同学可以参考这篇文章，它的实现原理就是在程序代码中插入一些自定义代码，如下：
*address = ...;
or: ... = *
if (IsPoisoned(address)) {
ReportError(address, kAccessSize, kIsWrite);
*address = ...;
// or: ... = *`
和valgrind明显不同的是，asan需要添加编译开关重新编译程序，好在不需要自己修改代码。而valgrind不需要编程程序就能直接运行。
address sanitizer集成在了clang编译器中，GCC 4.8版本以上才支持。我们线上程序默认都是使用gcc4.3编译，于是我测试时直接使用clang重新编译nginx：
--with-cc="clang" \
--with-cc-opt="-g -fPIC -fsanitize=address -fno-omit-frame-pointer"
其中with-cc是指定编译器，with-cc-opt指定编译选项， -fsanitize=address就是开启AddressSanitizer功能。
由于AddressSanitizer对nginx的影响较小，所以大压力测试时也能达到上万的并发，内存泄漏的问题很容易就定位了。
这里就不详细介绍内存泄漏的原因了，因为跟openssl的错误处理逻辑有关，是我自己实现的，没有普遍的参考意义。
最重要的是，知道valgrind和asan的使用场景和方法，遇到内存方面的问题能够快速修复。
性能热点分析
到此，经过改造的nginx程序没有core dump和内存泄漏方面的风险了。但这显然不是我们最关心的结果（因为代码本该如此），我们最关心的问题是：
1. 代码优化前，程序的瓶颈在哪里？能够优化到什么程度？
2. 代码优化后，优化是否彻底？会出现哪些新的性能热点和瓶颈？
这个时候我们就需要一些工具来检测程序的性能热点。
perf，oprofile，gprof，systemtap
linux世界有许多非常好用的性能分析工具，我挑选几款最常用的简单介绍下：
1. [perf]()应该是最全面最方便的一个性能检测工具。由linux内核携带并且同步更新，基本能满足日常使用。**推荐大家使用**。
2. ，我觉得是一个较过时的性能检测工具了，基本被perf取代，命令使用起来也不太方便。比如opcontrol --no-vmlinux , opcontrol --init等命令启动，然后是opcontrol --start， opcontrol --dump， opcontrol -h停止，opreport查看结果等，一大串命令和参数。有时候使用还容易忘记初始化，数据就是空的。
3. 主要是针对应用层程序的性能分析工具，缺点是需要重新编译程序，而且对程序性能有一些影响。不支持内核层面的一些统计，优点就是应用层的函数性能统计比较精细，接近我们对日常性能的理解，比如各个函数时间的运行时间，，函数的调用次数等，很人性易读。
其实是一个运行时程序或者系统信息采集框架，主要用于动态追踪，当然也能用做性能分析，功能最强大，同时使用也相对复杂。不是一个简单的工具，可以说是一门动态追踪语言。如果程序出现非常麻烦的性能问题时，推荐使用 systemtap。
这里再多介绍一下perf命令，tlinux系统上默认都有安装，比如通过perf top就能列举出当前系统或者进程的热点事件，函数的排序。
perf record能够纪录和保存系统或者进程的性能事件，用于后面的分析，比如接下去要介绍的火焰图。
火焰图 flame graph
perf有一个缺点就是不直观。就是为了解决这个问题。它能够以矢量图形化的方式显示事件热点及函数调用关系。
比如我通过如下几条命令就能绘制出原生nginx在ecdhe_rsa cipher suite下的性能热点：
perf record -F 99 -p PID -g -- sleep 10
perf script | ./stackcollapse-perf.pl & out.perf-folded
./flamegraph.pl out.perf-folded&ou.svg
直接通过火焰图就能看到各个函数占用的百分比，比如上图就能清楚地知道rsaz_1024_mul_avx2和rsaz_1024_sqr_avx2函数占用了75%的采样比例。那我们要优化的对象也就非常清楚了，能不能避免这两个函数的计算？或者使用非本地CPU方案实现它们的计算？
当然是可以的，我们的异步代理计算方案正是为了解决这个问题，
从上图可以看出，热点事件里已经没有RSA相关的计算了。至于是如何做到的，后面有时间再写专门的文章来分享。
为了解决上面提到的core dump和内存泄漏问题，花了大概三周左右时间。压力很大，精神高度紧张， 说实话有些狼狈，看似几个很简单的问题，搞了这么长时间。心里当然不是很爽，会有些着急，特别是项目的关键上线期。但即使这样，整个过程我还是非常自信并且斗志昂扬。我一直在告诉自己：
调试BUG是一次非常难得的学习机会，不要把它看成是负担。不管是线上还是线下，能够主动地，高效地追查BUG特别是有难度的BUG，对自己来说一次非常宝贵的学习机会。面对这么好的学习机会，自然要充满热情，要如饥似渴，回首一看，如果不是因为这个BUG，我也不会对一些工具有更深入地了解和使用，也就不会有这篇文档的产生。
不管什么样的BUG，随着时间的推移，肯定是能够解决的。这样想想，其实会轻松很多，特别是接手新项目，改造复杂工程时，由于对代码，对业务一开始并不是很熟悉，需要一个过渡期。但关键是，你要把这些问题放在心上。白天上班有很多事情干扰，上下班路上，晚上睡觉前，大脑反而会更加清醒，思路也会更加清晰。特别是白天上班时容易思维定势，陷入一个长时间的误区，在那里调试了半天，结果大脑一片混沌。睡觉前或者上下班路上一个人时，反而能想出一些新的思路和办法。
开放地讨论。遇到问题不要不好意思，不管多简单，多低级，只要这个问题不是你google一下就能得到的结论，大胆地，认真地和组内同事讨论。这次BUG调试，有几次关键的讨论给了我很大的启发，特别是最后reusable的问题，也是组内同事的讨论才激发了我的灵感。谢谢大家的帮助。
阅读(...) 评论()}