资源供给：并发性控制和latch之二
原创 Oracle 作者：sunsapollos 时间：2013-12-12 00:13:46 7780 0latch，spinlock，轻量的旋转锁，顾名思义通过spin来获得latch。
Oracle期望latch的持有时间很多，所以采用在线等待的方式来获得latch，也就是spin。注意spin不释放CPU资源，在spin期间消耗大量的CPU资源资源，在无法通过spin获得latch之后发布latch free事件，然后进入sleep，等待被唤醒。
Oracle 9.2之后采用了不同的方式来处理spin和sleep，据相关文章研究：绝大部分latch仅仅在spin在线等待指定次数之后就进入sleep状态，等待被唤醒。在等待被唤醒期间是采用queue结构。也就是同样的latch冲突处理，在Oracle 9.2之后其CPU消耗会大幅度下降，但是可能会遭遇更高的等待时间。
我们来比较以下两种不同的latch获取结构
gets --> spin gets --> sleep ---->wakeup
gets --> spin gets -->sleep ---> spin gets ---> sleep ---> gets
post机制的最大问题在于可能会发生post丢失，post丢失可能会导致Session由于等待latch永久挂起，而期间压根就没有人拥有该latch。现在还不清楚，是否存在某种机制wait latch process自我唤醒。
spin机制的好处在于某些热门的业务应用几乎总是可以快速的获得latch（通过牺牲冷门的session来完成）。
在我们的业务系统处理中，总有些进程的处理迫切程度比较高，需要及时获得latch，比如smon,lms等进程，我们可以设置smon,lms,lgwr,ckpt等进程处于实时的优先级，从而使其可以被有限post，从而不至于在队列中被阻塞。
为了支持更高的latch并发，Oracle现在相当多的latch采用CAS机制，compare and swap，事实上mutex也采用CAS机制，其他latch保持原有的TAS latch。
CAS latch为共享latch，也就是说在共享模式下可以共同访问，采用加latch +1,释放latch -1的方式，exclusive占有只有在计数为0的时候才可以获得。大家事实上可以看到CAS由于要更新计数，在更新期间即使是共享模式也是需要独占访问。
TAS模式为独占访问，也就是说某一时刻只允许一个Session访问该latch，不管其访问使什么模式的。
spin_count的缺省值为2000，该值设置仅仅对于shared latch有效，也就是说CAS latch有效。对于TAS的latch，其缺省值为20000。Exclusive latch的spin_count不能在线修改，但可以重启后生效。
Oracle为了进一步对于不同的latch进行spin_count控制，提供了分类的latch，可以参看视图：x$ksllclass
我们可以通过设置latch到不同的分类，并且设置其参数达到控制spin次数的目的。
_latch_class_1 = "5000"
_latch_classes = "98:1"
比如以上操作就是把cache buffer chain的spin_count设置为5000。
调整spin_count:
spin_count消耗CPU资源，但可以加速latch获取速度，如果你的CPU资源比较充分，可以增加spin_count通过消耗CPU资源获取相应时间的加速。
当然如果你CPU资源本身就紧张，还通过增加spin_count来加速获得latch可能会带来灾难。
在除了CPU资源判断之外，很难判断什么时候增加和减少是合适。
适当的减少是合适的：
spin_get/misses很低，也就是spin_get几乎没有发生什么作用，可以适当减少降低cpu消耗。
至于spin_get和miss的比例多少增加spin_count是合适的，只能通过真实场景调试了，没有准则了。
spin_count的调整是一个典型的Wait_time下降，响应时间还极有可能增加的案例，也就是说降低等待时间未必一定会降低响应时间，处理时间和等待时间是可以相互转化的。
如果需要进一步了解latch的情况，请访问：http://andreynikolaev.wordpress.com
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-1063039/，如需转载，请注明出处，否则将追究法律责任。