一个简单的优化例子(锁问题)

最新推荐文章于 2024-12-01 23:54:11 发布
最新推荐文章于 2024-12-01 23:54:11 发布 · 95 阅读 · 0
文章标签：

#前端 #数据库 #php #ViewUI

本文分析了一项批量处理操作因锁竞争导致性能下降的问题。通过详细的SQL跟踪和会话级监控，发现长时间的网络延迟成为锁等待的主要原因。

前一阵刚给同事做完一个tuning的培训，顺便把以前做过的case重新整理了一下，今天发出来。

case的开始是客户开始抱怨一个批量处理的操作现在变得很慢，在开发的帮助下，我们可以在生产环境中轻易的测试这个操作，而且发现响应时间确实是比以前慢了。这一般是个好的开始，因为我们至少知道问题是什么。

首先，我们通过session级别的trace，发现这个批处理在执行的过程中存在最多的等待事件是enqueue： 

PHP code:

OVERALLTOTALSFORALLNON-RECURSIVESTATEMENTS



callcountcpuelapseddiskquerycurrentrows

-----------------------------------------------------------------------

Parse280.010.000000

Execute280.1019.76025712514

Fetch140.000.00056014

-----------------------------------------------------------------------

total700.1119.78031312528



Missesinlibrarycacheduringparse:0



Elapsedtimesincludewaitingonfollowingevents:

EventwaitedonTimesMax.WaitTotalWaited

----------------------------------------Waited----------------------

SQL*Netmessagetoclient1840.000.00

SQL*Netmessagefromclient18418.75220.84

enqueue142.6217.64

logfilesync140.020.08

SQL*Netbreak/resettoclient140.292.03

bufferbusywaits40.020.03



而引起最多enqueue等待的SQL是:



selectrowid,bsr.*

from

BATCH_SUB_REQUESTbsrwherebsr.BSR_REQUEST_ID=:1andbsr.BSR_item=(select

bsr2.BSR_ITEMfromBATCH_SUB_REQUESTbsr2/*+INDEX(bsr2

idx_batch_sub_request)*/where(bsr2.BSR_STATUS='new')and

bsr2.BSR_request_id=bsr.BSR_request_idandrownum=1)forupdate





callcountcpuelapseddiskquerycurrentrows

-----------------------------------------------------------------------

Parse70.000.000000

Execute70.0617.700229410

Fetch70.000.0003507

-----------------------------------------------------------------------

total210.0617.710264417



Missesinlibrarycacheduringparse:0

Optimizergoal:CHOOSE

Parsinguserid:54



RowsRowSourceOperation

----------------------------------------------------------

1FORUPDATE(cr=5r=0w=0time=947us)

3TABLEACCESSBYINDEXROWIDBATCH_SUB_REQUEST(cr=25r=0w=0time=3205us)

3INDEXRANGESCANPK_BATCH_SUB_REQUEST(cr=22r=0w=0time=3141us)(objectid40913)

2COUNTSTOPKEY(cr=10r=0w=0time=477us)

2TABLEACCESSBYINDEXROWIDBATCH_SUB_REQUEST(cr=10r=0w=0time=437us)

2INDEXRANGESCANIDX_BATCH_SUB_REQUEST(cr=6r=0w=0time=305us)(objectid43816)





Elapsedtimesincludewaitingonfollowingevents:

EventwaitedonTimesMax.WaitTotalWaited

----------------------------------------Waited----------------------

SQL*Netmessagetoclient420.000.00

SQL*Netmessagefromclient420.3112.25

enqueue142.6217.64

bufferbusywaits40.020.03

********************************************************************************



在进行测试的时候，我通过v$session_wait检查了enqueue类型，是mode6的TX锁，也就是由dml操作引起的行级锁：

SQL>SELECTchr(to_char(bitand(p1,-16777216))/16777215)||

chr(to_char(bitand(p1,16711680))/65535)"Lock",

to_char(bitand(p1,65535))"Mode"

FROMv$session_wait

WHEREevent='enqueue'andsid=31;



LockMode

----------------------------------------------

TX6



所有的迹象都指向了一个SQL的lock问题，让我们看看这个SQL：

select rowid, bsr.*
from
BATCH_SUB_REQUEST bsr where bsr.BSR_REQUEST_ID=:1 and bsr.BSR_item=(select
bsr2.BSR_ITEM from BATCH_SUB_REQUEST bsr2 /*+ INDEX (bsr2
idx_batch_sub_request) */ where (bsr2.BSR_STATUS='new' )and
bsr2.BSR_request_id = bsr.BSR_request_idand rownum=1) for update

这是一个select ... for update的语句，目的是为了从batch_sub_request这个表里面选出一行，这里面的条件rownum=1引起了我的注意，因为这会使select锁定这张表的地一样，我知道系统上一般会有10个左右进程会一起运行这个同样的select，按照这种写法，同一时间只能有一个select ... for update可以成功，其他的进程必须等待，而等待事件就是enqueue。这显然是有问题的。

我就这个问题和开发组的同事交流了一下，开发的同事一方面同意这个SQL是有问题，但另一方面也向我提出了另一个费解的问题，同样的设计，为什么在测试环境下性能就是好的呢？
这确实是个很奇怪的问题，我们通过在测试环境下重做这个批处理的操作，并且trace下来，发现测试环境下虽然最大的等待事件还是enqueue，但每次等待的时间都是很短的，只需要零点几秒，而在生产环境中每次enqueue的等待时间是2秒以上。

我仔细的看了生产上的trace文件的每一个环节，发现select ... for update之后应该马上做一个update并且commit，从而释放锁。从这个角度来看，其他进程等待lock的时间应该取决于这个update的速度，但是当我兴高采烈的检查update的性能的时候，发现这个update只需要0.01秒都不到的时间。在10个左右的并发情况下，等待最长的那个进程也不应该等待超过0.1秒！
到底我们遗漏什么？最后的可能性是select ... for update和update之间有些东西被我们忽略了，带着这个问题我和开发再次对整个流程交流了一下，终于发现原来当我们做完select ... for update之后，系统还要做一件事情，那就是把select出来的结果发到前端服务器的java程序，前端的java程序要做一些处理。“但是，”开发说，“我们肯定前端的这个处理是很快的，绝不会超过0.1秒”。如果数据库和应用都很快，那慢的的东西就只能有一个了--------网络。

在我们的环境了，有9太前端服务器，3台在美国，3台在亚洲，3台在欧洲，为了提高这个批处理操作的性能，我们允许所有的9台前端服务器帮助处理一个批处理操作，这本来是个好的想法，但是当亚洲的前端成功的做完了select ... for update, 把结果发回给亚洲的前端，亚洲的前端处理好之后再返回下一条指令给数据库，这个过程中如果网络很慢的话可能需要5秒以上，要知道，在这5秒里，所有的其他8台前端的进程都在等待enqueue，这就是enqueue很大的原因！在我们的情况里，本来希望更多的server可以提高性能，但由于网络原因导致部分网络比较差的server堵塞了好的server。

之后我们单独用美国的前端，亚洲的前端，欧洲的前端做测试，发现只用美国前端的时候性能很好，而只用亚洲或欧洲的前端的时候性能都很差，因此问题就是慢的网络导致了大量的enqueue。

这个案例其实很简单，关键是：
1, 开始和开发沟通不充分，漏掉了很重要的环节，主要我自己没多少开发经验。
2, 我自己也有点思维定势，看到SQL*Net message from client很高也没在意，看到enqueue就一头扑上去了。其实如果我们在系统级别监控如果发现SQL*Net message from client很高，可能是很难判断到底应不应该忽略，但如果是在session级别监控到，就要具体分析了。
3，设计还是很重要，这里如果在设计阶段就把lock的影响考虑进去，也不会最后在生产上由于网络不好导致问题。

只用AM的前端监控到的性能： 

PHP code:

selectrowid,bsr.*

from

BATCH_SUB_REQUESTbsrwherebsr.BSR_REQUEST_ID=:1andbsr.BSR_item=(select

bsr2.BSR_ITEMfromBATCH_SUB_REQUESTbsr2/*+INDEX(bsr2

idx_batch_sub_request)*/where(bsr2.BSR_STATUS='new')and

bsr2.BSR_request_id=bsr.BSR_request_idandrownum=1)forupdate





callcountcpuelapseddiskquerycurrentrows

-----------------------------------------------------------------------

Parse360.000.000000

Execute360.050.110521890

Fetch360.050.040180036

-----------------------------------------------------------------------

total1080.100.1607018936



Missesinlibrarycacheduringparse:0

Optimizergoal:CHOOSE

Parsinguserid:54



RowsRowSourceOperation

----------------------------------------------------------

1FORUPDATE(cr=5r=0w=0time=798us)

2TABLEACCESSBYINDEXROWIDBATCH_SUB_REQUEST(cr=15r=0w=0time=1888us)

2INDEXRANGESCANPK_BATCH_SUB_REQUEST(cr=13r=0w=0time=1856us)(objectid40913)

1COUNTSTOPKEY(cr=5r=0w=0time=160us)

1TABLEACCESSBYINDEXROWIDBATCH_SUB_REQUEST(cr=5r=0w=0time=144us)

1INDEXRANGESCANIDX_BATCH_SUB_REQUEST(cr=4r=0w=0time=115us)(objectid43816)





Elapsedtimesincludewaitingonfollowingevents:

EventwaitedonTimesMax.WaitTotalWaited

----------------------------------------Waited----------------------

SQL*Netmessagefromclient2180.040.20

SQL*Netmessagetoclient2170.000.00

enqueue80.000.04

********************************************************************************

iteye_2060
关注
分布式锁实现解析：几种简单方式的对比与选择
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
12-25 172万+
本文分析了几种常见的分布式锁实现方式，包括基于Redis、ZooKeeper和数据库的方案。通过对每种方式的原理、优缺点进行深入剖析，本文旨在帮助开发者根据不同的应用场景选择合适的分布式锁实现。同时，文章还讨论了分布式锁的使用建议和最佳实践，为解决分布式系统中的并发控制问题提供了有效的参考。
锁的艺术：Java并发中的常用锁策略与实践
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
05-12 170万+
对java锁相关内容进行整理分析：乐观锁 VS 悲观锁+自旋锁 VS 适应性自旋锁+无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁+公平锁 VS 非公平锁+可重入锁 VS 非可重入锁+独享锁 VS 共享锁
系统优化实例一则
congmi1918的博客
06-16 1776
2016年初刚刚从CSC辞职回老部门没多久，就听说了部门里有个系统有些问题，最主要的就是反应在系统性能上。然后没多久，该系统的两任Tech lead都跳槽了。再然后这个有问题的系统也划到我名义下来兼管了。之后就经历了一段黑暗时...
简单参数优化案例
allenhulove的博客
02-22 384
参数优化案例： 1、服务器16G内存，峰值最大连接数为500个，使用MyISAM和InnoDB两种引擎。 为操作系统预留20%内存，约3G 2、与线程相关的几个关键参数 sort_buffer_size=2M read_buffer_size=2M read_rnd_buffer_size=2M join_buffer_size=2M 峰值最大将占用500*(2+2+2+2)=...
Oracle-job跑批卡住案例(代码逻辑问题)
sinat_36757755的博客
09-22 1064
近期处理了一起应用每日跑批job突然卡住的问题，与之前处理过的job跑批变慢不同，此次的job卡住不是性能问题，而是job的存储过程代码逻辑设计不合理所导致。
使用 Tkprof 分析 ORACLE 跟踪文件【转自dave博客】
Mr.pan felix的专栏
08-15 1149
  Tkprof是一个用于分析Oracle跟踪文件并且产生一个更加清晰合理的输出结果的可执行工具。如果一个系统的执行效率比较低，一个比较好的方法是通过跟踪用户的会话并且使用Tkprof工具使用排序功能格式化输出，从而找出有问题的SQL语句。 一. TKPROF 命令语法： TKPROF  filename1, filename2 [ SORT  = [ opion][,option] ]   ...
接口性能优化宝典：解决性能瓶颈的策略与实践
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
12-01 173万+
本文深入探讨了提升接口性能的多种策略，涵盖了数据库优化、远程调用、异步处理、事务优化、缓存机制、分库分表等方面的技术。通过直面常见性能瓶颈，本文详细讲解了如何优化 SQL 执行效率、避免重复调用、减少事务复杂性、提高并发度，并提供了实际应用的最佳实践和技术方案。此外，文章还结合具体的案例，阐述了如何通过合理选择和设计优化方案，解决常见的性能问题，帮助开发者构建高效、可扩展的系统架构。
黄金加密锁.zip易语言项目例子源码下载
03-22
黄金加密锁.zip是一个易语言项目的实例源码，它提供了丰富的学习资源，适用于个人技术提升、学生毕业设计以及小型团队的项目开发参考。易语言是一种中国本土化、简单易学的编程语言，旨在降低编程门槛，让更多人能够...
如何利用Redis锁解决高并发问题详解
09-09
在这个例子中，我们使用了一个简单的`Lock`类，包含获取和释放锁的方法。在尝试获取库存之前，先尝试获取`inventory_lock`锁，确保同一时刻只有一个线程能够执行库存操作。操作完成后，无论成功还是失败，都需要释放...
使用TKPROF 工具分析跟踪文件
03-31
使用TKPROF 工具分析跟踪文件 实验目的：让学员熟练掌握使用TKPROF 进行跟踪文件分析 实验环境：VmWare Server 1.0.4+RHEL as 4+Oracle 10g 10.2.0.1.0 实验场景： Tkprof 是一个用于分析Oracle 跟踪文件并且产生一个更加清晰合理的输出结果的可执行工具。如果一个 系统的执行效率比较低，一个比较好的方法是通过跟踪用户的会话并且使用Tkprof 工具使用排序功能格式 化输出，从而找出有问题的SQL 语句。 TKPROF 工具是oracle 提供的免费工具，有人习惯称之为"Trace Kernel Profile",也有人称之为"Tool Kit Profiler"或"transient kernel profiler. "。不过，这都不重要，重要的是我们应该掌握究竟应该如何 使用该工具对TRACE 文件进行分析。
10046 事件跟踪
王小辉的专栏
02-16 326
10046事件是oracle提供的内部跟踪事件，是对SQL_TRACE的曾强，提供10046可以通知oracle内核开启SQL_TRACE类的跟踪。使用步骤如下： 1.开启跟踪：SQL> alter session set events ‘10046 trace name context forever , level 12’; 2.执行跟踪内容：SQL> select * from work
系统性能优化策略案例
Mark’s Blog
01-13 7698
XX银行网银系统是一套全新的对公业务渠道类系统，经过两年的建设，将逐步对外提供服务。 该系统融合了原来多个对公渠道系统，并发量是以前多个系统之和，吞吐量要求将大幅上升。为了使广大对公客户使用系统时获得更快的响应时间体验，项目组对系统进行了持续的性能测试和优化。这一过程中，形成了一套针对新建系统进行性能测试和优化的方法论。 该方法论包括测试环境准备、测试功能优先级、性能优化原则、常用性能指标及工具、...
oracle全局索引 效率,SQL优化思路&结果集重用优化、分区索引优化测试
weixin_29306317的博客
04-11 400
1.自己构造两条不同的SQL来完成相同的查询,注意结果集重用对SQL性能的影响四个主人公：alan leonarding sun xy故事：这4个小伙伴刚刚毕业，毕业后都顺利的找到了工作，现在已经工作半年了，一次他们聚在了一起，由于虚荣心的驱动他们想比一比谁的工资攒的多，大家都是学IT出身，于是他们做了一个leo_salary表来计算他们这半年来的平均工资！创建了leo_salary表，雇...
删除大表的数据:普通删除语句和游标处理的比较
Robo's Blog【海阔凭鱼跃,天高任鸟飞】
03-01 1001
一、前言 WHERE条件用不到索引的情况下如何删除大表记录? 文章中只是列举出其中一种方式而已,但仍然存在很多不严谨的地方.只是 轻描淡写随着数据表越来越大,历史数据的处理将越来越困难.且过滤字段没有索引(如时间)字段,而创建索引是需要临时表空间排序的.有越来越大,创建的维护工作也随之越来越难. 除了本文介绍的方法以外,还可以通过以下几种方法来维护历史数据: 1. 创建历史表,将历史
多目标优化问题及求解
Hello！
01-08 2万+
多目标优化是多准则决策的一个领域，它是涉及多个目标函数同时优化的数学问题。多目标优化已经应用于许多科学领域，包括工程、经济和物流，其中需要在两个或多个相互冲突的目标之间进行权衡的情况下作出最优决策。分别涉及两个和三个目标的多目标优化问题的例子有：在购买汽车时降低成本，同时使舒适性最大化；在使车辆的燃料消耗和污染物排放最小化的同时将性能最大化。在实际问题中，甚至可以有三多个目标。对于非平凡多目标优化问题，不存在同时优化每个目标的单个解决方案。在这种情况下，目标函数被说成是冲突的，并且存在一个（可能无限）数量的
oracle 10046使用学习
xiaobluesky的专栏
11-30 520
设置10046事件来进行SQL跟踪，可以设置不同的跟踪级别 Level 0   停用SQL跟踪，相当于SQL_TRACE=FALSE Level 1   标准SQL跟踪，相当于SQL_TRACE=TRUE Level 4   在level 1的基础上增加绑定变量的信息 Level 8   在level 1的基础上增加等待事件的信息 Level 12 在level 1的
一篇文章讲清楚凸优化问题
weixin_62457573的博客
01-03 5364
现在这个问题我们就可以一目了然了。凸优化问题是优化问题的一种特殊类型，其中目标函数是凸函数，约束函数是凸集意义下的不等式和等式。在凸优化问题中，我们希望最小化（或最大化）一个凸（或凹）函数，而这个函数的定义域被指定为一个凸集。粗浅理解，你可以把凸函数想象成一个碗，无论你在碗里的任何地方，只要你一直朝着下坡的方向行走，最后一定会到达碗底，也就是函数的全局最小值点。并且当你经过的两个点都在被允许的空间之内（也就是可行集中）时，这两点之间的连线上的任意点不会超过这个空间。
两个示例分析系统优化的选择
郝玉杰的专栏
09-30 628
今天讲了两条：（1）最小粒度的机会均等和资源可以不均等；（2）不允许有pipeline（一串连续的最小粒度占据一个CPU core）
用Java写一个单例模式例子
最新发布
03-08
<think>嗯，用户让我用Java写一个单例模式的例子。首先，我得回想一下单例模式的定义和用途。单例模式属于创建型设计模式，确保一个类只有一个实例，并提供全局访问点。这在需要控制资源或者共享资源时很有用，比如数据库连接池、日志对象等。 接下来，我需要考虑不同的实现方式。常见的单例实现有懒汉式、饿汉式、双重检查锁、静态内部类、枚举等。用户可能希望一个简单明了的例子，所以应该选择最典型的几种来说明。 首先是饿汉式，这个实现简单，类加载时就初始化实例，线程安全。不过可能会浪费资源，如果实例很大且不常用的话。然后是懒汉式，延迟加载，但需要考虑线程安全问题。早期的懒汉式不加同步锁的话，多线程环境下会出问题，所以需要加synchronized关键字，但这样会影响性能。 然后双重检查锁，结合了懒汉式的延迟加载和线程安全，通过两次检查实例是否存在，减少同步的开销。不过要注意volatile关键字的使用，防止指令重排序导致的问题。 静态内部类方式利用了类加载机制，静态内部类在第一次使用时才会加载，从而实现了延迟加载，并且由JVM保证线程安全。这种方式比较优雅，代码也简洁。 还有枚举方式，Effective Java推荐的方法，不仅能避免多线程问题，还能防止反序列化重新创建新对象。不过可能不太灵活，比如无法继承其他类。 用户可能需要一个具体的例子，我应该给出几种常见的实现，并说明优缺点，让用户根据场景选择。同时要提醒注意事项，比如线程安全、序列化问题、反射攻击等。 现在需要把这些整理成代码示例，用中文解释清楚每种实现的原理和适用情况。可能用户是刚开始学习设计模式，所以需要解释得详细一些，确保他们能理解不同实现方式的区别和适用场景。 还要注意代码格式，用户要求行内数学表达式用$...$，但这里主要是代码块，所以需要用正确的Java语法，可能用三个反引号包裹代码块。不过用户没有特别说明代码块的格式，但根据系统指令，可能需要使用$$...$$，但代码块通常用反引号。不过原例子里用户用了三个反引号，可能应该遵循这一点。不过原例子里用户给的是系统指令中的例子，所以可能用户希望用标准的代码块格式。 最后，要确保回答结构清晰，分点列出不同的实现方式，每种方式给出代码示例、优缺点和适用场景。这样用户能一目了然，选择适合自己需求的方式。</think>好的！单例模式是设计模式中最基础的模式之一，主要作用是保证一个类仅有一个实例，并提供全局访问点。以下是几种常见的Java实现方式及详细说明： --- ### 一、饿汉式（线程安全） ```java public class Singleton { // 类加载时直接初始化实例 private static final Singleton INSTANCE = new Singleton(); // 私有化构造方法 private Singleton() {} // 提供全局访问点 public static Singleton getInstance() { return INSTANCE; } } ``` **特点** - **线程安全**：实例在类加载时创建，由JVM保证线程安全 - **缺点**：可能浪费资源（即使未使用也会创建实例） - **适用场景**：实例较小且一定会被使用的情况 --- ### 二、懒汉式（线程不安全→改进为线程安全） ```java // 基础版（线程不安全） public class Singleton { private static Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); // 多线程可能重复创建 } return instance; } } // 改进版（加锁，线程安全但性能低） public class Singleton { private static Singleton instance; private Singleton() {} public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } ``` **特点** - **延迟加载**：首次调用`getInstance()`时创建实例 - **缺点**：同步锁影响性能 - **适用场景**：单线程环境或对性能要求不高的情况 --- ### 三、双重检查锁（DCL，线程安全） ```java public class Singleton { // volatile禁止指令重排序 private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); } } } return instance; } } ``` **特点** - **延迟加载 + 高效线程安全**：通过两次判空和`volatile`关键字优化性能 - **适用场景**：高并发环境 --- ### 四、静态内部类（线程安全） ```java public class Singleton { private Singleton() {} // 静态内部类在第一次使用时加载 private static class Holder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; // 触发类加载并初始化实例 } } ``` **特点** - **天然线程安全**：由JVM保证类加载过程的线程安全 - **延迟加载**：内部类在调用`getInstance()`时加载 - **推荐方式**：简洁高效，无锁性能优 --- ### 五、枚举实现（最简洁的线程安全方式） ```java public enum Singleton { INSTANCE; // 枚举实例天然单例 public void doSomething() { // 功能方法 } } ``` **特点** - **绝对单例**：防止反射攻击和序列化破坏 - **代码极简**：直接通过`Singleton.INSTANCE`调用 - **推荐方式**：符合《Effective Java》建议 --- ### 关键注意事项 1. **反射攻击**：除枚举方式外，其他实现可能通过反射破坏单例（可通过构造方法中抛出异常防御） 2. **序列化安全**：若需序列化，应实现`readResolve()`方法返回已有实例 3. **多类加载器**：不同类加载器可能加载多个实例（需统一类加载器环境） 实际开发中推荐优先选择 **静态内部类** 或 **枚举** 实现方式。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值