soleghost
- 浏览: 41984 次
- 性别:
- 来自: 未知
-
最新评论
-
teasp：
哪有两个Long啊？分明是两个long，这是原始类型，它们所占 ...
如何计算java内存大小--谁吃了对象引用的16byte？ -
niwtsew：
楼主总结的不错，我也有此体会。一定要淡定
这段代码不是我写的
文章列表
Java内存区域与OOM http://www.iteye.com/topic/802573
·程序计数器：保留线程执行到的指令
·栈：编译期间预期的变量表。层次深：栈溢出；无法创建更多的栈OOM；线程个数=（系统内存-堆-年老代-保留区域）/每个栈空间
·本地栈：native,也会OOM
·堆（eden、s0、s1+old）：生成大量无法回收的对象OOM
·方法区：加载类过多OOM
·常量区：生成太多常量OOM
垃圾收集器与内存分配策略 http://www.iteye.com/topic/802638
·引用计数器：简单，但无法找到循环引用的情况
·搜索算法 ...
系统的性能优化--记项目总结
- 博客分类：
- 技术
项目过去都3个多月了，也没系统的总结，今天总结一下
系统背景：
1.访问量大：每天承受20亿+服务调用
2.海量数据：核心表都是5亿条数据，而且每天还在以几十万的速度增加
3.之前架构：由于读写比例很高，已经采用分 ...
http://blog.csdn.net/yzsind/archive/2010/12/06/6059209.aspx
看了《关于系统性能的思考》，结合自己平时的工作和身边的教训，谈谈自己的一些关于性能的想法
1.性能和容量不是一个概念，在相同条件下，当然性能如果越好，容量会越高
2.性能优化真的不是定式的，还需要相当丰富的经验去解决。以自己身边的系统为例，从Apache、Jboss、F5、网络、应用系统、到最后的DB，就如同是一条回家的路，任何一个环节处理慢了，都可能成为性能的瓶颈
3.一般涉及到性能的地方：
3.1.cache：缓存一切可以缓存的数据。比如数据字典、配置、读多写少的数据，但如果是敏感数据，比如资金，不建议缓存。
3.2.异步：异步一切可以异步的操作。意义不仅仅在于性 ...
1.最明显的功能，排查线上问题。
平时遇到bug时，要相信“人走过，必留下痕迹”，没有什么事情是没有原因的。
2.报警
我们的系统越来越多，业务越来越多，不可能靠人肉每天查询日志以发现问题，还是要利用机器。
针对具体的业务，打印具体格式的日志，通过日志收集系统的规则，发现问题则向相关人员报警。怎么实现日志收集系统呢，可以每隔一段时间，从生产环境中获取指定日志，每次读取后，记录本次读取日志的最后行数，下次再收集日志时，从该行数开始读取新的时间段的日志。
3.统计业务
还是要规范我们的摘要日志的格式，将每次读取的日志写入数据库，比如：
---- ...
在生产环境中，针对具体问题的追踪，没有debug，只有利用logger排查问题，这就要求我们打印logger，具体有哪些logger呢？
1.摘要日志
同步service层摘要日志，打印调用服务，入参，执行时间，执行结果
异步事件接收摘 ...
在应用中，总有一些业务操作可能会引起大数据量的查询，基于应用健壮性的考虑，需要对这些业务控制起来。
思路：外围业务每次请求时，应用每次申请一个资源，当超过限定的资源总数时，不允许业务继续进行. try{
applyResource(); do业务();
}
finally{
releaseResource();
}
实现1：在数据库中，针对具体业务插入一条记录（sysName，sysCount）， synchronized void ...
在有些业务背景下，需要cache防止并发的情况，然后cache却不能提供锁的功能，可以由应用代为实现
1.第一次存入cache的数据时，加一个modifiedTime的时间戳
2.下次更新的时候，必须保证取到当前的时间戳和cache中数据的时间戳一致，这样才可以更新；否则直接removecache，不要影响到正常业务。
其实，这种乐观锁的实现，和DB层的乐观锁实现原理是一样的，即先操作业务，具体执行时必须和DB/cache中的版本或者时间戳保持一致。
在大型的互联网应用中，如果缓存的是大量的数据，可以考虑多级缓存数据
1.第一级cache：本地线程cache
每次将数据放入线程cache（利用ThreadLocal）中，可以避免同一个线程中对同一个缓存数据的访问
2.第二级cache：本地内存cache
利用appserver的内存，将数据放入本地的内存缓存，可以用的工具有EHCache
3.第三级cache：远程cache
利用分布式缓存，当线程cache、内存cache都没有命中时，再去查询远程缓存。可以利用的工具有memcache
4.第四级cache：就是DB了：）
前三层缓存 ...
这篇没有任何技术含量，仅仅是一个良好的编程习惯
随着应用中缓存的业务数据越来越多，为了防止不同业务的key相互覆盖的情况，有个简单的办法，对不用的业务的数据分组，比如：
业务1 prefix1+key
业务3 prefix2+key
业务2 prefix3+key
这样之后，即时各个业务的key相同，也可以防止数据被相互覆盖的情况
如果我们对一个比较复杂的模型做cache，会有如下需求：
1. 利用多个key去查询这一模型的cache
2. 继而要求可以利用多个key去删除cache时
如果按照最简单的模型，每个key对应一个cache数据，这样当某一个key对应cache中的数据变动时，另外一个key对应的cache数据必定成为脏数据。
举例：key1->cacheObject,key2->cacheObject,当put(key1,cacheObject)时，key2对应的数据必定是脏数据；或者remove(key1)时，key2对应的cacheObject也还是会存在的，也是脏数据。
...
在我们的应用中，有一张表的查询量非常之大，高峰期时6000次/second查询，而且更新很少，于是我们的改造来了：
第一次优化：
方法：每次从cache中读取，如果cache中没有命中，则从DB读取，如果有值将此值放入cache中。
效果：上线后效果并不是特别明显，高峰期仍有3000次/second的查询，原因在哪里呢？此表只有700w的数据量，但是对于3亿用户，每个用户都要查询此表，就是说，只有700w/3亿=2.33%可以命中cache，间接导致每次从cache中取数据为空后，仍有97.67%的数据仍然会查询DB。
第二次优化：
方法：每次从DB中查询后，如果是空，则在 ...
在支撑大规模、高并发、高可用的互联网应用中，异步更新分布式缓存的应用已经越来越多了（为什么是异步更新缓存，因为异步不仅可以提高系统性能，而且提高系统的伸缩性和可用性），由于缓存的更新是异步的，可能由于多个更新缓存的并发线程而导致的脏数据。
举例，有下面2个线程A、B同时执行业务，执行完业务之后，会产生2个异步的线程A1、B1去更新缓存，在理想情况下，A1和B1应该保持顺序性，即A1先更新缓存、B1再更新缓存，但是由于线程本身是异步的，加上2个线程可能分布在不同应用服务器上，所以对执行线程时顺序没有办法保证，如果B1先执行，A1再执行，这样B1的数据就被A1覆盖掉，从而导致脏数据。有没有什 ...
这是一个非常值得记忆的时刻
- 博客分类：
- 思考
2008年12月份
收费改造，第一次通宵发布系统；这是刚毕业不久后进入公司，抱着对学习饥渴的心态，申请晚上通宵留守，发布成功，晚上12点吃了一顿烧烤，4点发布完成后监控没有问题，6点和若干开发还在局域网内打了几盘cs，7点pm把热腾腾的豆浆煎饺送上，上午9点和其他开发交接后，10点回家睡觉
2009年11月份
新的个人版发布，作为核心业务的提供方，留守发布，这次同样有烧烤，我们的系统发布没有问题，但是不幸的是，个人版系统由于事前没有评估到某个业务带来的消息挤压，导致下午全站宕机2小时，经验值得学习，教训值得警醒。
马上就到来的2010年7月7日凌晨
虽然这一刻还没到来，但依 ...
以前谈过重用的粒度问题，今天也谈谈冗余的粒度。
1. 数据库字段的冗余
好处1：合适字段的冗余，对于提供数据库的查询速度会有很大提升，因为可以不用于其他表join去获取数据
好处2：在垂直分库的情况下，丧失了join数据表的能力，为了不让业务受伤害，在表上加上一些冗余，同样可以满足业务的需求
坏处：需要在多个表中维护数据的一致性
2. 业务中多个表的冗余
一个最简单的道理，对于大型互联网，比如一次交易，数据会放入不同的业务系统中。比如：买家的交易信息、卖家的交易信息、支付订单的信息、收费的信息、账务的信息、会计的信息。
好处：其实这就是 ...