Some excel tech

shysnake

朋友教我使用excel:
1.函數的使用
  vlookup
  sumif
  sum
  if
2.樞紐分析
3.connet to oracle db by ODBC


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/3305/showart_29196.html

shysnake

情况总结：
- WebLogic参数设置正常，点击BOM或者高级查询出现性能慢问题时，线程池和连接池占用率不高，均无等待的情况，JVM的GC开销不大，IO无异常变化，CPU维持在20~80%间变化，内存paging无异常。
- JVM上heap大小的设置对于IBM的JVM个人建议大小不同（IBM JVM在这点上与其他JVM不同）
- 建议根据线程快照分析应用程序。

附：
- gc是JVM垃圾收集的日志
- Transaction statistics.docx是分析过程查阅数据的一些截图
= 可以看出BOM查询引起的事务持续时间较长，相关的程序是weblogic.transaction.name=[EJB com.agile.pc.cmserver.item.ItemSessionBean.getExpandedTree(long,com.agile.util.CMObjectID,int,com.agile.pc.common.CMWarning,com.agile.common.client.value.LoadTableParam,int)]
= 可以看出高级查询引起的事务持续时间较长，相关的程序是weblogic.transaction.name=[EJB com.agile.cs.query.QuerySessionBean.executeQuery(long,com.agile.util.CMObjectKey,com.agile.pc.common.CMWarning,com.agile.common.client.value.QueryExecutionParams)]
- javacore是出现性能慢问题时的线程快照，大约间隔5~10秒作的一个快照。
说明：original目录是线程快照的原始文件，simplified目录是仅选取线程快照中运行查询的线程的快照。
= BOM查询子需求的问题：
  # 从javacore.20101109.144813.344542.0001.txt到javacore.20101109.145219.344542.0043.txt
= 高级查询的问题：
  # 从javacore.20101109.155641.344542.0056.txt到javacore.20101109.155738.344542.0066.txt
分析：
= 出现DebugPreparedStatement、DebugConnectionFactory、DebugConnection这样的类，建议检查日志（可能与SQL/JDBC的日志有关系）设置。
= 另外从线程快照看，运行中的Java程序可能通过printStackTrace来获知调用者是谁（哪个类，哪个函数在调用我），此方式不建议使用。