精华内容
下载资源
问答
  • SQL优化经典案例合集

    千次阅读 2018-09-01 08:11:35
    案例即笔记,难免有疏漏。如对案例有任何问题 请直接留言或者联系本人(微信/手机号:15652625652) 我很乐意和大家相互学习,共同进步!! 34.关注业务-把优化做到极致了解业务,优化新高度 33.一波三折:...

    案例即笔记,难免有疏漏。如对案例有任何问题 请直接留言或者联系本人(微信/手机号:15652625652)

    我很乐意和大家相互学习,共同进步!!

     

    34.关注业务-把优化做到极致 了解业务,优化新高度

    33.一波三折:UPDATE语句改写优化  UPDATE/MERGE/分批提交 哪个高效用哪个!!!

    32.一次'诡异'的执行SQL报错ORA-03113的问题处理 这个ORA报错很肤浅,主要还是解决问题的思路,分析过程

    31.分页语句优化案例 对于分页语句,优化是有特殊技巧的,总之执行计划中看不到SORT ORDER BY为止!

    30.从业务上消除SORT MERGE JOIN 理解SMJ和HASH的本质区别

    29.又是标量子查询引起的性能问题 标量子查询,强调很多次了?

    28.树形查询的优化案例 树形查询应该注意什么,那几个特殊的访问路径是什么意思?

    27.大量慢SQL导致节点宕机的故障分析 说了多少遍删除分区要维护全局索引,我们都知道,实操却总忽略!

    26.半连接、反连接的优化案例 哪种FILTER会出现性能问题?优化手段有哪些!SMJ和HASH效率哪个好?

    25.parallel优化案例 并行广播、并行HASH 估计很少人关注吧?搞不懂就别乱开并行!

    24.bitmap index的优化案例 彻底搞懂位图索引及其使用场景。

    23.一次从业务出发的优化 站的起点不一样,案例很简单,借鉴思想吧。

    22.谓词推入的优化案例 谓词推入是一把双刃剑,但常量推入是把屠龙刀。

    21.简单的视图合并 视图到底是合并好还是不合并好?试试就知道!

    20.关系型数据库通用的坑-自定义函数的优化 mysql对自定义函数也很敏感。总之学会改写吧!

    19.再一次用merge优化update merge改写,老生常谈!

    18.使用sql_profile脚本处理执行计划突变的案例 快速解决执行计划突变就是让其走前一个执行计划。

    17.一条存在多处性能问题的SQL分析 怎么定位哪个性能问题才是木桶最短的木板呢?

    16.一次执行计划突变的故障分析 执行计划突变 一般都是统计信息导致。你知道该怎么做了吧!

    15.直方图缺失的优化案例 直方图是什么?怎么查?什么是绑定变量窥探?直方图有什么作用?

    14.Exadata迁移到双节点RAC性能下降 迁移之后性能下降,我们都遇到过。怎么着手排查问题?

    13.dblink远端数据库统计信息过期 无法操作远端数据库收集统计信息怎么办?一个HINT搞定!

    12.一条hang住数据库的SQL的分析 应该是bug,分析过程可以说山重水复柳暗花明!

    11.序列设计之enq SQ - contention处理一则 序列cache值的单位是什么,应该设置多大合适?

    10.数据仓库设计的隐患-标量子查询 存在即合理,不过你得会用。我们的口号是禁止标量,统统改外连!

    9.union和or互换 什么情况下可以互换,什么情况下只能用union?我的建议是都用union!

    8.一个跑不出结果的视图的优化 视图有性能问题,引用这个视图的所有SQL性能都很差。

    7.脑残设计-视图里包含order by和union 怎样设计的视图才是"合理"的,在设计视图时避免出现哪些关键字。

    6.用MERGE改写UPDATE的优化UPDATE容易出现的坑(新手更新全表)和性能瓶颈,通过改成MERGE都能迎刃而解

    5.分页语句优化注意点(一):关注业务数据分页我们需要注意stopkey,即扫描停止。而有些情况会出现扫描不停止!

    4.特殊分页语句的改写优化 当分页框架不正确时,我们需要先把语句改造成我们熟悉并且能优化的框架。

    3.使用HASH代替NEST LOOP 还是ORACLE连接方式的问题,纯属练手

    2.选择最合适的连接方式 什么时候该用NL ?什么时候该用HASH? 这是最基本的东东!

    1.rows算错导致错误的笛卡尔积造成temp不足 一个平淡无奇的案例,她开启了我的优化之路

     

    展开全文
  • 美团jvm优化案例

    千次阅读 2018-01-17 10:59:50
    当Java程序性能达不到既定目标,且其他优化手段都已经穷尽时,通常需要调整垃圾回收器来进一步提高性能,称为...本篇会介绍这些通用的GC优化策略和相关实践案例,主要包括如下内容: 优化前准备: 简单回顾JVM相关

    当Java程序性能达不到既定目标,且其他优化手段都已经穷尽时,通常需要调整垃圾回收器来进一步提高性能,称为GC优化。但GC算法复杂,影响GC性能的参数众多,且参数调整又依赖于应用各自的特点,这些因素很大程度上增加了GC优化的难度。即便如此,GC调优也不是无章可循,仍然有一些通用的思考方法。本篇会介绍这些通用的GC优化策略和相关实践案例,主要包括如下内容:

    优化前准备: 简单回顾JVM相关知识、介绍GC优化的一些通用策略。
    优化方法: 介绍调优的一般流程:明确优化目标→优化→跟踪优化结果。
    优化案例: 简述笔者所在团队遇到的GC问题以及优化方案。

    一、优化前的准备

    GC优化需知

    为了更好地理解本篇所介绍的内容,你需要了解如下内容。

    1. GC相关基础知识,包括但不限于:
      a) GC工作原理。
      b) 理解新生代、老年代、晋升等术语含义。
      c) 可以看懂GC日志。

    2. GC优化不能解决一切性能问题,它是最后的调优手段。

    如果对第一点中提及的知识点不是很熟悉,可以先阅读小结-JVM基础回顾;如果已经很熟悉,可以跳过该节直接往下阅读。

    JVM基础回顾

    JVM内存结构

    简单介绍一下JVM内存结构和常见的垃圾回收器。

    当代主流虚拟机(Hotspot VM)的垃圾回收都采用“分代回收”的算法。“分代回收”是基于这样一个事实:对象的生命周期不同,所以针对不同生命周期的对象可以采取不同的回收方式,以便提高回收效率。

    Hotspot VM将内存划分为不同的物理区,就是“分代”思想的体现。如图所示,JVM内存主要由新生代、老年代、永久代构成。

    GC影响

    ① 新生代(Young Generation):大多数对象在新生代中被创建,其中很多对象的生命周期很短。每次新生代的垃圾回收(又称Minor GC)后只有少量对象存活,所以选用复制算法,只需要少量的复制成本就可以完成回收。

    新生代内又分三个区:一个Eden区,两个Survivor区(一般而言),大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到两个Survivor区(中的一个)。当这个Survivor区满时,此区的存活且不满足“晋升”条件的对象将被复制到另外一个Survivor区。对象每经历一次Minor GC,年龄加1,达到“晋升年龄阈值”后,被放到老年代,这个过程也称为“晋升”。显然,“晋升年龄阈值”的大小直接影响着对象在新生代中的停留时间,在Serial和ParNew GC两种回收器中,“晋升年龄阈值”通过参数MaxTenuringThreshold设定,默认值为15。

    ② 老年代(Old Generation):在新生代中经历了N次垃圾回收后仍然存活的对象,就会被放到年老代,该区域中对象存活率高。老年代的垃圾回收(又称Major GC)通常使用“标记-清理”或“标记-整理”算法。整堆包括新生代和老年代的垃圾回收称为Full GC(HotSpot VM里,除了CMS之外,其它能收集老年代的GC都会同时收集整个GC堆,包括新生代)。

    ③ 永久代(Perm Generation):主要存放元数据,例如Class、Method的元信息,与垃圾回收要回收的Java对象关系不大。相对于新生代和年老代来说,该区域的划分对垃圾回收影响比较小。

    常见垃圾回收器

    不同的垃圾回收器,适用于不同的场景。常用的垃圾回收器:

    • 串行(Serial)回收器是单线程的一个回收器,简单、易实现、效率高。
    • 并行(ParNew)回收器是Serial的多线程版,可以充分的利用CPU资源,减少回收的时间。
    • 吞吐量优先(Parallel Scavenge)回收器,侧重于吞吐量的控制。
    • 并发标记清除(CMS,Concurrent Mark Sweep)回收器是一种以获取最短回收停顿时间为目标的回收器,该回收器是基于“标记-清除”算法实现的。

    GC日志

    每一种回收器的日志格式都是由其自身的实现决定的,换而言之,每种回收器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读,将各个回收器的日志都维持一定的共性。JavaGC日志 中简单介绍了这些共性。

    参数基本策略

    各分区的大小对GC的性能影响很大。如何将各分区调整到合适的大小,分析活跃数据的大小是很好的切入点。

    活跃数据的大小是指,应用程序稳定运行时长期存活对象在堆中占用的空间大小,也就是Full GC后堆中老年代占用空间的大小。可以通过GC日志中Full GC之后老年代数据大小得出,比较准确的方法是在程序稳定后,多次获取GC数据,通过取平均值的方式计算活跃数据的大小。活跃数据和各分区之间的比例关系如下(见参考文献1):

    空间 倍数
    总大小 3-4 倍活跃数据的大小
    新生代 1-1.5 活跃数据的大小
    老年代 2-3 倍活跃数据的大小
    永久代 1.2-1.5 倍Full GC后的永久代空间占用

    例如,根据GC日志获得老年代的活跃数据大小为300M,那么各分区大小可以设为:

    总堆:1200MB = 300MB × 4
    新生代:450MB = 300MB × 1.5

    老年代: 750MB = 1200MB - 450MB*

    这部分设置仅仅是堆大小的初始值,后面的优化中,可能会调整这些值,具体情况取决于应用程序的特性和需求。

    二、优化步骤

    GC优化一般步骤可以概括为:确定目标、优化参数、验收结果。

    确定目标

    明确应用程序的系统需求是性能优化的基础,系统的需求是指应用程序运行时某方面的要求,譬如:

    • 高可用,可用性达到几个9。
    • 低延迟,请求必须多少毫秒内完成响应。
    • 高吞吐,每秒完成多少次事务。

    明确系统需求之所以重要,是因为上述性能指标间可能冲突。比如通常情况下,缩小延迟的代价是降低吞吐量或者消耗更多的内存或者两者同时发生。

    由于笔者所在团队主要关注高可用和低延迟两项指标,所以接下来分析,如何量化GC时间和频率对于响应时间和可用性的影响。通过这个量化指标,可以计算出当前GC情况对服务的影响,也能评估出GC优化后对响应时间的收益,这两点对于低延迟服务很重要。

    举例:假设单位时间T内发生一次持续25ms的GC,接口平均响应时间为50ms,且请求均匀到达,根据下图所示:

    GC影响

    那么有(50ms+25ms)/T比例的请求会受GC影响,其中GC前的50ms内到达的请求都会增加25ms,GC期间的25ms内到达的请求,会增加0-25ms不等,如果时间T内发生N次GC,受GC影响请求占比=(接口响应时间+GC时间)×N/T 。可见无论降低单次GC时间还是降低GC次数N都可以有效减少GC对响应时间的影响。

    优化

    通过收集GC信息,结合系统需求,确定优化方案,例如选用合适的GC回收器、重新设置内存比例、调整JVM参数等。

    进行调整后,将不同的优化方案分别应用到多台机器上,然后比较这些机器上GC的性能差异,有针对性的做出选择,再通过不断的试验和观察,找到最合适的参数。

    验收优化结果

    将修改应用到所有服务器,判断优化结果是否符合预期,总结相关经验。

    接下来,我们通过三个案例来实践以上的优化流程和基本原则(本文中三个案例使用的垃圾回收器均为ParNew+CMS,CMS失败时Serial Old替补)。

    三、GC优化案例

    案例一 Major GC和Minor GC频繁

    确定目标

    服务情况:Minor GC每分钟100次 ,Major GC每4分钟一次,单次Minor GC耗时25ms,单次Major GC耗时200ms,接口响应时间50ms。

    由于这个服务要求低延时高可用,结合上文中提到的GC对服务响应时间的影响,计算可知由于Minor GC的发生,12.5%的请求响应时间会增加,其中8.3%的请求响应时间会增加25ms,可见当前GC情况对响应时间影响较大。

    (50ms+25ms)× 100次/60000ms = 12.5%,50ms × 100次/60000ms = 8.3% 。

    优化目标:降低TP99、TP90时间。

    优化

    首先优化Minor GC频繁问题。通常情况下,由于新生代空间较小,Eden区很快被填满,就会导致频繁Minor GC,因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下,新生代中的Eden区增加一倍,Minor GC的次数就会减少一半。

    这时很多人有这样的疑问,扩容Eden区虽然可以减少Minor GC的次数,但会增加单次Minor GC时间么?根据上面公式,如果单次Minor GC时间也增加,很难保证最后的优化效果。我们结合下面情况来分析,单次Minor GC时间主要受哪些因素影响?是否和新生代大小存在线性关系?
    首先,单次Minor GC时间由以下两部分组成:T1(扫描新生代)和 T2(复制存活对象到Survivor区)如下图。(注:这里为了简化问题,我们认为T1只扫描新生代判断对象是否存活的时间,其实该阶段还需要扫描部分老年代,后面案例中有详细描述。)

    GC影响

    • 扩容前:新生代容量为R ,假设对象A的存活时间为750ms,Minor GC间隔500ms,那么本次Minor GC时间= T1(扫描新生代R)+T2(复制对象A到S)。

    • 扩容后:新生代容量为2R ,对象A的生命周期为750ms,那么Minor GC间隔增加为1000ms,此时Minor GC对象A已不再存活,不需要把它复制到Survivor区,那么本次GC时间 = 2 × T1(扫描新生代R),没有T2复制时间。

    可见,扩容后,Minor GC时增加了T1(扫描时间),但省去T2(复制对象)的时间,更重要的是对于虚拟机来说,复制对象的成本要远高于扫描成本,所以,单次Minor GC时间更多取决于GC后存活对象的数量,而非Eden区的大小。因此如果堆中短期对象很多,那么扩容新生代,单次Minor GC时间不会显著增加。下面需要确认下服务中对象的生命周期分布情况:

    GC影响

    通过上图GC日志中两处红色框标记内容可知:

    1. new threshold = 2(动态年龄判断,对象的晋升年龄阈值为2),对象仅经历2次Minor GC后就晋升到老年代,这样老年代会迅速被填满,直接导致了频繁的Major GC。
    2. Major GC后老年代使用空间为300M+,意味着此时绝大多数(86% = 2G/2.3G)的对象已经不再存活,也就是说生命周期长的对象占比很小。

    由此可见,服务中存在大量短期临时对象,扩容新生代空间后,Minor GC频率降低,对象在新生代得到充分回收,只有生命周期长的对象才进入老年代。这样老年代增速变慢,Major GC频率自然也会降低。

    优化结果

    通过扩容新生代为为原来的三倍,单次Minor GC时间增加小于5ms,频率下降了60%,服务响应时间TP90,TP99都下降了10ms+,服务可用性得到提升。

    调整前:GC影响

    调整后:GC影响

    小结

    如何选择各分区大小应该依赖应用程序中对象生命周期的分布情况:如果应用存在大量的短期对象,应该选择较大的年轻代;如果存在相对较多的持久对象,老年代应该适当增大。

    更多思考

    关于上文中提到晋升年龄阈值为2,很多同学有疑问,为什么设置了MaxTenuringThreshold=15,对象仍然仅经历2次Minor GC,就晋升到老年代?这里涉及到“动态年龄计算”的概念。

    动态年龄计算:Hotspot遍历所有对象时,按照年龄从小到大对其所占用的大小进行累积,当累积的某个年龄大小超过了survivor区的一半时,取这个年龄和MaxTenuringThreshold中更小的一个值,作为新的晋升年龄阈值。在本案例中,调优前:Survivor区 = 64M,desired survivor = 32M,此时Survivor区中age<=2的对象累计大小为41M,41M大于32M,所以晋升年龄阈值被设置为2,下次Minor GC时将年龄超过2的对象被晋升到老年代。

    JVM引入动态年龄计算,主要基于如下两点考虑:

    1. 如果固定按照MaxTenuringThreshold设定的阈值作为晋升条件:
      a)MaxTenuringThreshold设置的过大,原本应该晋升的对象一直停留在Survivor区,直到Survivor区溢出,一旦溢出发生,Eden+Svuvivor中对象将不再依据年龄全部提升到老年代,这样对象老化的机制就失效了。
      b)MaxTenuringThreshold设置的过小,“过早晋升”即对象不能在新生代充分被回收,大量短期对象被晋升到老年代,老年代空间迅速增长,引起频繁的Major GC。分代回收失去了意义,严重影响GC性能。

    2. 相同应用在不同时间的表现不同:特殊任务的执行或者流量成分的变化,都会导致对象的生命周期分布发生波动,那么固定的阈值设定,因为无法动态适应变化,会造成和上面相同的问题。

    总结来说,为了更好的适应不同程序的内存情况,虚拟机并不总是要求对象年龄必须达到Maxtenuringthreshhold再晋级老年代。

    案例二 请求高峰期发生GC,导致服务可用性下降

    确定目标

    GC日志显示,高峰期CMS在重标记(Remark)阶段耗时1.39s。Remark阶段是Stop-The-World(以下简称为STW)的,即在执行垃圾回收时,Java应用程序中除了垃圾回收器线程之外其他所有线程都被挂起,意味着在此期间,用户正常工作的线程全部被暂停下来,这是低延时服务不能接受的。本次优化目标是降低Remark时间。

    GC影响

    优化

    解决问题前,先回顾一下CMS的四个主要阶段,以及各个阶段的工作内容。下图展示了CMS各个阶段可以标记的对象,用不同颜色区分。

    1. Init-mark初始标记(STW) ,该阶段进行可达性分析,标记GC ROOT能直接关联到的对象,所以很快。
    2. Concurrent-mark并发标记,由前阶段标记过的绿色对象出发,所有可到达的对象都在本阶段中标记。
    3. Remark重标记(STW) ,暂停所有用户线程,重新扫描堆中的对象,进行可达性分析,标记活着的对象。因为并发标记阶段是和用户线程并发执行的过程,所以该过程中可能有用户线程修改某些活跃对象的字段,指向了一个未标记过的对象,如下图中红色对象在并发标记开始时不可达,但是并行期间引用发生变化,变为对象可达,这个阶段需要重新标记出此类对象,防止在下一阶段被清理掉,这个过程也是需要STW的。特别需要注意一点,这个阶段是以新生代中对象为根来判断对象是否存活的。
    4. 并发清理,进行并发的垃圾清理。

    GC影响

    可见,Remark阶段主要是通过扫描堆来判断对象是否存活。那么准确判断对象是否存活,需要扫描哪些对象?CMS对老年代做回收,Remark阶段仅扫描老年代是否可行?结论是不可行,原因如下:
    GC影响
    如果仅扫描老年代中对象,即以老年代中对象为根,判断对象是否存在引用,上图中,对象A因为引用存在新生代中,它在Remark阶段就不会被修正标记为可达,GC时会被错误回收。
    新生代对象持有老年代中对象的引用,这种情况称为“跨代引用”。因它的存在,Remark阶段必须扫描整个堆来判断对象是否存活,包括图中灰色的不可达对象。

    灰色对象已经不可达,但仍然需要扫描的原因:新生代GC和老年代的GC是各自分开独立进行的,只有Minor GC时才会使用根搜索算法,标记新生代对象是否可达,也就是说虽然一些对象已经不可达,但在Minor GC发生前不会被标记为不可达,CMS也无法辨认哪些对象存活,只能全堆扫描(新生代+老年代)。由此可见堆中对象的数目影响了Remark阶段耗时。
    分析GC日志可以得出同样的规律,Remark耗时>500ms时,新生代使用率都在75%以上。这样降低Remark阶段耗时问题转换成如何减少新生代对象数量。

    新生代中对象的特点是“朝生夕灭”,这样如果Remark前执行一次Minor GC,大部分对象就会被回收。CMS就采用了这样的方式,在Remark前增加了一个可中断的并发预清理(CMS-concurrent-abortable-preclean),该阶段主要工作仍然是并发标记对象是否存活,只是这个过程可被中断。此阶段在Eden区使用超过2M时启动,当然2M是默认的阈值,可以通过参数修改。如果此阶段执行时等到了Minor GC,那么上述灰色对象将被回收,Reamark阶段需要扫描的对象就少了。

    除此之外CMS为了避免这个阶段没有等到Minor GC而陷入无限等待,提供了参数CMSMaxAbortablePrecleanTime ,默认为5s,含义是如果可中断的预清理执行超过5s,不管发没发生Minor GC,都会中止此阶段,进入Remark。
    根据GC日志红色标记2处显示,可中断的并发预清理执行了5.35s,超过了设置的5s被中断,期间没有等到Minor GC ,所以Remark时新生代中仍然有很多对象。

    对于这种情况,CMS提供CMSScavengeBeforeRemark参数,用来保证Remark前强制进行一次Minor GC。

    优化结果

    经过增加CMSScavengeBeforeRemark参数,单次执行时间>200ms的GC停顿消失,从监控上观察,GCtime和业务波动保持一致,不再有明显的毛刺。
    GC影响

    小结

    通过案例分析了解到,由于跨代引用的存在,CMS在Remark阶段必须扫描整个堆,同时为了避免扫描时新生代有很多对象,增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制,如果超时等不到Minor GC,Remark时新生代仍然有很多对象,我们的调优策略是,通过参数强制Remark前进行一次Minor GC,从而降低Remark阶段的时间。

    更多思考

    案例中只涉及老年代GC,其实新生代GC存在同样的问题,即老年代可能持有新生代对象引用,所以Minor GC时也必须扫描老年代。

    JVM是如何避免Minor GC时扫描全堆的?
    经过统计信息显示,老年代持有新生代对象引用的情况不足1%,根据这一特性JVM引入了卡表(card table)来实现这一目的。如下图所示:

    GC影响

    卡表的具体策略是将老年代的空间分成大小为512B的若干张卡(card)。卡表本身是单字节数组,数组中的每个元素对应着一张卡,当发生老年代引用新生代时,虚拟机将该卡对应的卡表元素设置为适当的值。如上图所示,卡表3被标记为脏(卡表还有另外的作用,标识并发标记阶段哪些块被修改过),之后Minor GC时通过扫描卡表就可以很快的识别哪些卡中存在老年代指向新生代的引用。这样虚拟机通过空间换时间的方式,避免了全堆扫描。

    总结来说,CMS的设计聚焦在获取最短的时延,为此它“不遗余力”地做了很多工作,包括尽量让应用程序和GC线程并发、增加可中断的并发预清理阶段、引入卡表等,虽然这些操作牺牲了一定吞吐量但获得了更短的回收停顿时间。

    案例三 发生Stop-The-World的GC

    确定目标

    GC日志如下图(在GC日志中,Full GC是用来说明这次垃圾回收的停顿类型,代表STW类型的GC,并不特指老年代GC),根据GC日志可知本次Full GC耗时1.23s。这个在线服务同样要求低时延高可用。本次优化目标是降低单次STW回收停顿时间,提高可用性。

    GC影响

    优化

    首先,什么时候可能会触发STW的Full GC呢?

    1. Perm空间不足;
    2. CMS GC时出现promotion failed和concurrent mode failure(concurrent mode failure发生的原因一般是CMS正在进行,但是由于老年代空间不足,需要尽快回收老年代里面的不再被使用的对象,这时停止所有的线程,同时终止CMS,直接进行Serial Old GC);
    3. 统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间;
    4. 主动触发Full GC(执行jmap -histo:live [pid])来避免碎片问题。

    然后,我们来逐一分析一下:

    • 排除原因2:如果是原因2中两种情况,日志中会有特殊标识,目前没有。
    • 排除原因3:根据GC日志,当时老年代使用量仅为20%,也不存在大于2G的大对象产生。
    • 排除原因4:因为当时没有相关命令执行。
    • 锁定原因1:根据日志发现Full GC后,Perm区变大了,推断是由于永久代空间不足容量扩展导致的。

    找到原因后解决方法有两种:

    1. 通过把-XX:PermSize参数和-XX:MaxPermSize设置成一样,强制虚拟机在启动的时候就把永久代的容量固定下来,避免运行时自动扩容。
    2. CMS默认情况下不会回收Perm区,通过参数CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled ,可以让CMS在Perm区容量不足时对其回收。

    由于该服务没有生成大量动态类,回收Perm区收益不大,所以我们采用方案1,启动时将Perm区大小固定,避免进行动态扩容。

    优化结果

    调整参数后,服务不再有Perm区扩容导致的STW GC发生。

    小结

    对于性能要求很高的服务,建议将MaxPermSize和MinPermSize设置成一致(JDK8开始,Perm区完全消失,转而使用元空间。而元空间是直接存在内存中,不在JVM中),Xms和Xmx也设置为相同,这样可以减少内存自动扩容和收缩带来的性能损失。虚拟机启动的时候就会把参数中所设定的内存全部化为私有,即使扩容前有一部分内存不会被用户代码用到,这部分内存在虚拟机中被标识为虚拟内存,也不会交给其他进程使用。

    四、总结

    结合上述GC优化案例做个总结:

    1. 首先再次声明,在进行GC优化之前,需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用,通过GC优化令其性能达到一个质的飞跃。
    2. 其次,通过上述分析,可以看出虚拟机内部已有很多优化来保证应用的稳定运行,所以不要为了调优而调优,不当的调优可能适得其反。
    3. 最后,GC优化是一个系统而复杂的工作,没有万能的调优策略可以满足所有的性能指标。GC优化必须建立在我们深入理解各种垃圾回收器的基础上,才能有事半功倍的效果。

    本文中案例均来北京业务安全中心(也称风控)对接服务的实践经验。同时感谢风控的小伙伴们,是他们专业负责的审阅,才让这篇文章更加完善。对于本文中涉及到的内容,欢迎大家指正和补充。

    作者简介

    录录,2016年加入美团点评,主要负责北京业务安全中心对接服务的后台研发工作。

    招聘

    美团点评北京业务安全中心致力于建设公司平台级业务安全基础设施、保障业务安全运行,工作涵盖交易秩序、帐号安全、爬虫防控等风控方向,基于千万级订单、千万级日活跃用户、亿级存量用户进行数据挖掘,实时处理每日百亿级流量,热诚期待各位开发、算法、策略产品经理人才加入。联系邮箱:tangyizhe#meituan.com。

    参考文献

    1. Scott O. Java Performance:The Definitive Guide. O'Reilly, 2014.
    2. 周志明,深入理解Java虚拟机[M],机械工业出版社,2013.
    3. CMS垃圾回收机制.
    展开全文
  • SQL 优化核心思想

    千次阅读 2018-12-19 07:29:16
    SQL 优化核心思想 SQL 优化必懂的概念 概念 英文 含义 影响 示例 计算 临界 基数 Cardinality 某个列唯一键(Distinct Keys)的数量 基数的高低影响列的数据分布 性别字段基数为2 ...

    SQL 优化核心思想


    SQL 优化必懂的概念

    概念 英文 含义 影响 示例 计算 临界
    基数 Cardinality 某个列唯一键(Distinct Keys)的数量 基数的高低影响列的数据分布 性别字段基数为2 5%,当查询结果返回表中5%以内的数据时应该走索引;反之,走全表扫描;在表中有male 有 50个,总数据100,那么检索sex=male,50%不走索引
    选择性 Selectivity 基数与总行数的比值再乘以100即为某列的选择性 当一个列的选择性大于20%,说明该列的数据分布就比较均衡了
    • 计算
    -- 列的基数
    select column_name,count(*) from table group by column_name order by 2 desc
    
    -- 列的选择性
    select
    a.TABLE_NAME as "表名称", 
    a.COLUMN_NAME as "表中列名称",
    a.CARDINALITY as "列的基数",
    b.TABLE_ROWS as "表中总行数",
    ROUND(a.CARDINALITY / b.TABLE_ROWS * 100 ,2 ) as "选择性" 
    from information_schema.STATISTICS a , information_schema.`TABLES` b 
    where a.TABLE_NAME = b.TABLE_NAME 
    and a.TABLE_SCHEMA = "test"
    and a.TABLE_NAME = "test" ;
    -- 列的选择性过低,减少数据总数量,定时批量删除无效数据
    
    • 说明
      • order by 2 ,根据第二列排序,当前查询的列中的第二列,而不是表中的第二列1
      • 什么样的列必须要创建索引?STATISTICS 2
        • 当一个列出现在where条件中,该列没有创建索引并且选择性大于20%
        • 表中只有几百条数据也无需建立索引
          • 索引是创建表时添加 or 运行中 ?
            • 预估表中数据量
              • 如果是字典表,则无需建立索引;
              • 如果是业务表,预估业务增长速度,按照开发时关于该表的查询SQL字段建立索引

    1. order by 1,2这个是什么意思,该如何解决 ↩︎

    2. MySQL 字典表 ↩︎

    展开全文
  • 经典算法思想及其案例

    千次阅读 2018-04-15 15:37:18
    一个决策序列就是在变化的状态中产生出来的,所以,这种多阶段最优化决策解决问题的过程就称为动态规划。太太规划问题往往是因为资源有限,每一步的决策会导致资源的损耗,而是后面决策可利用的资源不够多。 解决...

    贪心算法:总是做出在当前看来是最好的选择。也就是说,不从整体最优上加以考虑,他所做出的仅是在某种意义上的局部最优解。贪心算法往往是无后性无记忆性,即当前做出的决策不会影响到下一步的决策

    分治法:通过分解问题为一个个小问题,知道最后子问题可以求解,原问题的解即子问题的解的合并。这些子问题互相独立且与原问题形式相同,可以递归地解这些子问题,然后将各子问题的解合并得到原问题的解。故分治法和递归往往同时应用于解决问题、

    可使用分治法求解的一些经典问题


     (1)二分搜索
    (2)合并排序
    (3)快速排序
    (4)线性时间选择

    动态规划算法:每次决策依赖于当前状态,又随即引起状态的转移。一个决策序列就是在变化的状态中产生出来的,所以,这种多阶段最优化决策解决问题的过程就称为动态规划。太太规划问题往往是因为资源有限,每一步的决策会导致资源的损耗,而是后面决策可利用的资源不够多。

    解决问题的的重点是找到子问题重叠 即资源的约束,以及到终点的必经路线

    可使用动态规划求解的一些经典问题

     (1)poj 2533 最长上升子序列
    (2)hdu 2602  01背包
    (3) hdu 2084  数塔

    (4)hdu 1003  Max Sum

    回溯法:回溯算法实际上一个类似枚举的搜索尝试过程,主要是在搜索尝试过程中寻找问题的解,当发现已不满足求解条件时,就“回溯”返回,尝试别的路径。 及深度优先搜索,以及编译原理的上下文无关法

    分支限界法:广度优先或最小消耗优先搜索队列、优先队列每个结点只有一次成为活结点的机会找出满足约束条件的一个解或特定意义下的最优解


    展开全文
  • SQL优化新书《SQL优化核心思想》终于出版了

    万次阅读 多人点赞 2018-04-09 20:27:53
    耗时三年,SQL优化大作终于出版了,有想提升SQL优化水平的...第六章介绍单表访问以及索引扫描的成本计算,引出优化思想。第七章讲解查询变换;第八章讲解优化技巧;第九章分享经典案例;第十章介绍全自动SQL审核...
  • 从实际案例聊聊Java应用的GC优化

    千次阅读 2018-03-19 11:56:48
    当Java程序性能达不到既定目标,且其他优化手段都已经穷尽时,通常需要调整垃圾回收器来进一步提高性能,...本篇会介绍这些通用的GC优化策略和相关实践案例,主要包括如下内容: 优化前准备: 简单回顾JVM相关知...
  • 10月27日,由子衿技术团队首席架构师白鳝(徐戟)老师在“DBA+南京群”进行了一次关于“从一个案例看系统优化”的线上主题分享。小编特别整理出其中精华内容,供大家学习交流。 嘉宾简介 白鳝(徐戟),国内最早的...
  • 一个决策序列就是在变化的状态中产生出来的,所以,这种多阶段最优化决策解决问题的过程就称为动态规划。 二、基本思想与策略  基本思想与分治法类似,也是将待求解的问题分解为若干个子问题(阶段),按顺序求解...
  • 导读:笔者早年间从事了多年开发工作,后因个人兴趣转做数据库。在长期的工作实践中,看到了数据库工作(特别是SQL优化)面临的种种问题。本文通过几个案例探讨一下SQL优化的相关问题。作者:马...
  • 其实核心思想跟之前我们讲过的“ParNew+CMS”的垃圾回收器组合的优化思想是类似的,但是因为G1的运行原理有一些不一样的地方,所以说在优化上会略有不同。 首先我们来说说案例的背景,这是一个百万级注册用户的在线...
  • 当input输入框联想匹配的时候,你如果只写了对应监听事件去做请求,会发现每输入一个字符,页面的数据替换也是迅速的替代,因为数据替换较快,所以还...下面来讲解一下简单的案例: 1.我们首先,随便写一个简单的i...
  • 本套技术专栏从真实商业环境抽取案例进行总结和分享,并给出OLAP商业实战指导,请持续关注本套博客。版权声明:本套OLAP商业实战系列归作者(秦凯新)所有,禁止转载,欢迎学习。 Kylin官方案例是一个非常经典的...
  •  此项目可以说是比较严格的遵循了相关管理的标准,在三个月的实施中,我们秉承这“稳定大于效率”的思想,工作细化到每一步,每一步都有详细的说明,最终保证了三套系统的上线运行零故障!  文章...
  • 梯度下降法的优化思想是用当前位置负梯度方向作为搜索方向,因为该方向为当前位置的最快下降方向,所以也被称为是”最速下降法“。最速下降法越接近目标值,步长越小,前进越慢。梯度下降法的搜索迭代示意图如下图所...
  • 面向对象的编程思想是当下主流思想:一个对象有若干个属性,一个容器装很多个对象,如果想获取对象的属性,需要获取对象然后进行点操作。面向数组则完全不同。在做data science(DS) 和 machine learning(ML) 项目的...
  • 一、聚类分析 聚类分析是根据在数据中发现的描述对象(数据)及其关系的信息,将数据划分成有意义或有用的组(簇)。其目标是: 组内的对象相互之间是相似的(相关的),而不同组中的对象是不同的(不相关的);...
  • MySQL优化那些事

    千次阅读 2018-04-11 15:32:04
    项目上线了一段时间,每天成百上千万数据生成,相关系统资源消耗也随之增加,分库分表、缓存也慢慢落地加入,但其中sql语句优化,像索引、查询优化等,更是重点之重(不久前一个业务点上线,由于数据量和查询未评估...
  • 超级全面的MySQL优化面试解析

    千次阅读 多人点赞 2019-09-02 10:13:40
    作者:Anwen juejin.im/post/5c6b9c09f265da2d8a55a855 ... SpringBoot内容聚合 ...为什么要优化 系统的吞吐量瓶颈往往出现在数据库的访问速度上 随着应用程序的运行,数据库的中的数据会越来越多,处理时间会相...
  • 关于服务性能优化思考

    千次阅读 2017-03-06 23:58:35
     开发者在开发的过程中都需要时刻注意自己服务的性能,但有时候会常常在思想上犯一个毛病 :“性能做得好没啥用处,能用就行,流量高峰期扩容吧 ” 。那我们谈谈为什么需要对服务进行性能优化?至少有两点,一 是...
  • 关于二阶锥优化(SOCP)的学习

    万次阅读 2011-11-24 22:03:17
    原来,数学不好的时候,真...接触到SOCP的起因在于大多多视觉几何下面的问题通常可以通过建立优化模型来求解,而凸优化又是这类模型中性质最为优良的一种——它具有全局最优值(因而也是大家研究最多的一种模型)。不例
  • 案例上手 Spring 全家桶

    千次阅读 2019-07-21 23:30:02
    案例上手 Spring 全家桶》课程亮点spring boot面试题 Spring 技术零基础轻松入门 spring boot 68 讲更全面地覆盖 Spring 全家桶核心模块 100+ 段代码示例,理解 Spring 全家桶要领 3 大项目实战,掌握 Spring ...
  • 优化算法——常见优化算法分类及总结

    万次阅读 多人点赞 2018-10-27 12:54:53
    之前做特征选择,实现过基于群智能算法进行最优化的搜索,看过一些群智能优化算法的论文,在此做一下总结。 最优化问题  在生活或者工作中存在各种各样的最优化问题,比如每个企业和个人都要考虑的一个问题“在...
  • 实战SEO——实用技法与案例剖析

    千次阅读 2011-09-19 15:45:02
    实战SEO——实用技法与案例剖析  藏锋者 编著 ISBN978-7-121-14273-4 2011年9月出版 定价:55.00元 16开 472页 内 容 简 介 本书针对SEO细节操作、技术实施、实际案例进行了详细分析,主要包括建站前的...
  • Hive案例 需求:统计出掉线率最高的前10基站 数据: record_time:通话时间 imei:基站编号 cell:手机编号 drop_num:掉话的秒数 duration:通话持续总秒数
  • Unity大场景数据加载及优化方案

    万次阅读 多人点赞 2018-08-07 16:29:55
    前段时间,有几个虚拟仿真公司跟我请教关于大地形的加载优化问题,它们使用的引擎都是自己研发的,引擎对于开发者来说,大同小异,它们的基本构造是一样的,关键是在于解决问题的方法,正是基于这个前提写了这个课程...
  • 二叉树算法应用案例

    千次阅读 2017-01-02 19:40:09
    还有一种是最优二叉树也称为哈夫曼树,下面开始案例的分享。 在游戏开发中美术会制作很多图片,这些图片一方面是用于UI界面,另一方面是用于模型的材质。大部分网络游戏使用的图片数量是非常多的,图片要展示出来...
  • python练习案例100例(每天坚持一粒,按时服下)

    万次阅读 多人点赞 2019-11-22 20:26:13
    简单的代码实现(优化)实现了可以控制比较数字大小的个数,个人思想: 放上一个列表,采用sort()方法加上for循环比较后放入列表中 代码实现: #!/usr/bin/python # -*- coding: UTF-8 -*- len = [ ] ...
  • 动态规划算法经典案例

    千次阅读 2019-04-29 19:20:10
    动态规划算法是从暴力搜索算法优化过来的,如果我们不清楚暴力搜索的过程,就难以理解动态规划的实现,当我们了解了动态规划算法的基本原理的文字概述,实现条件之后,这时可能并不是太理解这种思想,去面对实际问题...
  • MySQL 索引原理及慢查询优化

    千次阅读 2016-05-19 19:43:28
    虽然性能出色,但所谓“好马配好鞍”,如何能够更好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如“精通MySQL”、“SQL语句优化”、“了解数据库原理”等要求。我们知道一般的应用系统,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,701
精华内容 16,680
关键字:

关于优化思想的案例