博文转至:http://www.jianshu.com/p/3667157d63bb,转本博文的目的就是需要的时候以防忘记 1.故障现象 客服同事反馈平台系统运行缓慢,网页卡顿严重,多次重启系统后问题依然存在,使用top命令查看服务器情况,发现CPU占用率过高. 2.CPU占用过高问题定位 2.1.定位问题进程 使用top命令查看资源占用情况,发现pid为14063的进程占用了大量的CPU资源,CPU占用率高达776.1%,内存占用率也达到了29.8% [ylp@ylp-web-01 ~]$ t

假设当前页面的js文件中有如下函数: function A(){ function B(); } function B(){ $(document).on("click","#元素id",function(){ dosomething……; }); } 函数A是一个按钮上绑定的onclick函数处理: 那么每次点击按钮触发A函数之后,都会导致B函数的执行,进而 $("#元素id") 这个元素就会绑定一次点击事件. 如果多次触发A函数之后,导致 $

问题描述:业务突然变得巨卡 分析思路: (1)分析用户请求进程:查看是否有长期运行霸占锁的情况,或者进程数量巨多.很明显我这里就是巨多,正常情况一般0~40来个的样子,在业务使用高峰期居然达到了140多个.且等待类型大多为WRITELOG与PAGEIOLATCH_SH(参考:https://www.cnblogs.com/gered/p/9359266.html),意思是写日志等待和系统同步资源被占用需要等待共享锁释放(这里个人很明显感觉是因为查询时间太久,共享锁不释放)导致写入.查询等操作被阻

当windows程序出现异常.界面卡顿.无响应情况时,在有工程和源码的情况下,程序员通常是打开IDE,在DEBUG模式下进行调试.但如果是一个RELEASE程序,且无调试环境,该如何来定位呢. 这里介绍一下通过adplus导出dump文件,通过windbg来查看的方法. windbg 在这之前,先大概了解一下windbg.简单来说windbg就是Windows下对用户态/内核态的程序进行调试.分析的工具.不仅提供了图形界面操作,还有着着强大的调试命令. adplus是一个Microsoft Pr

前因 今天检查一个vue页面问题,就是在切换Tab时候(某些win10电脑),页面会卡顿一段很长的时间,短则3秒,长则十几秒,这个体验非常糟糕,于是我着手寻找其中原因. 概况 这个vue页面的元素非常多,主要分为六个Tab内容,切换Tab也只是控制Tab内容的显隐.按道理这是非常简单的行为,不应该出现卡顿的情况. 检查 代码上,我将切换Tab做的一些业务逻辑去掉,只留下控制显隐部分,并打印执行时间. 测试过后发现,即便是这么简单的操作,页面还是会卡顿,从打印的日志上看,我发现了切换的代码很快就执

一个比较长的界面一般都是Scrollview嵌套RecyclerView来解决.不过这样的UI并不是我们开发人员想看到的,实际上嵌套之后.因为Scrollview和RecyclerView都是滑动控件.会有一点滑动上的冲突.导致滑动起来有些卡顿.这个时候.我们重写一下LayoutManager就行了 例如: LinearLayoutManager linearLayoutManager = new LinearLayoutManager(getActivity(), LinearLayoutMa

1.现象: vue单页面项目 只有在某个页面切换的时候出现页面卡顿现象 经过长时间排查 确定最终原因是 该模块外层div使用  position: relative 根本原因:待完善

1.setTimeout致使页面的卡顿或是不流畅,打乱模块的生命周期 ,还有setTimeout其实是很难调试的. 当一个页面有众多js代码的时候,setTimeout就是导致页面的卡顿. var setTimeOut=setTimeout(function(){ console.log("延迟事件执行");},200);同样的代码在web端和APP端的执行的代码的效率会有很大的差异2.不要在setTimeOut里面嵌套setInterval,同样会导致页面的卡顿. var setTi

var i=0;j=30;setinterval(function(){ document.getElementId(idname).style.top=j+'px'; i<3?i++:i=0; j=i*10;},300);然后就尴尬了...在弱鸡浏览器上卡得飞起..原因:dom操作引起的reflow 回流..方法:缓存节点先..再改var myDiv = document.getElementById("myDiv");myDiv.style.left = myDiv.offs

最近电脑边的特别慢,打开任务管理器发现是磁盘活动时间时不时的就会变成100%.起初是以为硬盘出问题了,后来网上查了一下才发现很多人都遇到过这个问题,其原因就是Windows的SuperFetch和家庭组服务. 解决方案就是关闭这两个服务.以下是具体方法: 关闭SuperFetch: 运行“Win + R” -> 输入"services.msc" -> 找到SuperFetch服务,然后双击 -> 对服务的属性进行配置: 点击“确定”.SuperFetch服务就关掉了.

描述: 在 C# 中,System.Threading.Thread 类用于线程的工作.它允许创建并访问多线程应用程序中的单个线程.进程中第一个被执行的线程称为主线程. 案例: static void Main(string[] args) { int num = 100; for (int i = 0; i < num; i++) { //无参的多线程 noParmaThread(); } } private static void StartThread() { Console.WriteL

http://developer.51cto.com/art/201504/473422.htm

最近的项目是用webview做的界面,但是在界面顶端加了android本地动画效果的横向滚动条.当webview里面的图片切换时导致滚动条动画卡顿. 1:setLayerType(View.LAYER_TYPE_SOFTWARE, null); 无论硬件加速是否打开,都会有一张Bitmap(software layer),并在上面对WebView进行软渲染. 设置LAYER_TYPE_SOFTWARE后会把当前view转为bitmap保存.这样就不能开多个webview,否则会报out of m

说到 Android 系统手机,大部分人的印象是用了一段时间就变得有点卡顿,有些程序在运行期间莫名其妙的出现崩溃,打开系统文件夹一看,发现多了很多文件,然后用手机管家 APP 不断地进行清理优化 ,才感觉运行速度稍微提高了点,就算手机在各种性能跑分软件面前分数遥遥领先,还是感觉无论有多大的内存空间都远远不够用.相信每个使用 Android 系统的用户都有过以上类似经历,确实,Android 系统在流畅性方面不如 IOS 系统,为何呢,明明在看手机硬件配置上时,Android 设备都不会输于 IO

在前一篇博客中提到内存抖动和耗时复杂的计算会导致UI卡顿. 那为什么内存抖动会导致UI卡顿呢? 其实在 性能优化一之内存与垃圾回收器 这篇文章中已经有所提及. 这里来详细说明一下: 渲染功能是应用程序最普遍的功能,开发任何应用程序都是这样,一方面,设计师要求为用户展现可用性最高的超然体验,另一方面,那些华丽的图片和动画,并不是在所有的设备上都能流畅地运行.我们来了解一下什么是渲染性能. 首先,我们要知道Android系统每隔16ms就重新绘制一次Activity,也就是说,我们的应用必须在16m

转载:http://gold.xitu.io/post/582583328ac247004f3ab124 1, 感知卡顿 用户对卡顿的感知, 主要来源于界面的刷新. 而界面的性能主要是依赖于设备的UI渲染性能. 如果我们的UI设计过于复杂, 或是实现不够好, 设备又不给力, 界面就会像卡住了一样, 给用户卡顿的感觉. 1.1 16ms原则 在剖析卡顿的原因之前, 我们先来了解下Android中著名的"16ms"原则: Android系统每隔16ms会发出VSYNC信号重绘我们的界面(A

1, 感知卡顿 用户对卡顿的感知, 主要来源于界面的刷新. 而界面的性能主要是依赖于设备的UI渲染性能. 如果我们的UI设计过于复杂, 或是实现不够好, 设备又不给力, 界面就会像卡住了一样, 给用户卡顿的感觉. 1.1 16ms原则 在剖析卡顿的原因之前, 我们先来了解下Android中著名的"16ms"原则: Android系统每隔16ms会发出VSYNC信号重绘我们的界面(Activity). 为什么是16ms, 因为Android设定的刷新率是60FPS(Frame Per S

https://mp.weixin.qq.com/s/I1fp89Ib2Na1-vjmjSpsjQ 线上服务的FGC问题排查,看这篇就够了! 原创 骆俊武 IT人的职场进阶 2020-05-10   线上服务的GC问题,是Java程序非常典型的一类问题,非常考验工程师排查问题的能力.同时,几乎是面试必考题,但是能真正答好此题的人并不多,要么原理没吃透,要么缺乏实战经验. 过去半年时间里,我们的广告系统出现了多次和GC相关的线上问题,有Full GC过于频繁的,有Young GC耗时过长的,这些问

刚发布版本,忽然发现加载界面需要3-5秒延迟,那么问题来了. 首先,发现问题: 1.看代码,基于之前版本更新都没出问题,还是比较确信不是代码中的bug,以防万一,还是仔细看了下关于界面跳转部分的代码,那么ok,问题不在这里. 2.然后用工具,看看界面延迟在哪些地方了,打开instruments,启动我的app,得到运行结果如下图. 发现是在TableViewController 在调用 dequeueReusableCellWithIdentifier: 函数的时候耗时过长,打开System L

在vim编辑文件时,若单行过长,可能会导致vim卡顿,严重影响使用体验 估计是syntax匹配效率过滥导致.. 偶尔发现了一个临时的解决办法就是关掉syntax然后再打开,即在命令模式下 :syntax off :syntax on 参考:http://www.zhihu.com/question/33623946/answer/57172100 http://www.douban.com/group/topic/28307548/

近期工作中遇到了一个奇怪的现象:thinkphp框架中一个控制器中执行success或者error跳转的时候,会卡10s甚至更久,而在其他控制器中测试却不会.于是开始着手调试,利用自定义的毫秒函数测试各处代码执行的效率,最终定位发现 \ThinkPHP\Library\Think\Controller.class.php 中 函数dispatchJump 执行到 $this->get()时会出现明显卡顿,但是在其他控制器中使用并未发现问题 .于是想到了查询tp自带的日志,发现提示了 Declar