e-ant

BEA WebLogic平台下J2EE调优攻略（转）

e-ant — Wed, 23 Jul 2008 18:26:05 +0800

作者: e-ant 链接：http://e-ant.javaeye.com/blog/218679 发表时间: 2008年07月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

BEA WebLogic平台下J2EE调优攻略（收藏）

http://www.blogjava.net/lqsun/archive/2005/06/10/5854.aspx

作者：zhouhg (dev2dev ID)
摘要：

　　随着近来J2EE软件广泛地应用于各行各业，系统调优也越来越引起软件开发者和应用服务器提供商的重视。而对于最终客户来说，在一个高效、稳定地实现他们的业务需求已经是他们的基本要求。所以J2EE调优显得非常重要，而BEA WebLogic Server是业界领先的应用服务器，BEA WebLogic平台下的J2EE调优也就尤为重要,她将为我们提供普遍的J2EE调优方案。最近网络、杂志上的J2EE调优文章层出不穷。本人也将自己平时工作中的一些经验积累分享给大家，抛砖引玉。

目录

前言
第一章应用程序调优
1.1.1 通用代码调优
1.1.2 减小没有必要的操作
1.1.3 使用合适的类型
1.1.4 尽量使用pool,buffer和cache
1.2 JDBC代码调优
1.2.1 严格资源使用
1.2.2 实用技巧
1.2.3 优化SQL语句
1.3 Web代码调优
1.3.1 HttpSession的使用
1.3.2 JSP代码调优
1.3.3 Servlet代码调优
1.4 JMS代码调优
1.4.1 注意必要的事项，避免使用不必要的特征
1.4.2 消息类型的选择
1.4.3 确认方式的选择和JMS事务
1.5 EJB代码调优
1.5.1 有效使用设计模式
1.5.2 使用EJB和WebLogic的特性
1.5.3 缓存资源
1.5.4 如何选择和使用Entity Bean
1.5.5 其他的一些小技巧
第二章应用服务器调优
2.1 JVM调优
2.1.1 垃圾收集和堆大小
2.1.2 jRockit调优
2.2 Server调优
2.2.1 尽量使用本地I/O库
2.2.2 调整默认执行线程数
2.2.3 调整连接参数
2.2.4 创建新的执行队列
2.3 JDBC调优
2.3.1 调整连接池配置
2.4 WEB调优
2.4.1 调整WEB应用描述符
2.5 JMS调优
2.6 EJB调优
2.6.1 调整pool和cache
2.6.2 优化事务隔离级别和事务属性
2.6.3 其他一些小技巧
第三章数据库调优
3.1.1 Oracle性能优化
3.1.2 Oracle的其他调整
第四章操作系统调优
4.1 操作系统调整
4.1.1 HP-UX
4.1.2 Solaris
4.1.3 AIX
4.1.4 Linux
4.1.5 Windows
第五章性能监控和性能分析
5.1 性能瓶颈
5.2 操作系统监控
5.3 数据库监控
5.4 WebLogic监控
5.4.1 JVM监控
5.4.2 Console监控
5.4.3 实用工具分析
5.5 应用程序分析
总结
参考文献
关于作者

前言 (目录)

　　随着近来J2EE软件广泛地应用于各行各业，系统调优也越来越引起软件开发者和应用服务器提供商的重视。而对于最终客户来说，在一个高效、稳定地实现他们的业务需求已经是他们的基本要求。所以J2EE调优显得非常重要，而BEA WebLogic Server是业界领先的应用服务器，BEA WebLogic平台下的J2EE调优也就尤为重要,她将为我们提供普遍的J2EE调优方案。最近网络、杂志上的J2EE调优文章层出不穷。本人也将自己平时工作中的一些经验积累分享给大家，抛砖引玉。

　　本文从J2EE应用架构（下图）来分别剖析系统调优，首先我们一般会从应用程序出发，去审核代码，做到代码级的优化，然后再调整应用服务器(BEA WebLogic8.1)和数据库 (Oracle9i)的参数，最后当然是调整操作系统和网络的性能(包括硬件升级)。诚然,在我遇到的很多项目中,都是出现了性能问题后才想到调优,而且一般都是先进行系统参数调整,实在解决不了才会对代码进行检查.实际上,我们应当将代码级的调优放在应用设计时来做,测试生产时修改代码将是一件极其痛苦的事情。

WebLogic平台J2EE应用架构

第一章应用程序调优(目录)
1.1.1 通用代码调优

1.1.2 减小没有必要的操作
　　对象的创建是个很昂贵的工作,所以我们应当尽量减少对象的创建,在需要的时候声明它,初始化它,不要重复初始化一个对象,尽量能做到再使用,而用完后置null有利于垃圾收集。让类实现Cloneable接口,同时采用工厂模式,将减少类的创建,每次都是通过clone()方法来获得对象。另外使用接口也能减少类的创建。对于成员变量的初始化也应尽量避免, 特别是在一个类派生另一个类时。

　　异常抛出对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。

　　此外, 建议关闭Debug输出,尽量少用串行化、同步操作和耗时昂贵的服务(如Date())。

1.1.3 使用合适的类型
　　当原始类型不能满足我们要求时,使用复杂类型。String和StringBuffer的区别自不必说了,是我们使用最多的类型,在涉及到字符运算时,强烈建议使用StringBuffer。在做String匹配时使用intern()代替equal()。

　　带有final修饰符的类是不可派生的, 如果指定一个类为final，则该类所有的方法都是final。

　　Java编译器会寻找机会内联所有的final方法,这将能够使性能平均提高50%。类的属性和方式使用final或者static修饰符也是有好处的。

　　调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。所以尽量使用局部变量。

　　ArrayList和Vector,HashMap和Hashtable是我们经常用到的类,前者不支持同步,后者支持同步,前者性能更好,大多数情况下选择前者。

1.1.4 尽量使用pool,buffer和cache
　　使用pool、buffer和cache能大大提高系统的性能,这在J2EE的大部分技术中都是适用的。

　　在WebLogic中就大量使用了池:JDBC Connection Pool、Socket Pool、Object Pool和Thread Pool。I/O操作中,buffer是必须的,特别是对大文件的操作,不然容易造成内存溢出。字节操作最快,所以尽可能采用write(byte[])，Buffered FileOutputStream比Buffered FileWriter要快,因为FileWriter需要Unicode到Byte的转换。

　　而后面讲到的JDBC、JSP、EJB和JMS我们都非常建议使用buffer和cache。为HttpServletResponse设置buffersize,使用wl-cache,缓存在JNDI树上获取的对象等等。

　　此外,使用JDK 1.4的非阻塞I/O对性能也有很大提高。

1.2 JDBC代码调优
1.2.1 严格资源使用
　　JDBC代码调优最大的原则就是使用WebLogic的连接池,而不是自己直连数据库。在我接触的很多自己实现连接池的项目中,大部分遇到死锁和连接泄漏的问题，最后得不得修改代码。而WebLogic提供了功能强大，性能良好的数据库连接池，我们要做的只是封装一个连接管理类，从JNDI树上获取数据源并缓存，得到连接，并提供一系列关闭数据库资源的方法。

　　对任何资源使用的原则是用完即关，不管是数据库资源、上下文环境，还是文件。数据库资源的泄漏极易造成内存泄漏，乃至系统崩溃。在使用完数据库资源后依次关闭ResultSet，Statement和Connection，而在一个数据库连接多次进行数据库操作时要特别注意ResultSet和Statement依次关闭。

try{
　　//open connection
　　pstmt =conn.prepareStatement(strSql1);
　　pstmt.executeUpdate();
　　pstmt.close();
　　pstmt =conn.prepareStatement(strSql2);
　　rs=pstmt.executeQuery();
　　while (rs.next()){
　　//process
　}
rs.close();
pstmt.close();
　}catch(Exception e){
　　//close rs,psmt,con
}finally{
　　//close rs,psmt,con
}

1.2.2 实用技巧
　　在JDBC操作中还有一些小的技巧跟大家分享：由于获取连接时默认自动提交方式，使用connection.setAutoCommit(false)关闭自动提交，使用PreparedStatement,批量更新,业务复杂或者大数据量操作时使用存储过程，尽量使用RowSet，此外设置记录集读取缓存FetchSize和设置记录集读取方向FetchDirection对性能也有一定的提高。

1.2.3 优化SQL语句
　　SQL语句的优化牵涉到很多数据库的知识，需要与索引配合，因此需要DBA对代码中的SQL进行检查测试。常见的，select *不提倡使用，效率极差，建议显式获取列，即使是所有字段也应罗列，而取总数时使用count(*),为提高cache的命中率，尽量做到SQL重用。对于大数据量的查询，可以充分利用Oracle数据库的特性，每次取出m-n行的数据，实现分页查询。另外，提高性能的好选择可能就是把所有的字符数据都保存为Unicode，Java以Unicode形式处理所有数据，因此，数据库驱动程序不必再执行转换过程。

1.3 Web代码调优
1.3.1 HttpSession的使用
　　应用服务器保存很多会话时，容易造成内存不足，所以尽量减少session的使用，放置session
里的对象不应该是大对象，最好是简单小对象，实现串行化接口。当会话不再需要时，应当及时调用invalidate()方法清除会话。而当某个变量不需要时，及时调用removeAttribute()方法清除变量。请勿将EJB对象放置在session中。

1.3.2 JSP代码调优
　　目前，在JSP页面中引入外部资源的方法主要有两种：include指令，以及include动作。 include指令：例如<%@ include file="copyright.html" %>，该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定，比运行时才确定资源更高效。
include动作：例如。该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但是，只有当被引用的内容频繁地改变时，或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include动作才合算。

　　对于那些无需跟踪会话状态的jsp，关闭自动创建的会话可以节省一些资源。使用如下page指令： <%@ page session="false"%> ;尽量不要将JSP页面定义为单线程，应设置为<%@page isThreadSafe=”true”%>;在JSP页面最好使用输出缓存功能，如: <%@page buffer="32kb"%>;尽量用wl:cache定制标记来缓存静态或相对静态的内容，缓存jsp:include操作的结果能显著提高应用程序的运行性能。

1.3.3 Servlet代码调优
　　Servlet代码调优比较简单：在Servlet之间跳转时，forward比sendRedirect更有效；设置HttpServletResponse 缓冲区，如：response.setBufferSize(20000);在init()方法里缓存静态数据，而在destroy()中释放它；建议在Servlet里使用ServletOutputStream输出图片等对象；避免在Servlet和Jsp中定界事务等。

1.4 JMS代码调优
1.4.1 注意必要的事项，避免使用不必要的特征
　　JMS提供了强有力的消息处理机制，但是为了最大限度的提高JMS系统的性能，应避免使用不需要使用的特征，同时也要注意必要的事项。比如：尽量使用接收程序能直接使用的最简单、最小的消息类型；消息选择器要尽可能简单(最好不使用)，尽量不要使用复杂的操作符，如like、in或者between等,使用字符串数据类型的速度最慢;务必为特定的应用程序定义特定的JMS连接工厂，并且禁用默认的JMS连接工厂；不要在javax.*与weblogic.*的名字空间中使用JNDI名称；尽量使用异步消费者，线程不必封锁以等待消息的到达;使用完JNDI树上的资源后注意关闭。

1.4.2 消息类型的选择
　　标准JMS提供了五种消息类型，而TextMessage应用最为普遍, 当发送的消息是几种原始数据类型的集合体时，最好使用MapMessage消息类型，而不要使用ObjectMessage，以便减少不同系统间的耦合。此外消息是否使用压缩要慎重考虑，压缩未必能减少消息大小。如果生产者、消费者和目的地并置在同一WebLogic Server内部，通常不使用压缩。WebLogic特有的XMLMessage能为运行于消息主体之上的消息选择器提供内嵌式支持，而且易于数据交换。因此，建议应用程序之间传送消息使用XML消息格式，而应用程序内部间传送消息使用二进制消息格式。

1.4.3 确认方式的选择和JMS事务
　　使用事务性会话时,尽量使用恰当的消息确认方式:如果需求允许,使用NO_ACKKNOWLEDGE;非持久的订阅者使用DUPS_OK_ACKNOWLEDGE或者MULTICAST_NO_ACKNOWLEDGE。而使用JTA的UserTransaction，确认方式将被忽略。在使用JMS事务时，无效的消息会导致事务的回滚，以致消息重发这样的死循环。此时，可以将无效消息发送到错误消息队列，并提交JMS事务，这将确保消息不会再次传递。

1.5 EJB代码调优
1.5.1 有效使用设计模式
　　GoF 的《设计模式》为我们实现高性能、易扩展的J2EE应用提供理论保障和技术支持。而EJB作为J2EE的核心组件和技术，善用设计模式对系统性能影响很大。Service Locator 和Value Object 已为我们所熟悉，Floyd Marinescu的《EJB Design Patterns》中的Session Fa?ade、Message Fa?ade、EJB Command和Data Transfer Object等设计模式更是为我们提供设计典范：缓存对EJBHome的访问；使用门面模式，不暴露Entity Bean，用Session Bean封装Entity Bean；如果可以异步处理，则用MDB代替Session Bean；封装业务逻辑在轻量级JavaBean中；使用值对象等简单对象传递数据;不直接使用get/set方法操作Entity Bean。当然过度使用模式或者牵强套用模式也是不提倡的，总的原则就是减少网络流量，改进事务管理。

1.5.2 使用EJB和WebLogic的特性
　　使用EJB和WebLogic的新特性往往能提高性能。与EJB2.0特性相关的技巧有：一个Application中使用本地接口，对于Entity Bean肯定使用本地接口，避免远程调用的开销；使用CMP管理关系，而不是BMP，EJB2.0中CMP的性能大大改善，性能和移植性都优于BMP；使用ejbSelect进行内部查询；使用home方法进行外部查询和批处理; 数据库驱动级联删除等。

　　与WebLogic特性相关的技巧有:使用自动生成主键,WebLogic为Oracle和Sqlserver两种数据库的CMP提供了自动生成主键功能,节约了Entity Bean产生主键的时间,同时设key-cache-size不小于100;WebLogic管理事务性能更好,使用容器管理,而不是Bean管理事务;WebLogic提供了为CMP动态查询和批量插入功能,对性能也有很大帮助。

1.5.3 缓存资源
　　对SLSB或者MDB来说,使用setMesssageDrivenContext()或者ejbCreate()方法缓存特定资源,在ejbRemove()方法里释放; 对SLSB或者MDB来说,使用setSessionContext()或者ejbCreate()方法缓存特定资源,在ejbRemove()方法里释放;对Entity Bean来说,使用setEntityContext ()方法缓存特定资源,在unSetEntityContext ()方法里释放。

1.5.4 如何选择和使用Entity Bean
　　1. 在设计EJB时，要适当考虑EJB的粒度, 细粒度的EJB在事务管理和资源管理的开销太大,尽量创建粗粒度的 EJB , 不要太粗，粗到能满足实际需求就可以;

　　2. Entity Bean不是唯一方式,如果只有一个很小的数据子集被经常改变，建议采用JDO;

　　3. 在操作大数据量的时候,直接采用JDBC比Entity Bean更有效;

　　4. 避免采用返回很大数据组的finder方法,如 FindAll() 方法，因为它的实现代价太大;

　　5. 考虑设置域组field groups,减少没有必要并昂贵的属性加载,如BLOB;

　　6. 对于EJB1.1或者BMP,可以设置is-modified-method-name属性,根据isModified()的值来判断是否调用ejbStore()等方法,减少没有必要运算;

　　7. 避免连接多个表创建BMP,可以使用视图,存储过程或者O/R Mapping等方式。

1.5.5 其他的一些小技巧
　　1. 考虑使用 javax.ejb.SessionSynchronization 接口,提供在Rollback之后恢复数据的方法: afterBegin(), beforeCompletion(), afterCompletion();
　　2. 使用完SFSB之后，调用remove()方法释放实例;
　　3. 假如你不需要EJB服务的时候,建议使用普通Java类;
　　4. 避免EJB之间相互调用;
　　5. 使用多读模式。

第二章应用服务器调优(目录)
2.1 JVM调优
2.1.1 垃圾收集和堆大小
　　垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:)以打开详细的GC输出。分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。
通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx。而为了防止内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最大内存数。对于sun和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m。建议设置临时域-Xmn的大小为-Xmx的1/4~1/3, SurvivorRatio为8。

　　为了获得更好的性能,建议在启动文件设置WebLogic为产品模式,此时sun和hp jvm JIT引擎为-server,默认情况下打开JIT编译模式对性能也有帮助。调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高。此外还需关闭显示GC: -XX:+DisableExplicitGC。

　　当然在Intel平台上使用jRockit（使用参数-jrockit）无疑大大提高WebLogic性能。

2.1.2 jRockit调优
　　jRockit支持四种垃圾收集器：分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:,对应四个收集器分其他为gencopy, singlecom, gencon以及parallel。为得到更好的响应性能，应该使用并发垃圾回收器：-Xgc:gencon，可使用-Xms和-Xmx设置堆栈的初始大小和最大值,要设置护理域-Xns为-Xmx的10%。而如果要得到更好的性能，应该选用并行垃圾回收器:-Xgc: parallel，由于并行垃圾回收器不使用nursery，不必设置-Xns。

　　如果你的线程大于100或者在linux平台下，可以尝试使用瘦线程模式：-Xthinthread,同时关闭Native IO:-Xallocationtype:global。

　　jRockit 还提供了强大的图形化监控工具Jrockit Management Console。欲详细了解JRockit可访问：http://edocs.bea.com/wljrockit/docs81/index.html。

2.2 Server调优
　　WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。当有一个请求出现在执行队列中时，就会有一个空闲的执行线程从该队列中取走发来的该请求，并返回应答，然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发。

2.2.1 尽量使用本地I/O库
WebLogic Server有两套套接字复用器：Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。

2.2.2 调整默认执行线程数
　　理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000，则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小。

2.2.3 调整连接参数
　　WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。

2.2.4 创建新的执行队列
　　创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里优先级不应设为9或者10。定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后，用户需要为应用程序的J2EE组件配置分配策略，以便它可以找到新的队列。举个例子：要将servlet或jsp捆绑到一个特定的执行队列，必须替换web.xml文件项，将wl-dispatch-policy初始化参数设置为自己的执行队列名。

servletname

/directoryname/deployment.jsp

wl-dispatch-policy

NewExecuteQueueName

　　我们可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB,建议使用自己的执行队列。

2.3 JDBC调优
2.3.1 调整连接池配置
　　JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

　　增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

　　尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

　　最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

2.4 WEB调优
2.4.1 调整WEB应用描述符
　　WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。同时生产环境下无需检查Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSPKeep Generated 和JSPVerbose对性能也有帮助。此外，还可以对jsp进行预编译,有两种方法：激活precompile选项；使用weblogic.appc事先编译，建议采用后者。

2.5 JMS调优
　　1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在jRockit上增加-XXenablefatspin以减少加锁冲突;
　　2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
　　3. 使用分布式目的地时,激活连接工厂Load Balancing Enabled ,Server Affinity Enabled;
　　4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下，则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置；
　　5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enabled和Bytes Paging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
　　6. 在运行WebLogic Server进程之外的生产者务必使用流控制, 并增大Send Timeout;
　　7. 将JMS Server Expiration Scan Interval设很大的值，能禁止主动扫描过期消息;
　　8. 使用FIFO或者LIFO方式处理目的地消息;
　　9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。

2.6 EJB调优
2.6.1 调整pool和cache
　　initial-beans-in-free-pool定义SLSB启动时实例的个数,默认为0,可以调大到正常并发数的大小,以减少初始响应时间。max-beans-in-free-pool为最大个数,默认1000对SLSB来说,在频繁创建和删除实例的情况下很有帮助,一般不用调整,至少设为默认线程数,过大容易造成内存溢出。而对Entity Bean来说,由于是匿名的,所以当频繁使用finder、home和create方法时可以调大。

　　对SFSB来说,尽量将max-beans-in-cache参数设置得足够的大，以满足Bean实例对最大并发用户数的要求，可以避免有状态会话Bean过多的钝化行为。而idle-timeout-seconds尽量设置小,如果SFSB不用于存储Web应用会话状态可以设置为0。

　　对于Entity Bean来说, max-beans-in-cache同样可以首先采用默认值1000，监控实例缓存和钝化的情况,再做适当调整。

　　并行策略concurrency-strategy定义了实体Bean如何管理锁,有四种策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,尽量避免使用互斥策略,如果Bean无需更新操作,使用只读策略,更甚的是,如果Bean的内容不会改变,可设置read-timeout-seconds为0,乐观并行策略时采用事务间缓存策略,在entity-cache描述符中将cache-between-transactions元素设为true。

2.6.2 优化事务隔离级别和事务属性
　　对EJB组件来说，有四种事务隔离水平：
TRANSACTION-SERIALIZABLE：在处理完成之前拒绝其他处理的读入、可扩展性或插入数据操作;
TRANSACTION-REPEATABLE-READ：防止处理修改正在被其他处理调用的数据;
TRANSACTOIN-READ-COMMITTED：防止对正在被其他处理修改的数据执行写锁定；
TRANSACTION-READ-UNCOMMITTED：允许处理读入未受权的数据以及允许在向结果中添加记录时可以忽略处理。

　　以上隔离水平依次降低,效率和性能依次提高。因此,建议选用满足在业务数据完整性要求前提下水平最低的隔离级别。

　　对于事务属性的设置也是如此,对于删除、修改和插入操作设置为Required,而对于只读操作设置为Supports或者NotSupports。

2.6.3 其他一些小技巧
　　1. 利用finders-load-bean的默认值true，既可以避免“n+1”的查询问题，又可以提高系统的性能;
　　2. 使用delay-updates-until-end-of-tx参数的默认值true，除非应用程序对某些变化有特别的要求;
　　3. 应用程序在每个业务方法调用后不需要进行存在性检查，将check-exists-on-method设定为false，以提高程序的性能;
　　4. 同一应用内, 将enable-call-by-reference设置为 true;
　　5. reentrant设置为false,避免事先加载子数据。

第三章数据库调优(目录)
3.1.1 Oracle性能优化
　　Oracle9i的性能优化除了调整kernal之外就是主要对Oracle启动文件的调整,即调整SGA的参数。注意,不同操作系统不同位数的机器最优的参数不是一样的,这里主要有windows和unix之分,32位和64位之分。
首先需要调大进程数和游标数,一般默认的值对实际应用来说都比较小,比如说,进程数可以调到300,游标数可以调到500。

　　其次,看一个经验公式: OS 使用内存+ SGA + session*(sort_area_size + hash_area_size +2M)<0.7RAM,通常认为此时的SGA比较合理。这里sort_area_size为64k, hash_area_size为128k(当排序多的时候需要增大sort_area_size,按调整后的值计算),session表示最大并发进程数,假设100个。假如1G内存的机器,OS占用200M,PGA占用200M左右,那么SGA可以设为400-500M，如果2G内存可以1G给SGA，8G可以5G给SGA。不过对于32位数据库来说，通常最多只能使用1.7G内存。

　　然后，SGA内参数设置的基本原则是：data buffer 通常可以尽可能的大，shared_pool_size 要适度，log_buffer 通常大到几百K到1M就差不多。具体的：data buffer 1G内存可以设置500M，2G设为1.2G，8G可设为5G 。shared_pool_size不易过大，通常应该控制在200M--300M,如果使用了大量的存储过程，可以根据SGA的值增大到500M，如果增大后命中率得不到提高，则增加是无益的。具体的：1G内存可以设置100M，2G设为150M，8G可设为300M。如不使用Java，java_pool_size 10-20M即可。large_pool_size如果不设置MTS，在20M -30M 即可，假如设置 MTS,可以考虑为 session * (sort_area_size + 2M)。

　　最后，关于内存的设置可根据statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息来考虑微调。

3.1.2 Oracle的其他调整
　　为了Oracle高效率的运行，除了上面提到的内存因素之外，还有就是需要良好的数据库设计：表、视图、索引和日志的合理规划和建立。I/O的性能也是重要因素，应尽量减少页交换和页分配。此外，就是改善检查点的效率。

第四章操作系统调优(目录)
4.1 操作系统调整
　　操作系统影响应用程序运行性能的因素主要有：硬件的配置(CPU、内存、硬盘等),核心参数,TCP/IP参数以及补丁的情况等。这里对操作系统的优化,除了更新最新的补丁程序以保证应用程序正常运行之外,就是调整TCP/IP参数,文件描述符,对于个别操作系统还有其他特别的参数调整。下面将依次介绍不同操作系统的情况,更多的信息请参考各操作系统的文档。

4.1.1 HP-UX
　　对于HP-UX,你首先需要安装Java Patch:
http://www.hp.com/products1/unix/java/patches/index.html,然后需要确认下面文档中的核心参数是否满足(可以使用sam命令修改核心参数):http://e-docs.bea.com/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105。

　　调整TCP参数: ndd -set /dev/tcp tcp_conn_req_max 1024, 将侦听队列的最大允许长度调整到1024。有时操作系统限制进程使用的最大内存数小于你要配置的内存大小,则需要调整该值。

　　读者可以从http://docs.hp.com/hpux/onlinedocs/TKP-90203/TKP-90203.html了解更多的HP-UX调整建议。

4.1.2 Solaris
　　调整TCP的参数,等待时间间隔tcp-time-wait-interval建议设置为60000ms: /usr/sbin/ndd ?set /dev/tcp tcp_time_wait_interval 60000;
其他参数调整如下:

tcp_xmit_hiwat/tcp_recv_hiwat 131072
tcp_conn_req_max_q/tcp_conn_req_max_q0 16384

　　调整一个进程打开的文件描述符的数量:软限制和硬限制以及散列表的大小,修改/etc/system文件:

set tcp:tcp_conn_hash_size=32768
set rlim_fd_cur=8192
set rlim_fd_max=8192

更多的调整信息请查阅: http://docs.sun.com/db/doc/806-7009(Solaris9)。

4.1.3 AIX
　　AIX用no命令调整TCP参数，等待时间间隔tcp_timewait: no -o tcp_timewait=4,将tcp.timewait参数设置为4个15秒间隔，即1分钟。运行no -a命令将显示网络当前的所有属性值。由于UDP_SENDSPACE默认的缓存大小是8k,为减少I/O异常,需调整为32k:

　　no -o udp_sendspace=32768。此外, 当WebLogic HTTP请求忙时,可以调整侦听队列的最大长somaxconn到8192(默认值是1024)。

　　更多信息:http://publib16.boulder.ibmo.com/pseries/en-us/aixbman/prftungd/prftungd.htm。

4.1.4 Linux
　　调整Linux系统使用sysctl命令修改TCP参数等待时间间隔:sysctl -w ip_ct_tcp_timeout_time_wait=60;调整打开文件的最大数:在/etc/sysctl.conf文件中，添加: Fs.file-max=65535,然后运行sysctl -p;调整打开文件描述符最大数为8192:在/etc/security/limits.conf文件，添加:WebLogic hard nofile 8192(仅针对WebLogic用户),然后在WebLogic启动文件里运行ulimit-n 8192激活设置。

更多信息请查阅:http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html。

4.1.5 Windows
　　Windows系统的调整通过修改注册表HKEY-LOCAL-MACHINESYSTEMCurrent ControlSetServices文件夹来完成。可以调整TcpipParameters子文件夹中的等待时间间隔时间TcpTimedWaitDelay参数的值。侦听队列最大长度的默认值为15，为修改它，可在InetinfoParameters子目录中创建DWORD条目ListenBackLog。
此外,Windows2000的Service Pack(要求sp3以上)也会影响系统稳定性: http://e-docs.bea.com/platform/suppconfigs/configs81/win2ksvr_as_data_pentium/81sp3.html。

第五章性能监控和性能分析(目录)
5.1 性能瓶颈
　　最后,介绍一下实际分析J2EE应用性能的常用命令和工具。对于实现一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的。掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源。在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决。瓶颈会发生在Web服务器上，程序代码中，应用服务器上，数据库，操作系统或者网络，硬件上。经验表明，瓶颈很容易发生在如下地方：数据库连接与队列中；应用服务器的程序代码中；应用服务器和Web服务器硬件上；网络和TCP配置中。实际中可以着力对这些环节进行监控。

5.2 操作系统监控
　　操作系统层面的性能监控主要是对内存、CPU、I/O和交换区的使用情况进行监控分析。windows平台可以通过任务管理器和perfmon工具查看。如果是unix系统可以使用stat系列命令(vmstat, mpstat, iostat)监控内存、CPU和I/O的即时变化,使用swap命令查看交换区的使用情况。如果操作系统安装了top、topas、glance等使用工具,则使用top、topas、glance将能更为方便地看到WebLogic进程对操作系统的内存,CPU和I/O资源使用的即时变化情况。

　　而网络方面的性能可以通过ping和netstat等命令来监控,主要几个关键的网络统计值,如数据包再发送、重复数据包和数据包侦听丢失。

　　说明:本文提到的unix命令并非适用所有操作系统,仅供参考。

5.3 数据库监控
　　数据库层面的监控这里为oracle9i为例来说明,可以采用oracle自带的工具Oracle
Interprise Manager Console来监控session和sql的执行情况。还有其他专业的数据库监控工具可以使用,比如QUEST的spotlight(http://www.quest.com/spotlight-portal/)可以非常形象和直观地对Oracle数据库的CPU、内存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等参数进行即时监控,并自动对不正常的参数以红色显示。

5.4 WebLogic监控
5.4.1 JVM监控
　　采用java参数-verbose:gc 来分析JVM的GC非常繁琐，而且不直观。使用-Xloggc:gc.log 参数将GC日志写入文件,采用GC 工具HPjtune (http://www.javaperformancetuning.com/tools/hpjtune/index.shtml)进行分析,可以轻松看出当前jvm参数配置是否合理。

　　严格意义上来说HPjtune是一个分析工具,不是监控工具。这里不得不提及jRocket,Intel平台上最快的JVM, 在WebLogic启动命令中增加-Xmanagement参数,就可以执行beajrockit81sp3_142_04in下console命令监控WebLogic的内存使用和CPU负载情况。设置Tools/Preferences菜单中的Mode of operation属性为developer, jRocket将提供Method Profiler工具，她能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，进行代码级调优，这是jRockit的又一大优势。

5.4.2 Console监控
　　WebLogic Console除了管理配置功能之外,提供了丰富的监控功能。通过WebLogic Console，首先我们可以查看服务器的运行情况。

5.4.2.1 Server监控
　　通过使用服务器的Performance Monitoring选项卡，可以查看到请求吞吐量，执行队列积压情况以及JVM栈利用情况。而通过点击Performance Genaral选项卡中” Monitor all Active Queues...”可以查看所以执行线程的当前统计数据。此外Monitoring选项卡还可以监控JTA和JMS等Service的情况。

5.4.2.2 JDBC监控
　　在连接池Monitoring选项卡中，WebLogic Console为每一个数据库连接池提供了实时统计信息。其中有三个重要参数可以反应WebLogic Server的健康状况：Connections High、Wait Second High和Waiters High。Connection High表示从服务器启动开始后到达池的最大连接数量，如果大于池的最大数量，则需要调整Maxium Capacity。Waiters High表示在没有可用连接的情况下，应用程序等待连接的最大个数。我们可以根据Waiters High的大小调整连接池容量。更多的参数可以通过Customize this view链接添加,参数含义参考:http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_monitor.html#1104829。

5.4.2.3 WEB监控
　　Web Application Monitoring选项卡可以监控WEB应用的Session个数,以及Servlet的响应情况,激活Session Monitoring Enabled可以获取所有session的统计情况。更多信息请参考:
http://e-docs.bea.com/wls/docs81/ConsoleHelp/web_applications.html#1106723。

5.4.2.4 JMS监控
　　Welogic Console JMS监控功能比较多,不仅在Server JMS Monitoring选项卡可以监控Active JMS Connections, Pooled JMS Connections和Active JMS Servers的连接和使用情况。还可以监控JMS Session Pool、Active JMS Destinations和Durable Subscribers的消费和生产情况。比如,我们可以监控到JMS Queue的接收和消费消息的数量和字节数。有关JMS监控的详细情况可参见:http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_monitor.html。

5.4.2.5 EJB监控
　　EJB监控包括对SLSB,SFSB,Entity Bean,MDB四种EJB的监控。本人认为EJB监控提供了非常丰富的运行时统计信息(http://e-docs.bea.com/wls/docs81/ConsoleHelp/ejb.html#1105036),非常有利于我们对EJB进行性能调优。

　　SLSB选项卡为用户提供实例池的运行时统计信息。Pool Miss Ratio 表示实例池的Miss率,Pool Waiter Total Count 表示线程等待bean 实例的累计时间,Pool Timeout Total Count表示超时的线程数。当Pool Miss Ratio较大时,可以增加max-beans-free-pool。

　　SFSB可以关注Cache Miss Ratio和Activation Count。Cache Miss Ratio过大时,调大max-bean-in-cache未必有帮助,需要尝试不用的max-bean-in-cache以获得最低的Cache Miss Ratio。激活将严重减慢应用程序的速度,如果某一个bean的Activation Count的值过高，那么需要考虑增加max-bean-in-cache的大小。
Entity Bean结合了SLSB的free pool和SFSB的cache。可以结合上面的策略进行监控。

　　而MDB仅比SLSB多一个参数JMSConnection Alive,报告EJB是否成功连接到JMS目的地。

更多Console监控信息可参见http://edocs.bea.com/wls/docs81/ConsoleHelp/index.html。

5.4.3 实用工具分析
　　WebLogic除了提供Console进行应用监控之外,用户还可以编写JMX程序或者通过SNMP协议进行监控。而QUEST Spotlight for WebLogic Server提供了类似WebLogic Console类似的监控功能,并对异常情况显红。
这里不得不提到实战中经常用来分析性能瓶颈的工具THREAD DUMP,统一的命令是使用 weblogic.Admin 命令 THREAD_DUMP。而在 windows上还可以使用+ 来创建诊断问题所需的线程转储Thread Dump,而在unix上使用kill -3 命令。我们从中可以看到WebLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦。

5.5 应用程序分析
　　应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borland Optimizeit Enterprise Suite和QUEST Jprobe两个产品可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等。Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。

　　而Borland Optimizeit Server Trace,HP OpenView Transaction Analyzer和Mercury LoadRunner J2EE breakdown都可以用来分解J2EE应用从客户端访问到最终数据库操作每一层次花费的时间,甚至精确到每一个方法的执行时间。Server Trace还具有检查内存泄漏，连接泄漏和错误警告等功能,一般在测试环境中使用。而HP OTVA的优势在于运行时监控,LoadRunner优势在于压力测试。

总结(目录)
　　J2EE调优是一门实践和经验科学，是一个复杂而往复的过程。其原则是：合理。合理,看似简单,细细品味,意味深长。本文所述的调优策略并不是一成不变的，只是为了给大家一个参考建议，让大家少走弯路，关键是根据实际环境调优。欢迎有兴趣的朋友在论坛上积极讨论和批评指正。

参考文献(目录)
[1]BEA WebLogic Server edocs: http://e-docs.bea.com/wls/docs81/perform/index.html
[2]Gregory Nyberg & Robert Patrick :Mastering BEA WebLogic Server
[3]Jack Shirasi:Java Performance Tuning

关于作者(目录)
周海根(dev2dev ID:zhouhg) 合力思软件(中国)有限公司技术顾问，BEA Certified Specialist，BEA dev2dev撰稿人。多年从事J2EE开发工作，目前致力于技术支持工作，主要研究J2EE技术在WebLogic上的应用、调优。有着西电人的务实，喜欢专研技术，是个体育狂热者。
联系方式: 010-85251858-1053,zhouhaigen@hotmail.com
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Weblogic调优（转）

e-ant — Wed, 23 Jul 2008 09:39:02 +0800

作者: e-ant 链接：http://e-ant.javaeye.com/blog/218464 发表时间: 2008年07月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Weblogic调优
原文：http://blog.163.com/sjlksoft@126/blog/static/4001823120085523215502/

1、最近我在帮助一个客户对应用程序进行性能调优，该应用程序的CPU占用量高得不可思议。他们计划从另一种产品迁移到WebLogic Express上，但是令他们吃惊的是，WebLogic Express下的CPU占用量要远远高于他们原本使用的产品。

我们以优先级的顺序列出了各种性能调优参数，试图解决问题。列在上面的是我所认为的简单参数。对于这些参数，我们公认应该设一个特定的值为最大值，而不会造成任何可能的负面影响。头两个参数是pageCheckSeconds和servlet-reload-check-secs。它们的默认值是1，这表示WebLogic每一秒钟都针对每个JSP页面和servlet进行检查，看是否有新的版本。这在开发时是一个很好的设置，但是在生产中，如果系统有大量的JSP页面和servlet，这将会造成巨大的开销。

如果您的生产系统从来不动态更新JSP页面和servlet的话，这两个参数应该设置为 -1，这表示WebLogic从不检查新页面。如果您需要更改JSP页面和servlet的话，可以将这两个参数设置为一个比较大的数，比如180，以减少检查新版本对系统的影响。

将客户机应用程序的这两个参数设为 -1可以使CPU占用量减少一半。只需更改一下参数，就可以获得巨大的好处，的确是一种非常简单的性能优化方法。

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

优化WebLogic 服务器性能参数

WebLogic 配置文件（config.xml）包含了大量很直观的与性能有关的参数，能通过配置环境与应用程序得到很好的优化。基于系统的需要调整这些参数不仅能改善单个点的性能，而且能提高整个应用程序性能的可衡量性。

试着采用下列WebLogic配置方法，或许能使你的系统达到最佳状态：

一修改运行队列线程数的值。在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。当任务加入一个WebLogic 实例，它就被放到执行队列中，然后分配给任务一个线程来运行。线程消耗资源，因此要小心处理这个属性——增加不需要的值，会降低性能。

二，如果可能，使用自带的性能包（NativeIOEnabled=true）。

三，使用特定的应用程序执行队列。

四，使用JDBC连接池时，修改下列属性：

n 驱动名称：使用小的驱动或者jDriver。

n 初始容量：设为与最大容量相同的值。

n 最大容量：其值至少应与线程数相同。

五，把连接池的大小设为与执行队列的线程数相同。

六，设置缓冲。

七，为Servlet和JSP使用多个执行队列。

八，改变JSP默认的Java编译器，javac 比jikes或sj要慢。

优化WebLogic

提要：

n 为WebLogic启动设置Java参数。

n 设置与性能有关的配置参数。

n 调整开发与产品模式默认值。

n 使用WebLogic“自有的IO”性能包。

n 优化默认执行队列线程。

n 优化连接缓存。

n 如何提高JDBC连接池的性能。

n 设置Java编译器。

n 使用WebLogic集群提高性能。

n 监视WebLogic域。

一、为WebLogic启动设置Java参数

只要启动WebLogic，就必须指定Java参数，简单来说，通过WebLogic.Server域的命令行就可以完成，不过，由于这样启动的过程冗长并且易于出错，BEA 公司推荐你把这个命令写进脚本里。为了简化这个过程，你可以修改样例脚本里的默认值，样例脚本是提供WebLogic启动服务器的。

如果你用配置向导创建你的域，WebLogic启动脚本（startWebLogic.cmd）放在domain-name目录里。默认情况下，这个目录是BEA_HOME\user_projects\domain\domain-name，BEA_HOME表示安装路径，domain-name是在配置模板中设置的域名称。

你需要在这个脚本中修改一些默认的Java参数值，使之适合你的应用环境和程序。在这个文件中主要的性能参数是JAVA_HOME和Java堆的大小。

n 设JAVA_HOME的值为JDK所在的位置，如：

set JAVA_HOME=C:\bea\jdk141_03

n 为得到高性能的吞吐量，把Java堆的最小值与最大值设为相等。如：

"%JAVA_HOME%\bin\java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -

二、设置与性能有关的配置参数

在一个WebLogic域中，配置文件（config.xml）位于与管理服务器通信的机器里，提供WebLogic MBean的长期存储。管理服务器作为连接的中心点，为服务实例与系统管理工具提供服务。域也可以包括其他的WebLogic实例，称之为从服务，主要为应用程序提供服务。

当启动管理服务器是，首先读域配置文件，然后跳过建立在配置文件中管理MBean 默认的属性值，每一次用系统管理工具（不管是命令行界面还是管理控制台）改变一个属性值，它都会被存到相应的管理MBean，并且写进配置文件。

下表列出了config.xml文件中影响服务器性能的参数。

元素

属性

控制台标签

备注

Server

NativeIOEnabled

Native IO Enabled

ExecuteQueue

ThreadCount

Thread Count

ExecuteQueue

QueueLength

QueueLengthThresholdPercent

ThreadsIncrease

ThreadsMaximum

ThreadPriority

Queue Length

Queue Length Threshold Percent

（队列长限度百分比）

Threads Increase

Threads Maximum

Thread Priority

Server

StuckThreadMaxTime

StuckThreadTimerInteral

Stuck Thread Max Time

（堵塞线程的最长时间）

Stuck Thread Timer Interval

（堵塞线程的时间间隔）

Server

ThreadPoolPercentSocketReaders

Socket Readers

Server

AcceptBacklog

Accept Backlog

（接受缓存数）

JDBCConnectionPool

InitialCapacity

MaxCapacity

Initial Capacity

Max Capacity

JDBCConnectionPool

StatementCacheSize

Statement Cache Size

(声明高速缓冲大小)

三、调整开发模式与产品模式默认值

你可以指定域为开发环境或为产品环境。WebLogic会根据你指定的环境类型使用不同的默认值提供不同的服务。

下表列出了两种模式下的默认值

优化参数

开发模式

产品模式

Execute Queue: ThreadCount

15 threads

25 threads

JDBC Connection Pool: MaxCapacity

15 connections

25 connections

3．1更改运行时模式

在创建了一个域后，按下列步骤可以更改域里所有服务的的运行时模式：

1．为更改运行在一个WebLogic主机上的所有域的运行时模式，用文本编辑器打开WL_HOME\common\bin\commEnv.cmd(Windows) 或者WL_HOME\common\bin\commEnv.sh (UNIX)，WL_HOME是安装WebLogic的路径。

为指定的域更改运行时模式，就用文本编辑器打开domain-name\StartWebLogic.cmd (Windows) or domain-name\StartWebLogic.sh (UNIX)，domain-name为创建的域的目录。

2．在这个脚本中，更改PRODUCTION_MODE的值，如果你要服务器运行在产品模式，指定其值为TRUE。

3．重启所有的服务器。

3．2两种模式的不同

下表列出了开发模式与产品模式几种关键项的区别：

功用名称

开发模式

产品模式

SSL

你可以使用WebLogic安全服务提供的验证数字证书。有这些证书，你开发的应用程序会在SSL保护的环境下运行。

如果你使用验证数字证书，会收到警告信息。

部署应用程序

WEBLOGIC实例会自动部署和更新位于domain_name/applications目录下的应用程序（domain_name为域的名称）。

不能使用自动部署功能，必须使用WebLogic控制台或者WebLogiceblogic Deployer工具。

Log File Rotation

启动服务器后，服务器自动重命名本地日志文件为server-name.log.n，为了滞留的session ，只要日志文件的达到500kb，日志文件就会滚转一次。

当日志文件达到500kb，就会滚转。

Execute Queues

默认的执行线程为15。

默认的执行线程为25。

JDBC Connection Pool Capacity

默认的容量为15。

默认的容量为25。

四、使用WebLogic“自有的IO”性能包

当你使用自有的性能包，测试基准就表明了主要性能的提高。性能包采用最优化的平台及多线程的Socket去提高服务器的性能。例如，本地Socket 读的多线程有自己的执行队列而不需要借用默认的执行队列线程，这样可以让默认执行线程很从容去处理应用程序。

不过，如果你一定要用纯Java socket读在主机上运行，你仍然可以通过配置每个服务器实例和客户机中适当的socket读的线程数量，来提高socket通信的性能。

设置性能包的操作方法：

默认情况下，装载在config.xml中的是自有的性能包。为了验证这个设置，在配置文件中检查NativeIOEnabled属性是否设为“true”（NativeIOEnabled=true）。

你也可以通过管理控制台来验证，步骤如下：

1，启动管理服务器。

2，访问管理控制台。

3，展开左边面板的Servers 节点，显示域服务。

4，点击你要配置的服务实例。

5，选择Configuration－>Tuning tab。

6，如果 Enable Native IO复选框没有被选择，选中即可。

7，点击Apply。

8，重启服务器。

五、优化默认执行队列线程

默认情况下，一个新的WebLogic实例配置了一个开发模式执行队列，weblogic.kernel.default,它包含15个线程。另外，WebLogic提供了2个预配置队列：

n weblogic.admin.HTTP——只在管理服务器上才有，这个队列供与管理控制台的通信用，你不能再配置它。

n weblogic.admin.RMI——管理服务器和被管理服务器上都有这个队列，它是供管理的交通之用，也不能再配置它。

如果你不配置额外的执行队列，并且指定应用给这些队列，web 应用程序和RMI对象就使用默认的队列weblogic.kernel.default。

注意；如果自带的执行包没有在你的平台上使用，你可能需要调整默认的执行队列线程数和担任socket读的线程的百分比，去实现最佳性能。

5．1你应该更改默认的线程数吗?

增加更多的线程到默认的执行队列并不意味着你能处理更多的工作。即使增加更多的线程，仍然被处理器的能力限制。因为线程消耗内存，所以增加线程数属性的值不必要的降低了性能。一个高的执行线程数导致更多的内存被占用并且增加了上下文转换程序，它也会降低性能。

线程数属性的值与应用程序处理的工作的类型关系密切。例如，如果你的客户应用程序比较小，通过远程调用处理的工作较多，这样，客户端会花费更多的时间连接，因此，与能完成大量客户端任务的客户应用程序相比，会需要更多的线程数。

如果你的工作不需要使用超过15个线程（开发模式默认）或者25个线程（产品模式默认），就不要改变这个属性的值。通常，如果你的应用程序访问数据库花很长时间才返回结果，与访问数据库很短时间就返回的应用程序比较，你会需要更多的执行线程。从后者来看，用少点的线程数可能提高性能。

5．2需要修改默认线程数的情形

为了给执行队列决定一个理想的线程数，当队列中所有应用程序都运行在最大负荷的情况下，监视队列的吞吐量。增加线程数，重复负载测试，直到达到最佳的吞吐量。（在某些情况下，增加线程数将产生足够多的上下文转换程序，使得队列中的吞吐量开始减少。）

注意：WebLogic管理控制台显示的是所有服务器执行队列累积的吞吐量。为了得到这个值，后面将会介绍。

下表列出了在WebLogic 域中调整的线程及与CPU数量相关的情形，这些情况也假定WebLogic运行在最大负荷下，并且使用默认的执行队列满足所有的线程的请求。如果你配置了额外的执行队列并指派了应用程序到具体的队列，就需要依据一个个连接池得到结果。

如果…

结果

应该：

线程数

线程数太少，如果：

CPU正等着工作，但有工作被完成。

CPU利用率不能达到100％。

增加线程数。

线程数＝CPU的数量

理论上理想，但是CPU仍然低利用。

增加线程数。

线程数（适当的）>CPU的数量

实际中理想，有个适当的上下文转换程序数量和高的CPU利用率。

调整适当的线程数并且比较性能结果。

线程数（较大的）>CPU的数量

过多的上下文转换程序，能导致重大的性能降级。

当你降低线程数时，性能可以增强。

减少线程数，使它等于CPU的数量，然后仅仅增加已经得出的“堵塞”线程的数量。

例如，如果你有4个处理器，它们都同时运行，并出现堵塞线程，于是，你想要的执行线程就是4＋堵塞线程的数

5．3修改默认线程数的步骤

用管理控制台修改默认执行队列线程数如下：

1．如果管理服务器没有运行，先启动。

2．访问管理控制台。

3．展开左边面板的Servers 节点，显示域服务。

4．右击服务名称，在弹出菜单中选择View Execute Queues ，就会在右边面板显示有执行队列的表用来修改。

注意：你只能修改默认的执行队列或者用户定义的执行队列。

5．在Name列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。

6．填下适当的线程数。

7．点击Apply，保存刚才的修改。

8．重启服务器，使新的执行队列设置生效。

5．4指派应用程序到执行队列

虽然可以配置默认的执行队列，为所有的WebLogic应用程序提供最佳的线程数，但是为关键的应用程序配置多个执行队列可以提供更多的管理控制。通过使用多执行队列，你可以保证应用程序有权占用固定的线程数，而不管WebLogic服务器有多大的负荷。

5．5创建执行队列

一个执行队列代表执行线程的命名集，线程指向一个或多个Servlet、JSP、EJB、RMI对象。执行队列在config.xml文件中描述，作为服务器元素的一部分。如，在config.xml文件中描述一个有4个线程的队列，命名为CriticalAppQueue，如下：

...

Name="examplesServer"

ListenPort="7001"

NativeIOEnabled="true"/>

ThreadCount="15"/>

ThreadCount="4"/>

...

另一种创建队列的方法是通过管理控制台，配置步骤如下：

1．启动管理服务器，访问控制台。

2．展开左边面板中Servers节点，显示域中要配置的服务。

3．右击你要增加队列的服务实例，从弹出菜单中选择View Execute Queues。

4．在队列配置标签中，点击配置新执行队列链接。

5．在队列配置标签中，更改下列属性或接受系统的默认值：

n 线程名称（Name）：你可以输入线程名称，如CriticalAppQueue。

n 队列长度(Queue Length)：通常保留默认值65536，队列长度表明了同时发来请求的最大数，65536个请求是个很大的数，即使达到这个最大数，也是很少见的。

如果达到最大队列长度，WebLogic会自动成倍增长队列大小，以处理额外的工作。

注意：超过65536个请求预示队列中的线程有问题，不仅仅只是队列本身的长度问题，实践表明在队列中有堵塞线程或线程数不足的情况存在。

n 队列长限制百分比（Queue Length Threshold Percent）：达到队列长度百分比（1－99）时，就构成了溢出条件的产生。实际队列大小在限制的百分比之下时才被认为是正常的；在限制百分比之上就会产生溢出。当出现溢出，WebLogic日志就会产生一个错误消息，并且按线程数增量（Threads Increase）属性的值增加线程数，以帮助减少负载量。

默认的队列长限制百分比为90％。一般情况下，应保留90％或其左右，以应对一些潜在的情况，使得有额外的线程可以去处理一些请求中的异常。记住，队列长度限制百分比不是一定作为自动优化参数――因为正常运作情况下，这个限度从不会被触发。

n 线程数（Tread Count）：指派到这个队列的线程数。如果你不需要使用超过15个线程（默认），就不必更改这个属性值。

n 线程数增量（Threads Increase）：是指WebLogic探测到有溢出时，增加到执行队列的线程数。当你指定为0（默认），出现溢出时，WebLogic会把运行良好状态改为“警告”，而且也不会指派额外的线程去减少负荷量。

注意：如果WebLogic实例的线程数响应了溢出，那么这些额外的线程就会滞留在执行队列，直到服务器重启。监视错误日志，以判断溢出产生的原因，以便根据需要重配置线程数，防止以后类似情况产生。不要同时使用线程数增量和队列长限制百分比作为自动优化的手段。如此做通常结果会产生比正常需要还多的线程被指派到执行队列，这样上下文转化程序的增多会使服务器遭受很差的性能。

n 最大线程数：是指执行队列中能运行的，这个值保护WebLogic为了响应频繁溢出，创建过多的线程数。默认情况下，最大线程数为400。

n 线程优先级：线程优先级与此队列相关。默认值为5。

6．点击Create，创建队列。

7．重启服务器。

5．6指派Servlet和JSP到执行队列

你可以把servlet或JSP分配到指定的配置执行队列，只需在初始参数中标识执行队列的名称。初始参数出现在Servert或JSP的部署描述文件web.xml中的init-param元素里。为了分配一个队列，可以把队列名作为wl-dispatch-policy参数的值。如：

MainServlet

/myapplication/critical.jsp

wl-dispatch-policy

CriticalAppQueue

5．7指派EJB和RMI对象到执行队列

为了把EJB分配到指定的队列，可以使用weblogic-ejb-jar.xml文件中dispatch-policy元素。

然而你也可以通过使用appc编译器－dispatchPolicy选项来设置派遣策略，BEA强烈推荐使用部署描述元素。因为用这种方式，如果EJB重编译，在部署用例期间，这个设置不会被丢失。

为了把RMI对象分配到指定的队列，可以使用rmic编译器的－dispatchPolicy选项，如：

java weblogic.rmic -dispatchPolicy CriticalAppQueue ...

5．8分配执行队列担任Socket读

为了获得更好的socket性能，BEA 推荐你使用自有的socket读执行工具，它更优于纯Java执行工具。然而，如果你一定要在主机上用纯Java 的socket读，你仍然可以通过配置恰当的执行线程数以提高socket通信性能，为每个服务器实例和客户机器担负socket读线程的任务。

Socket读占线程池百分比（ThreadPoolPercentSocketReader）属性可以设置用来从socket读消息的执行线程的最大百分比。这个属性的最优值是根据应用程序的需要指定的。默认值是33，有效范围在1－99之间。

分配执行线程担任socket读增加了服务器处理速度和接受客户请求的能力。有必要平衡执行线程数，使其专注于从socket读消息，也有必要平衡那些在服务器处理实际任务的执行线程。

5．9为服务器实例设置socket读的线程数的操作

1．启动管理服务器，访问域控制台。

2．展开左边面板Servers节点，显示域服务配置。

3．点击你要配置的服务名称。

4．选择配置（Configuration）――>调整（Tuning）标签。

5．在Socket Reader中编辑Java读线程的百分比。Java socket读线程数是根据所有的执行线程数的百分比计算得到的。

6．应用（Apply）这个调整。

5．10在客户机设置Socket读线程数

在客户机上，你可以配置运行在JVM（Java虚拟机）上的socket读线程数。指定Socket读，需要通过用java命令行定义下列参数：

-Dweblogic.ThreadPoolSize=value

-Dweblogic.ThreadPoolPercentSocketReaders=value

5．11优化溢出情况时的执行队列

你可以配置WEBLOGIC监测并且随时应对潜在的溢出，不管其发生在默认的执行队列还是用户定义的队列。一旦当前队列大小快达到用户定义的百分比，WebLogic认为队列中有一个可能的溢出产生。

当这个限度到达时，服务器改变它的良好状态为“警告”，随即分配额外的线程去处理超负荷的工作，从而还原它的大小。

为了自动监测和应对溢出，你可以配置以下项：

1．队列长限制百分比，这个值是队列大小的百分比。

2．当溢出发生时，增加到队列的线程数。这些额外的线程以还原队列到正常的运行的大小。

3．线程的最大数，在特殊情况下，线程最大数用来保护服务器在响应过载情况下过度分配线程数。

5．12优化执行队列的监测行为

当一个线程在队列中变成堵塞状态时，WebLogic会自动监测到。因为堵塞线程不能完成它当前的工作或接受新的工作，服务器每次诊断一个堵塞线程，就记入一个消息到日志中。如果一个队列中所有的线程变成堵塞，服务器改变良好状态成“警告”或者“危机”，依赖于下列情况：

n 如果默认队列中所有的线程变成堵塞，服务器状态变成“危机”。（你可以设立节点管理器（Node Manager）应用去自动关闭及重启服务器。）

n 如果在weblogic.admin.HTTP, weblogic.admin.RMI或用户定义的队列中所有线程变成堵塞，服务器状态变成“警告”。

WebLogic诊断到一个堵塞线程，如果它是在指定的时间内连续不断的工作（没有空闲）。你可以调整服务器线程监测行为，它是通过改变堵塞线程被诊断前的时间长度和服务器核查堵塞线程的频率。

注意：尽管你能改变标准WebLogic去决定一个线程是否堵塞，但，你不能改变默认行为，就是出现堵塞时把服务器设置成“警告”或“危机”的行为。

配置WebLogic堵塞线程监测行为的步骤：

1．启动WebLogic，访问管理控制台。

2．点击你想为改善堵塞线监测而修改的服务器实例的名称。

3．选择配置（Configuration）――>调整（Tuning）标签。

4．修改下列参数：

n 堵塞线程最大时间（Stuck Thread Max Time）：输入秒数，线程一定是不断的运行，服务器才会诊断这个线程作为堵塞。默认情况下，WebLogic认为线程连续不断运行600秒后置为堵塞。

n 堵塞线程时间间隔（Stuck Thread Timer Interval）：输入秒数，这个时间是WebLogic周期性的扫描线程以察觉它们是否连续不断运行了某一线程的时间达到通过堵塞线程最大时间属性指定的时间长度。默认时间间隔为600秒。

5．应用（Apply）设置。

6．重启服务器。

六、优化连接缓存

Config.xml文件中的元素接受缓存数（AcceptBacklog）属性是用来设定请求WebLogic实例的连接数，在拒绝额外的请求之前，能接受设定的缓存数。AcceptBacklog属性指定有多少TCP连接缓存在等待队列，这个固定的队列存放了TCP堆栈已经收到但应用程序还没有收到的连接请求。默认值是50，最大值由操作系统决定。

在控制台调整接受缓存数的步骤：

1．启动WebLogic，访问控制台。

2．展开左边面板Servers节点。

3．点击你要配置的服务器实例的名称。

4．选择配置（Configuration）――>调整（Tuning）标签。

5．根据需要修改默认的接受缓存数（Accept Backlog）：

n 在运行期间，如果许多客户端连接得不到响应或被拒绝，并且服务器端也没有错误消息，说明接受缓存的值可能太小。

n 在你访问WebLogic时，如果收到“拒绝连接（connection refused）”的提示，则应该增加接受缓存的默认值的25％。继续增加其值的25％，直到停止出现这样的提示。

6．点击应用（Apply），保存设置。

七、如何提高JDBC连接池的性能

创建一个带DBMS的JDBC连接是非常慢的。如果应用程序需要数据库不断的连接和断开，这种创建方式会造成一个重大的性能问题。WebLogic连接池提供了一种高效的解决方案来解决这个问题。

当启动WebLogic，就打开连接池，以便于所有客户连接。当一个客户关闭一个连接，这个连接就返回到连接池，供其他的客户使用。连接本身不会关闭。如此就用极少的代价实现了连接和断开连接池。

在连接池里应该创建多少连接呢？连接池会根据配置参数中的最大数与最小数之间增加或减少连接。最好的性能应该是连接数与当前客户会话（Session）数相同。

7．1调整JDBC连接池的初始容量

在配置连接池时， JDBCConnectionPool元素中的InitialCapacity属性能设定连接数，创建物理的数据库连接。如果服务器不能创建这个连接数，连接池的创建就会失败。

在开发期间，为了使服务器启动更快，可以很方便的设置InitialCapacity属性的值小一点。在产品系统中，就应该把InitialCapacity的值设为与MaxCapacity值相同，默认产品模式的值为25。这样，在服务器启动时，所有的连接就会被创建。如果你调整了MaxCapacity值后，一定要确信InitialCapacity值设置与MaxCapacity值相同。

如果InitialCapacity比MaxCapacity值少，当负荷增加时，服务器需要创建额外的数据库连接。当服务器处于低负荷时，所有的资源应该是尽快的完成请求，而不是创建新的数据库连接。

7．2调整JDBC连接池的最大容量

JDBCConnectonPool元素中的MaxCapacity属性设置连接池包含的最大的物理数据库连接数。不同的JDBC驱动程序和数据库服务器可能限制物理连接数。

默认的最大容量数与默认的线程数相等：开发模式为15，产品模式为25。不过，在产品模式下，建议连接数与当前的客户会话（Session）数相等。在服务器端，连接池的容量与执行线程数是无关的，正在进行的用户会话比执行线程更多。

八、设置Java编译器

编译JSP Servlet的标准Java编译器是javac。你可以把java编译器设置为si或jikes代替javac，这样能极大的提高性能。下面讨论设置步骤及其要考虑的事项。

8．1通过控制台改变编译器

1．启动服务器，访问控制台。

2．展开左边面板Servers节点。

3．点击要配置的服务器实例的名称。

4．选择配置（Configuration）――>常规（General），在Java Compiler编辑框输入编译器的完全路径。如：c:\visualcafe31\bin\sj.exe

5．点击高级选项（Advanced Option）――>Show，显示其他的属性。

6．用添加（Append）把完全路径通过Classpath框输入到JRE rt.jar 库。如：BEA_HOME\jdk141_02\jre\lib\rt.jar

7．点击应用。

8．重启服务器。

8．2在Weblogic.xml文件中设置编译器

n 使用compileCommand参数指定Java编译器。

n 使用procompile参数配置WebLogic，在启动WebLogic时预编译JSP。

8．3编译EJB容器类

使用Weblogic.appc的功能去编译EJB2.0和1.1容器类。如果编译Jar文件部署EJB容器，你必须使用weblogic.appc生成容器类。默认情况下，EJB使用javac编译器。为了得到跟好的性能，使用－compiler标志指定不同的编译器（如Symantec公司的sj）

8．4在UNIX环境下编译

在UNIX机器上编译JSP文件，如果收到下列错误消息：

failed：java.io.IOException:Not enough space

试试下列一些或所有的解决方法：

n 如果你只有256MB的内存，增加更大的内存。

n 提高文件描述文件的限制，如：

set rlim_fd_max=4096

set rlim_fd_cur=1024

n 启动JVM时，用－native标志来使用自有的线程。

九、使用WebLogic集群提高性能

WebLogic集群是指一组WebLogic实例在一起提供具有防过载和自有复制的功能，以用一个域为所有客户支持可伸缩的高可用性运行。集群对于客户是一个单一的服务器，但实际上是一组服务器来提高可靠性和可伸缩性。

9．1可伸缩性和高的可用性

可伸缩性是系统增加一个或更多部件作为系统资源的能力。很典型的是，这些部件使并发用户得到支持，使并发事务能在特定的时间单位能被处理。

假定应用程序设计良好，它完全可以简单的增加更多的资源来提高性能。为了增加WebLogic处理的负荷量，只需增加一个WebLogic实例到你的集群――不需改变应用程序。集群提高两个关键的好处：可伸缩性和可用性，这是单一服务器无法比拟的。

WebLogic集群给J2EE带来了可伸缩性和高的可用性，而且对于应用程序的开发者是透明的。可伸缩性扩展了中间层的能力，超过了单一的WebLogic服务器或单一的计算机能处理的。集群成员唯一的限制是所有WebLogic必须要用IP多点传送通信。新的WebLogic能动态的增加到集群，以增加处理能力。

WebLogic集群保证高的可用性是通过多个服务器的冗余，减少客户的请求失败。集群中多个服务器能提供同一服务。如果一个服务器停止运行，另一个能接替运行。这种功能为客户增加了可用性。

警告：如果你要解决应用程序和环境的颈瓶问题，增加额外的服务器到集群，应该提供线性的可伸缩性。定基准和初始配置测试运行时，在移到集群环境之前，应把应用隔离在单独的服务器上测试。

9．2在多CPU机器上运行多服务器实例，应考虑的性能问题

多处理器的机器上，必须考虑群集WebLogic实例数应与CPU的数量成比例。因为WebLogic没有内置限制的服务器实例数位于集群里，规模大的、多处理器服务器，如Sun公司的Sun Enterprise 10000，有着当作非常大的集群或多集群主机的潜能。

在决定最佳的服务器与CPU比例前，彻底测试你的应用程序并确定如下：

n 网络要求如果你发现Web 应用程序是主要受网络I/O限制，在增加CPU数前，考虑测试网络的吞吐量。如果实际是网络I/O限制，安装一个更快的网络接口卡（NIC）可以提供性能，而不是增加额外的CPU，因为在等着读socket时，更多的CPU会处于闲置。

n 磁盘I/O要求如果你发现Web应用程序主要受磁盘I/O限制。在配置额外的CPU前，就应该考虑增加磁盘转速或单个磁盘。

总之，在配置额外的CPU前，必须确定Web应用程序是受CUP限制，而不是受网络或磁盘I/O限制。

对于受CPU限制的应用，最初在每个CPU上对一个WebLogic实例进行性能测试。如果CPU利用率是一致的或者接近100％，然后增加CPU比重（例如，为一个WebLogic实例配置两个CUP），记住在产品模式下，应该有一些空闲的CPU周期存在去执行管理任务。

虽然Web应用程序的处理需求变化多端，但BEA公司发现WebLogic实例与CPU最理想的比例是1：2。

十、监视WebLogic域

监视WebLogic域的健康状况和性能的工具是管理控制台。通过控制台，你可以观察到WebLogic资源的状态和统计信息，如服务器，HTTP，JTA 子系统，JNDI,安全，CORBA连接池，EJB，JDBC以及JMS。

举个例子，在Server――>Monitoring――>Performance为当前服务器实例提供了与等待和运行状态的请求有关的性能参考。它包括下列信息：

n 队列中空闲线程数。

n 队列中等待时间最长的请求。

n 吞吐量，根据已经处理的请求数来衡量的。

n 队列长度，根据队列中等待请求数来衡量的。

n JVM堆还有的内存量。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Oracle中分区表的使用（转）

e-ant — Mon, 07 Jul 2008 15:47:54 +0800

作者: e-ant 链接：http://e-ant.javaeye.com/blog/212362 发表时间: 2008年07月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Oracle中分区表的使用

在大型的企业应用或企业级的数据库应用中，要处理的数据量通常可以达到几十到几百GB，有的甚至可以到TB级。虽然存储介质和数据处理技术的发展也很快，但是仍然不能满足用户的需求，为了使用户的大量的数据在读写操作和查询中速度更快，Oracle提供了对表和索引进行分区的技术，以改善大型应用系统的性能。

使用分区的优点：

1、增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用；

2、维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可；

3、均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能；

4、改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。

Oracle数据库提供对表或索引的分区方法有三种：

1、范围分区

2、Hash分区（散列分区）

3、复合分区

下面将以实例的方式分别对这三种分区方法来说明分区表的使用。为了测试方便，我们先建三个表空间。

create tablespace dinya_space01
datafile '/test/demo/oracle/demodata/dinya01.dnf' size 50M

create tablespace dinya_space02
datafile '/test/demo/oracle/demodata/dinya02.dnf' size 50M

create tablespace dinya_space03
datafile '/test/demo/oracle/demodata/dinya03.dnf' size 50M

1 分区表的创建：
1.1 范围分区
范围分区就是对数据表中的某个值的范围进行分区，根据某个值的范围，决定将该数据存储在哪个分区上。如根据序号分区，根据业务记录的创建日期进行分区等。

需求描述：有一个物料交易表，表名：material_transactions。该表将来可能有千万级的数据记录数。要求在建该表的时候使用分区表。这时候我们可以使用序号分区三个区，每个区中预计存储三千万的数据，也可以使用日期分区，如每五年的数据存储在一个分区上。

根据交易记录的序号分区建表：

SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date not null
7 )
8 partition by range (transaction_id)
9 (
10 partition part_01 values less than(30000000) tablespace dinya_space01,
11 partition part_02 values less than(60000000) tablespace dinya_space02,
12 partition part_03 values less than(maxvalue) tablespace dinya_space03
13 );

Table created.

SQL>

建表成功，根据交易的序号，交易ID在三千万以下的记录将存储在第一个表空间dinya_space01中，分区名为:par_01，在三千万到六千万之间的记录存储在第二个表空间：dinya_space02中，分区名为：par_02，而交易ID在六千万以上的记录存储在第三个表空间dinya_space03中，分区名为par_03.

根据交易日期分区建表：

SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date not null
7 )
8 partition by range (transaction_date)
9 (
10 partition part_01 values less than(to_date('2006-01-01','yyyy-mm-dd')) tablespace dinya_space01,
11 partition part_02 values less than(to_date('2010-01-01','yyyy-mm-dd')) tablespace dinya_space02,
12 partition part_03 values less than(maxvalue) tablespace dinya_space03
13 );

Table created.

SQL>

这样我们就分别建了以交易序号和交易日期来分区的分区表。每次插入数据的时候，系统将根据指定的字段的值来自动将记录存储到制定的分区（表空间）中。

当然，我们还可以根据需求，使用两个字段的范围分布来分区，如partition by range ( transaction_id ,transaction_date),分区条件中的值也做相应的改变，请读者自行测试。

1.2 Hash分区（散列分区）
散列分区为通过指定分区编号来均匀分布数据的一种分区类型，因为通过在I/O设备上进行散列分区，使得这些分区大小一致。如将物料交易表的数据根据交易ID散列地存放在指定的三个表空间中：

SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date
7 )
8 partition by hash(transaction_id)
9 (
10 partition part_01 tablespace dinya_space01,
11 partition part_02 tablespace dinya_space02,
12 partition part_03 tablespace dinya_space03
13 );

Table created.

SQL>

建表成功，此时插入数据，系统将按transaction_id将记录散列地插入三个分区中，这里也就是三个不同的表空间中。

1.3 复合分区
有时候我们需要根据范围分区后，每个分区内的数据再散列地分布在几个表空间中，这样我们就要使用复合分区。复合分区是先使用范围分区，然后在每个分区内再使用散列分区的一种分区方法，如将物料交易的记录按时间分区，然后每个分区中的数据分三个子分区，将数据散列地存储在三个指定的表空间中：

SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date
7 )
8 partition by range(transaction_date)subpartition by hash(transaction_id)
9 subpartitions 3 store in (dinya_space01,dinya_space02,dinya_space03)
10 (
11 partition part_01 values less than(to_date('2006-01-01','yyyy-mm-dd')),
12 partition part_02 values less than(to_date('2010-01-01','yyyy-mm-dd')),
13 partition part_03 values less than(maxvalue)
14 );

Table created.

SQL>

该例中，先是根据交易日期进行范围分区，然后根据交易的ID将记录散列地存储在三个表空间中。

2 分区表操作
以上了解了三种分区表的建表方法，下面将使用实际的数据并针对按日期的范围分区来测试分区表的数据记录的操作。

2.1 插入记录：
SQL> insert into dinya_test values(1,12,'BOOKS',sysdate);
1 row created.
SQL> insert into dinya_test values(2,12, 'BOOKS',sysdate+30);
1 row created.
SQL> insert into dinya_test values(3,12, 'BOOKS',to_date('2006-05-30','yyyy-mm-dd'));
1 row created.
SQL> insert into dinya_test values(4,12, 'BOOKS',to_date('2007-06-23','yyyy-mm-dd'));
1 row created.
SQL> insert into dinya_test values(5,12, 'BOOKS',to_date('2011-02-26','yyyy-mm-dd'));
1 row created.
SQL> insert into dinya_test values(6,12, 'BOOKS',to_date('2011-04-30','yyyy-mm-dd'));
1 row created.
SQL> commit;
Commit complete.
SQL>

按上面的建表结果，2006年前的数据将存储在第一个分区part_01上，而2006年到2010年的交易数据将存储在第二个分区part_02上，2010年以后的记录存储在第三个分区part_03上。

2.2 查询分区表记录：
SQL> select * from dinya_test partition(part_01);

TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
1 12 BOOKS 2005-1-14 14:19:
2 12 BOOKS 2005-2-13 14:19:
SQL>

SQL> select * from dinya_test partition(part_02);

TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
3 12 BOOKS 2006-5-30
4 12 BOOKS 2007-6-23
SQL>

SQL> select * from dinya_test partition(part_03);

TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
5 12 BOOKS 2011-2-26
6 12 BOOKS 2011-4-30
SQL>

从查询的结果可以看出，插入的数据已经根据交易时间范围存储在不同的分区中。这里是指定了分区的查询，当然也可以不指定分区，直接执行select * from dinya_test查询全部记录。在也检索的数据量很大的时候，指定分区会大大提高检索速度。

2.3 更新分区表的记录：
SQL> update dinya_test partition(part_01) t set t.item_description='DESK' where t.transaction_id=1;

1 row updated.

SQL> commit;

Commit complete.

SQL>

这里将第一个分区中的交易ID=1的记录中的item_description字段更新为“DESK”，可以看到已经成功更新了一条记录。但是当更新的时候指定了分区，而根据查询的记录不在该分区中时，将不会更新数据，请看下面的例子：

SQL> update dinya_test partition(part_01) t set t.item_description='DESK' where t.transaction_id=6;

0 rows updated.

SQL> commit;

Commit complete.

SQL>

指定了在第一个分区中更新记录，但是条件中限制交易ID为6，而查询全表，交易ID为6的记录在第三个分区中，这样该条语句将不会更新记录。

2.4 删除分区表记录：
SQL> delete from dinya_test partition(part_02) t where t.transaction_id=4;

1 row deleted.

SQL> commit;

Commit complete.

SQL>

上面例子删除了第二个分区part_02中的交易记录ID为4的一条记录，和更新数据相同，如果指定了分区，而条件中的数据又不在该分区中时，将不会删除任何数据。

3 分区表索引的使用：
分区表和一般表一样可以建立索引，分区表可以创建局部索引和全局索引。当分区中出现许多事务并且要保证所有分区中的数据记录的唯一性时采用全局索引。

3.1 局部索引分区的建立：
SQL> create index dinya_idx_t on dinya_test(item_id)
2 local
3 (
4 partition idx_1 tablespace dinya_space01,
5 partition idx_2 tablespace dinya_space02,
6 partition idx_3 tablespace dinya_space03
7 );

Index created.

SQL>

看查询的执行计划，从下面的执行计划可以看出，系统已经使用了索引：

SQL> select * from dinya_test partition(part_01) t where t.item_id=12;

Execution Plan

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

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=187)

1 0 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'DINYA_TEST' (Cost=

2 Card=1 Bytes=187)

2 1 INDEX (RANGE SCAN) OF 'DINYA_IDX_T' (NON-UNIQUE) (Cost=1

Card=1)

Statistics

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

0 recursive calls

0 db block gets

4 consistent gets

0 physical reads

0 redo size

334 bytes sent via SQL*Net to client

309 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

2 rows processed

SQL>

3.2 全局索引分区的建立。
全局索引建立时global 子句允许指定索引的范围值，这个范围值为索引字段的范围值：

SQL> create index dinya_idx_t on dinya_test(item_id)
2 global partition by range(item_id)
3 (
4 partition idx_1 values less than (1000) tablespace dinya_space01,
5 partition idx_2 values less than (10000) tablespace dinya_space02,
6 partition idx_3 values less than (maxvalue) tablespace dinya_space03
7 );

Index created.

SQL>

本例中对表的item_id字段建立索引分区，当然也可以不指定索引分区名直接对整个表建立索引，如：

SQL> create index dinya_idx_t on dinya_test(item_id);

Index created.

SQL>

同样的，对全局索引根据执行计划可以看出索引已经可以使用：

SQL> select * from dinya_test t where t.item_id=12;

Execution Plan

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

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=3 Bytes=561)

1 0 TABLE ACCESS (BY GLOBAL INDEX ROWID) OF 'DINYA_TEST' (Cost

=2 Card=3 Bytes=561)

2 1 INDEX (RANGE SCAN) OF 'DINYA_IDX_T' (NON-UNIQUE) (Cost=1

Card=3)

Statistics

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

5 recursive calls

0 db block gets

10 consistent gets

0 physical reads

0 redo size

420 bytes sent via SQL*Net to client

309 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

3 sorts (memory)

0 sorts (disk)

5 rows processed

SQL>

4 分区表的维护：
了解了分区表的建立、索引的建立、表和索引的使用后，在应用的还要经常对分区进行维护和管理。日常维护和管理的内容包括：增加一个分区，合并一个分区及删除分区等等。下面以范围分区为例说明增加、合并、删除分区的一般操作：

4.1 增加一个分区:
SQL> alter table dinya_test
2 add partition part_04 values less than(to_date('2012-01-01','yyyy-mm-dd')) tablespace dinya_spa
ce03;

Table altered.

SQL>

增加一个分区的时候，增加的分区的条件必须大于现有分区的最大值，否则系统将提示ORA-14074 partition bound must collate higher than that of the last partition 错误。

4.2 合并一个分区：
SQL> alter table dinya_test merge partitions part_01,part_02 into partition part_02;

Table altered.

SQL>

在本例中将原有的表的part_01分区和part_02分区进行了合并，合并后的分区为part_02,如果在合并的时候把合并后的分区定为part_01的时候，系统将提示ORA-14275 cannot reuse lower-bound partition as resulting partition 错误。

4.3 删除分区：
SQL> alter table dinya_test drop partition part_01;

Table altered.

SQL>

删除分区表的一个分区后，查询该表的数据时显示，该分区中的数据已全部丢失，所以执行删除分区动作时要慎重，确保先备份数据后再执行，或将分区合并。

5 总结：
需要说明的是，本文在举例说名分区表事务操作的时候，都指定了分区，因为指定了分区，系统在执行的时候则只操作该分区的记录，提高了数据处理的速度。不要指定分区直接操作数据也是可以的。在分区表上建索引及多索引的使用和非分区表一样。此外，因为在维护分区的时候可能对分区的索引会产生一定的影响，可能需要在维护之后重建索引，相关内容请参考分区表索引部分的文档。

- 作者： Mmbear_Ed 2005年04月6日, 星期三 17:03
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Linux 文件命令精通指南（转）

e-ant — Wed, 18 Jun 2008 09:10:07 +0800

作者: e-ant 链接：http://e-ant.javaeye.com/blog/204996 发表时间: 2008年06月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Linux 系统管理员

Linux 文件命令精通指南
作者：Sheryl Calish

为刚接触 Linux 文件命令的初学者提供的速成教程

虽然 GUI 桌面（如 KDE 和 GNOME）能够帮助用户利用 Linux 特性，而无需关于命令行接口的功能知识，但还是经常会需要更多的功能和灵活性。而且，基本熟悉这些命令对于在 shell 脚本中正确地使某些功能自动化仍然是必需的。

这篇文章是关于 Linux 文件命令的一个“速成教程”，它是为那些刚接触这个操作系统或者只是需要补充这方面知识的用户提供的。它包含了对一些更有用的命令的一个简明的概述以及关于它们的最强大的应用的指导。下面包含的信息 — 结合一些实验 — 将使您能够容易地掌握这些基本的命令。（注意：当涉及到一个与 Oracle 集群文件系统 (OCFS) 结合的内核时，这些命令中的某些命令的行为可能会稍微有所不同。在此情况下，Oracle 提供了一个 OCFS 工具集，该工具集可以为文件命令应用提供一个更好的选择。）

注意，这里包含的所有示例都在 SUSE Linux 8.0 Professional 上进行了测试。虽然没有理由相信它们在其它的系统上将不能工作，但如果出现问题，您应当查看您的文档，以了解可能的变化。

背景概念

在深入研究规范之前，让我们回顾一些基础知识。

文件和命令

在 Linux/UNIX 操作系统中，所有事物都被当作文件来处理：硬件设备（包括键盘和终端）、目录、命令本身，当然还有文件。这个奇怪的惯例实际上是 Linux/UNIX 的能力和灵活性的基础。

大多数（几乎是全部）的命令形式如下：

command [option] [source file(s)] [target file]

获取帮助

最有用的命令之一是那些提供帮助的命令（特别是对那些学习 Linux 的人而言）。Linux 中的两个重要的信息来源是联机参考手册，或 man 页面和 whatis 工具。您可以用 whatis 命令来访问一个不熟悉的命令的 man 页面。

$ whatis echo

要了解关于这个命令的更多信息，可以使用：

$ man echo

如果您不知道某个特殊任务所需的命令，您可以用 man -k （也称为 apropos）和一个主题来生成可能的命令。例如：

$ man -k files

一个很有用但常常被忽视的命令可以提供关于使用 man 本身的信息：

$ man man

您可以用 SPACEBAR 来浏览任意的 man 页面；UP ARROW 将向上翻滚文件。.要退出，则输入 q,!，或 CTRL-Z。

用户类别

记得那句名言“所有动物一例平等但有些动物比其他动物更加平等”吗？在 Linux 世界中，根用户掌管一切。

根用户可以以另一个用户名 su （源自 "superuser"）登录。要执行诸如添加一个新用户、打印机或文件系统之类的任务，必须作为根用户登录或者用 su 命令和根用户密码切换到超级用户。系统文件（包括控制初始化过程的系统文件）归根用户所有。虽然可能允许普通用户对它们进行读操作，但出于系统安全性的原因，编辑的权利将留给根用户。

BASH shell

虽然提供了其它的 shell，但 BASH (Bourne Again Shell) 是 Linux 的默认 shell。它结合了与它同名的 Bourne shell 的特性和 Korn、C 和 TCSH shell 的特性。

BASH 内置的命令 history 默认记录最后输入的 500 条命令。可以通过在命令提示符下输入 history 来查看它们。要检索某个特定的命令，可以在命令提示符下按 UP ARROW 或 DOWN ARROW，或在历史列表中输入它的编号，并在编号前面加上 "!"，例如：

$ !49

您还可以通过一条命令在历史列表中离位置最靠前的项目的距离来执行该命令：如果在历史列表中有 53 个事件，$ !-3 将执行事件号 51。

像 UNIX/Linux 世界的其它 shell 一样，BASH 使用了特殊的环境变量来方便系统管理。例如：

HOME，用户主目录
PATH，Linux 用来搜索您输入的命令的可执行镜像的搜索路径
HISTSIZE，系统保存的历史事件的数量

除了这些保留的关键字之外，您还可以定义您自己的环境变量。例如，Oracle 使用 ORACLE_HOME （还有其它一些变量），要使 Oracle 安装成功完成，必须在您的环境中设置这些变量。

可以在提示符下临时设置变量：

$HISTSIZE=100

或者，在 /etc/profile （需要根用户权限）中进行系统范围的永久设置，或在 .profile 中进行局部永久设置。

可以通过 echo 命令，并用一个 $ 符号来访问一个环境变量的值，进而查看该值。

$ echo $HOME
/home/bluher

可以用 env 命令来查看当前所有的环境变量。

正则表达式和通配符

许多 Linux 命令使用通配符 * 和 ? 来匹配任意数量的字符或分别匹配任意的单个字符；正则模式匹配表达式利用一个句点 (.) 来匹配除“换行符”之外的任意单个字符。这两种情况下都使用方括号 ([ ]) 来匹配除“*”号之外的字符组。不过，* 号在各种情况下有类似但不同的意义：虽然它在 shell 中将匹配一个或更多的字符，但在正则表达式中，它匹配上述字符的零个或更多的实例。一些命令（如 egrep 和 awk）使用了一组更广泛的特殊字符来进行模式匹配。

文件处理命令

剖析一个文件列表

ls 命令用来查看用户有执行权限的任意目录中的文件列表，该命令有许多有趣的选项。例如：

$ ls -liah *
22684 -rw-r--r-- 1 bluher users 952 Dec 28 18:43 .profile
19942 -rw-r--r-- 1 scalish users 30 Jan 3 20:00 test2.out
925 -rwxr-xr-x 1 scalish users 378 Sep 2 2002 test.sh

上面的列表显示 8 列：

第 1 列指示文件的 inode，因为我们使用了 -i 选项。剩下的列通过 -l 选项来进行正常显示。
第 2 列显示文件类型和文件访问权限。
第3 列显示链接数，包括目录。
第 4 和第 5 列显示文件的所有者和组所有者。这里，所有者 "bluher" 属于组 "users"。
第 6 列显示文件大小（单位为所显示的单位，而不是默认的字节数，因为我们使用了 -h 选项。
第 7 列显示日期（它看起来像是三列），包括月、日和年，以及当天的时间。
第 8 列显示文件名。在选项列表中使用 -a 将使列表中包含隐藏文件（如 .profile）的列表。
处理文件

可以移动 (mv)、复制 (cp) 或删除 (rm) 文件和目录。明智地使用 -i 选项，以获得确认通常是个不错的主意。

$ cp -i ls.out ls2.out
cp:overwrite `ls2.out'?

mv 命令允许使用 -b 选项，这将在移动文件之前作一个备份拷贝。rm 和 cp 接受功能强大但却危险的 -r 选项，它将在一个目录和它的文件上递归执行。

$ rm -ir Test
rm:descend into directory `Test'? y

可以用 mkdir 来创建目录，用 rmdir 来删除目录。不过，因为不能用 rmdir 来删除包含文件的目录，所以使用 rm 加 -r 选项通常要更方便些。

出于安全的原因，所有的文件都有所有权和保护。文件访问权限（或文件模式）包含之前提到的相同的 10 个字符：

第一个字符指示文件类型。最常见的是 - 代表文件，d 代表目录，而 l 代表链接。
接下来的 9 个字符是三种用户类别的访问权限：文件所有者（字符 2-4），用户组 (5-7) 和其它 (8-10)，其中 r 表示读权限，w 表示写权限，x 指示一个文件上的执行权限。破折号 - 如果出现在这九个位置的任意一个，则指示这个操作对该类别的用户禁止。

可以使用 chmod 命令通过字符符号或二进制掩码来设置访问权限。要使用二进制掩码，必须将三个权限组的字符表示转换成二进制格式，然后转换成八进制格式：
用户类别：所有者用户组其它
字符表示： rwx r-x r--
二进制表示： 111 101 100
八进制表示： 7 5 4

将写权限赋予用户组，您可以使用：

chmod g+w test.sh or chmod 774 test.sh

用 umask 命令，在 /etc/init.dev 文件中进行系统范围内的、或在 .profile 文件中进行的本地的文件权限默认设置。这个命令指示用 777 减去这个数字来获取默认的权限：

$ umask 022

这将为用户创建的所有新文件生成一个默认的文件权限 755。

可以用 chown 来修改文件的所有权：

$ chown bluher ls.out

这里，bluher 是新的文件所有者。类似地，组成员资格将按以下方式修改：

$ chgrp devgrp ls.out

这里，devgrp 是新的用户组。

ls 不提供哪些文件是文本的，哪些文件是二进制的的信息。要了解这个信息，您可以使用 file * 命令。

重命名文件

赋予一个文件多个名字的两种流行的方法是利用链接和 alias 命令。Alias 可以用来为一个更长的命令重新起一个更方便的名字：

$ alias ll='ls -l'
$ ll

注意单引号的使用，这使得 BASH 将该项目传递给别名，而不是自己估计它。别名还可用作较长的路径名的缩写：

$ alias jdev9i=/jdev9i/jdev/bin/jdev

关于 alias 和它的反命令 unalias 的更多信息，请查看 BASH 的 man 页面的 "SHELL BUILTIN COMMANDS" 子部分。在最后一个例子中，定义了一个环境变量来实现相同的结果。

$ export JDEV_HOME=/jdev9i/jdev/bin/jdev
$ echo $JDEV_HOME
/jdev9i/jdev/bin/jdev
$ $JDEV_HOME

链接允许几个文件名引用单个源文件，格式如下：

ln [-s] fileyouwanttolinkto newname

单独的 ln 命令创建到文件的一个硬链接，而使用 -s 选项来创建一个符号链接。简而言之，一个硬链接几乎不能和原始的文件区分开（除了这两个文件的 inode 将相同之外）。符号链接较容易区分，因为它们出现在一个长的文件列表中，并用 -> 来指示源文件，l 指示文件类型。

查看和查找文件

文件过滤器

用来读取文件内容和在文件内容上执行操作的命令有时被称为 ¹ý滤器。sed 和 awk 命令是两个滤波器的例子，因为在以前的 OTN 文章中有它们详细的讨论，在这里将略过。

诸如 cat、 more 和 less 之类的命令让您能够从命令行查看一个文本文件的内容，而无需调用编辑器。Cat 是 "concatenate" 的缩写，它将默认地在标准输出（显示屏）上显示文件内容。和 cat 一起提供的最有趣的选项之一是 -n 选项，它用编号的输出行来显示文件内容。

$ cat -n test.out
1 This is a test.

因为 cat 一次性输出文件中的所有行，所以您可能更喜欢用 more 和 less，因为它们都一次输出一屏的文件内容。Less 是 more 的一个增强的版本，它允许用来自 vi 文本编辑器的关键命令来增强文件查看。例如，d 向前翻滚、b 向后翻滚 N 行（如果 N 是在 d 或 b 之前指定的）。为 N 输入的值成为随后的 d 命令的默认值。man 页面实用工具使用 less 来显示使用说明的内容。

重定向和管道

重定向允许将命令输出重定向到文件中，而不是标准输出，或者类似地，也可重定向输入。重定向的标准符号 > 创建一个新的文件。>> 符号将输出添加到一个现有的文件中：

$ more test2.out
Another test.
$ cat test.out >> test2.out
$ cat test2.out
Another test.
This is a test.

到文件的标准输入可以用 < 符号来重定向：

$ cat < test2.out

错误消息用 2> 和 2>> 来重定向和添加，格式如下：

$ command 2> name_of_error_file

要避免无意地覆盖一个现有的文件，使用 BASH 内置的命令集：

$ set -o noclobber

可以在命令和输出文件之间用 >! 符号来重载这个特性。要关闭这个特性，用 +o 代替 -o。

重定向在一个命令和文件之间、或文件和文件之间工作。重定向语句的一项必须是一个文件。

管道使用 |符号，并且在命令之间工作。例如，您可以用以下方式将一个命令的输出直接发送到打印机上：

$ ls -l * | lpr

可以用以下方式快速地找到历史列表中的一个命令：

$ history | grep cat

更多的滤波器

Grep、fgrep 和 egrep 都显示匹配一种模式的行。所有这三个命令都在文件中搜索指定的模式，如果您想不起来一个所需文件的名称，这将非常有用。基本格式是：

grep [options] PATTERN [FILE...]

$ grep -r 'Subject' nsmail

CTRL-Z 将终止上述或其它任何命令。

grep 的最有用的选项可能是 -s。如果您以除根用户之外的任何身份搜索系统文件，那么对于每一个您没有访问权限的文件，都将产生错误消息。这个命令禁止那些消息。

Fgrep（也以 grep -F 调用）只查找固定的字符串，而不是 grep 接收的正则表达式。而 egrep 接收包含更大范围的特殊字符（如 “|”，它指示条件 OR 运算符）的模式。

$ egrep 'Subject|mailto' *

查找文件

find 命令的 GNU 版本非常强大、灵活并且比 UNIX 系统上存在的经典版本更具包容性。它对于涉及到目录结构的任务非常有用，包括在文件上查找和执行命令。find 命令的基本格式是：

$ find startdirectory options matchcriteria [actionoptions]

如果您知道文件的名称、或者甚至名称的一部分，但不知道它所处的目录，您可以这么做：

$ find .-name 'test*'
./test
./jdevhome/mywork/EmpWS/EmpBC4J/test

与经典的 UNIX 系统不同，在 Linux 中不需要在末尾添加 -print 操作，因为如果没有指定其它的操作选项，就将假定执行这个操作。在目录起始位置上的一个点 ( . ) 将使 find 在您的工作目录中开始搜索。两个点， ..，在父目录中开始搜索。您可以在任意目录下开始搜索。

注意，您可以使用通配符作为搜索准则的一部分（只要用单引号将整个项目括起来）。

$ find .-name 'test*' -print
./test.out
./test2.out

显示拥有 .out 扩展名的一系列文件：

$ find /home -name '*.out'

不过记住，除非您是作为超级用户运行这个命令，否则您将可能得到许多的 "Permission denied" 错误消息。

最强大的搜索工具之一是和 grep 一起使用的 -exec 操作：

$ find .-name '*.html' -exec grep 'mailto:foo@yahoo.com' {} \;

接下来的步骤
下载 Oracle Database 10g for Linux

访问并将 Linux 技术中心添加到收藏夹

这里，我们让 find 命令在当前目录中开始执行，接下来的步骤
下载 Oracle Database 10g for Linux

访问并将 Linux 技术中心添加到收藏夹
.，查找一个 html 文件，*.html，并在当前文件上执行 (-exec) grep 命令，{}。当使用 -
exec 操作时，需要一个分号 ;，这是用来在使用 find 命令时执行其它一些操作。需要反斜线 \ 和引号来确保这些项目通过 BASH，以使它们由命令而不是 shell 来进行解释。

立即掌握 Linux 文件命令

在 Linux 中提供了许多有用的命令和利用它们的强大的方法，在此无法一一说明。此外，完成许多任务通常都存在多种方法。

我们已经看到了一些最常用和最有启发意义的 Linux 文件命令。掌握这些基础但却关键的工具将使您的 Linux 学习走上快车道。利用您手头上的 man 页面，和试验的积极性，您现在拥有了足够的信息来开始探索 Linux 文件操作的力量。

在我的下一篇文章中，我将提供 Linux 系统命令的一个类似的说明。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐