Tomcat -- パフォーマンスの最適化
- 巴扎黑オリジナル
- 2017-06-23 16:39:051891ブラウズ
1. JVM の最適化
1.
2. ガベージ コレクション戦略の最適化。
2.server.xmlのコネクタ最適化(コネクタはHTTPリクエスト処理に関わるコンテナです。3つのコンテナの初期化順序はサーバー→サービス→コネクタ)
(1)NIOの使用を指定HTTP リクエストを受け入れるモデル
(2) http コネクタの最適化、処理スレッド数を指定
(3) スレッド プール
(4) その他の一般設定
3. セッションの有効期限を設定
4. Apr プラグ-in により Tomcat のパフォーマンスが向上します
5. クラスター
6. 問題の場所
1. JVM の最適化
linux TOMCAT_HOME/bin/catalina.sh を変更して追加
JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"
windows TOMCAT_HOME/bin/catalina.bat を変更し、
set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m
1. メモリの調整
メモリ モードの設定は catalina.sh にあります。後続の起動パラメータは JAVA_OPTS を JVM の起動パラメータとして扱うためです。
具体的な設定は次のとおりです:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"
パラメータは次のとおりです:
-Xmx3550m: 使用可能な最大値を設定しますJVM のメモリを 3550M に増やします。最大ヒープ サイズは、利用可能な物理メモリの 80% を超えてはなりません
-Xms3550m: メモリが 3550m になるように JVM を設定します。この値を -Xmx と同じに設定すると、ガベージ コレクションのたびに JVM がメモリを再割り当てするのを避けることができます。
-Xmn2g: 若い世代のサイズを 2G に設定します。全体のヒープ サイズ = 若い世代のサイズ + 古い世代のサイズ + 永続世代のサイズ。通常、永続世代のサイズは 64m に固定されているため、若い世代を増やすと古い世代のサイズが小さくなります。この値は、システムのパフォーマンスに大きな影響を与えます。Sun では、ヒープ全体の 3/8 の構成を公式に推奨しています。
-Xss128k: 各スレッドのスタック サイズを設定します。 JDK5.0 以降、各スレッドのスタック サイズは 1M 以前は、各スレッドのスタック サイズは 256K でした。より多くのアプリケーション スレッドに必要なメモリ サイズを調整します。同じ物理メモリの下で、この値を減らすと、より多くのスレッドが生成される可能性があります。ただし、オペレーティング システムにはプロセス内のスレッド数に制限があり、経験値は 3000 ～ 5000 程度です。
-XX:NewRatio=4: 古い世代 (永続世代を除く) に対する若い世代 (Eden と 2 つの Survivor エリアを含む) の比率を設定します。 4 に設定すると、若い世代と古い世代の比率は 1:4 になり、若い世代がスタック全体の 1/5 を占めます
-XX:SurvivorRatio=4: Eden 領域のサイズ比率を設定し、若い世代のサバイバーエリア。 4 に設定すると、2 つの Survivor エリアと 1 つの Eden エリアの比率は 2:4 となり、1 つの Survivor エリアが若い世代全体の 1/6 を占めます
-XX:MaxPermSize=16m: 永続世代のサイズを 16m に設定します。
-XX:MaxTenuringThreshold=0: ガベージの最大存続期間を設定します。 0 に設定すると、若い世代のオブジェクトは Survivor 領域を経由せずに直接古い世代に入ります。古い世代が多数あるアプリケーションの場合、効率を向上させることができます。この値をより大きな値に設定すると、若い世代のオブジェクトが Survivor 領域に複数回コピーされるため、若い世代でのオブジェクトの生存時間が長くなり、若い世代で再利用される可能性が高まります。
2. ガベージコレクション戦略のチューニング
ガベージコレクションの設定もcatalina.shにあり、JAVA_OPTS変数を調整します。
具体的な設定は次のとおりです:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
特定のガベージ コレクション戦略と対応する戦略のパラメーターは次のとおりです:
シリアルコレクター (JDK1.5以前の主要な再利用方法)
-XX:+UseSerialGC: シリアルコレクターの設定
パラレルコレクター (スループット優先)
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX: MaxGCPauseMillis =100
-XX:+UseParallelGC: ガベージ コレクターを並列コレクターとして選択します。この設定は若い世代にのみ有効です。つまり、上記の構成では、若い世代は同時収集を使用しますが、古い世代は依然としてシリアル収集を使用します。
-XX:ParallelGCThreads=20: 並列コレクターのスレッド数、つまりガベージ コレクションを同時に実行するスレッドの数を構成します。この値は、プロセッサの数と同じに構成するのが最適です。
-XX:+UseParallelOldGC: 旧世代のガベージ コレクション メソッドを並列コレクションに構成します。 JDK6.0 は古い世代の並列コレクションをサポートします
-XX:MaxGCPauseMillis=100: 若い世代の各ガベージ コレクションの最大時間を設定します。この時間を満たせない場合、JVM はこの値を満たすように若い世代のサイズを自動的に調整します。
-XX:+UseAdaptiveSizePolicy: このオプションを設定すると、パラレル コレクターは、ターゲット システムで指定された最小応答時間または収集頻度を達成するために、若い世代領域のサイズと対応する Survivor 領域の比率を自動的に選択します。この値のパラレル コレクターは常にオープンです。
コンカレントコレクター (応答時間優先)
例: java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSoupGC
-XX:+UseConcMarkSweatGC: コンカレントコレクション用に古い世代を設定します。テストでこれを構成した後、-XX:NewRatio=4 の構成は不明な理由で失敗しました。したがって、現時点では、若い世代のサイズには -Xmn 設定を使用するのが最善です。
-XX:+UseParNewGC: 若い世代を並列コレクションに設定します。 CMSコレクションとの併用も可能です。 JDK5.0以降の場合は、システム構成に応じてJVMが自ら設定するため、この値を設定する必要はありません。
-XX:CMSFullGCsBeforeCompaction: コンカレント コレクターはメモリ空間の圧縮と整理を行わないため、一定期間実行すると「フラグメント」が生成され、操作効率が低下します。この値は、メモリ空間を圧縮して整理するために GC が実行される回数を設定します。
-XX:+UseCMSCompactAtFullCollection: 古い世代の圧縮をオンにします。パフォーマンスに影響する可能性がありますが、断片化を解消できます
3. 概要
メモリ設定でいくつかのトレードオフを行う必要があります
1) メモリが大きいほど、通常の状況では処理効率が高くなりますが、同時にガベージコレクションにかかる時間が長くなるほど、この間の処理効率は必然的に影響を受けます。
2)在大多数的网络文章中都推荐 Xmx和Xms设置为一致，说是避免频繁的回收，这个在测试的时候没有看到明显的效果，内存的占用情况基本都是锯齿状的效果，所以这个还要根据实际情况来定。
二、Server.xml的Connection优化
提高Tomcat的并发能力一些方法
1、Apache + Tomcat 结合起来用Apache 负责静态页面，Tomcat负责动态页面，同时减少connectionTimeout的时间，以应对并发量大线程回收来不及的情况。
2、压力过大的问题，可以做负载均衡，一个TOMCAT无论如何也不可能担当如此多的线程负载，而且JVM过大，其内存管理成本将显著加大。2G的内存，做3-4个TOMCAT实例（512RAM*4），更为科学合理。
3、数据库连接池，不少人，都推荐使用C3P0，能提高访问数据库的并发性能好几倍。（有博文称使用tomcat自带的jdbc-pool更好，还没试过）
4、采用Tomcat集群可以最大程度的发挥服务器的性能，可以在配置较高的服务器上部署多个Tomcat，也可以在多台服务器上分别部署 Tomcat，Apache和Tomcat整合的方式还是JK方式。经过验证，系统对大用户量使用的响应方面，Apache+3Tomccat集群> Apache+2Tomcat集群> Apache集成Tomcat >单个Tomcat。并且采用Apache+多Tomcat集群的部署方式时，如果一个Tomcat出现宕机，系统可以继续使用，所以在硬件系统性能足够优越的情况下，需要尽量发挥软件的性能，可以采用增加Tomcat集群的方式。
5. 打开KeepAlive支持
KeepAlive on, KeepAliveTimeout 15 MaxKeepAliveRequests 1000
根据实际经验，通过Apache和Tomcat集群的方式提高系统性能的效果十分明显，这种方式可以最大化的利用硬件资源，通过多个Tomcat的处理来分担单Tomcat时的压力。
web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。
1.指定使用NIO模型来接受HTTP请求
protocol="org.apache.coyote.http11.Http11NioProtocol" 指定使用NIO模型来接受HTTP请求。默认是BlockingIO，配置为protocol="HTTP/1.1"
acceptorThreadCount="2" 使用NIO模型时接收线程的数目
2、指定处理线程数目
<Connector port="80" protocol="HTTP/1.1" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700" connectionTimeout="20000" redirectPort="8443" />
maxThreads="600" ///最大线程数
minSpareThreads="100"///初始化时创建的线程数
maxSpareThreads="500"///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
这里是http connector的优化，如果使用apache和tomcat做集群的负载均衡，并且使用ajp协议做apache和tomcat的协议转发，那么还需要优化ajp connector。
<Connector port="8009" protocol="AJP/1.3" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700" connectionTimeout="20000" redirectPort="8443" />
3、线程池
由于tomcat有多个connector，所以tomcat线程的配置，又支持多个connector共享一个线程池。
首先。打开/conf/server.xml，增加
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="20" maxIdleTime="60000" />
最大线程500（一般服务器足以），最小空闲线程数20，线程最大空闲时间60秒。
然后，修改
<Connector executor="tomcatThreadPool" port="80" protocol="HTTP/1.1" connectionTimeout="60000" keepAliveTimeout="15000" maxKeepAliveRequests="1" redirectPort="443" />
可以多个connector公用1个线程池，所以ajp connector也同样可以设置使用tomcatThreadPool线程池。
4.其它常用设置
maxHttpHeaderSize="8192" http请求头信息的最大程度，超过此长度的部分不予处理。一般8K。
URIEncoding="UTF-8" 指定Tomcat容器的URL编码格式。不要遗漏URIEncoding=”GBK”，能使页面url传递中文参数时保证正确。
disableUploadTimeout="true" 上传时是否使用超时机制
enableLookups="false"--是否反查域名，默认值为true。为了提高处理能力，应设置为false
compression="on" 打开压缩功能 。压缩会增加Tomcat负担，最好采用Nginx + Tomcat 或者 Apache + Tomcat 方式，压缩交由Nginx/Apache 去做。
compressionMinSize="10240" 启用压缩的输出内容大小，默认为2KB
noCompressionUserAgents="gozilla, traviata" 对于以下的浏览器，不启用压缩
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些资源类型需要压缩
5.小结
关于Tomcat的Nio和ThreadPool，本身的引入就提高了处理的复杂性，所以对于效率的提高有多少，需要实际验证一下。
三、设置session过期时间
conf\web.xml中通过参数指定：
<session-config> <session-timeout>180</session-timeout> </session-config> 单位为分钟。
四、Apr插件提高Tomcat性能
Tomcat可以使用APR来提供超强的可伸缩性和性能，更好地集成本地服务器技术.
APR(Apache Portable Runtime)是一个高可移植库，它是Apache HTTP Server 2.x的核心。APR有很多用途，包括访问高级IO功能(例如sendfile,epoll和OpenSSL)，OS级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，NT管道和UNIX sockets)。这些功能可以使Tomcat作为一个通常的前台WEB服务器，能更好地和其它本地web技术集成，总体上让Java更有效率作为一个高性能web服务器平台而不是简单作为后台容器。
在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能
要测APR给tomcat带来的好处最好的方法是在慢速网络上（模拟Internet），将Tomcat线程数开到300以上的水平，然后模拟一大堆并发请求。
如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待。但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来。
在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输。如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的。
(1)安装APR tomcat-nativeapr-1.3.8.tar.gz 安装在/usr/local/apr #tar zxvf apr-1.3.8.tar.gz #cd apr-1.3.8#./configure;make;make install apr-util-1.3.9.tar.gz 安装在/usr/local/apr/lib #tar zxvf apr-util-1.3.9.tar.gz #cd apr-util-1.3.9 #./configure --with-apr=/usr/local/apr ----with-java-home=JDK;make;make install #cd apache-tomcat-6.0.20/bin #tar zxvf tomcat-native.tar.gz #cd tomcat-native/jni/native #./configure --with-apr=/usr/local/apr;make;make install (2)设置 Tomcat 整合 APR 修改 tomcat 的启动 shell （startup.sh），在该文件中加入启动参数： CATALINA_OPTS="$CATALINA_OPTS -Djava.library.path=/usr/local/apr/lib" 。 (3)判断安装成功: 如果看到下面的启动日志，表示成功。 2007-4-26 15:34:32 org.apache.coyote.http11.Http11AprProtocol init
5. クラスターソリューション
単一の Tomcat の処理パフォーマンスには限界があります。同時実行の量が多い場合、負荷分散のために複数のセットをデプロイする必要があります。
クラスターの重要なポイントは次のとおりです:
1. ロード側を紹介します ソフトロードは、主に分散機能を使用して nginx または apache を使用して実行できます
参考:
(nginx ロード)
(apache ロード) )
2. 共有セッション処理 現在の処理方法は以下の通りです:
1). Tomcat 独自のセッションレプリケーション機能を使用します
参考 (セッションレプリケーション設定)
このソリューションの利点は、設定がシンプルであることです。欠点は、クラスターの数が多い場合、セッションのレプリケーション時間が長くなり、応答効率に影響することです
2) 共有セッションを保存するためにサードパーティを使用します
現在、最も一般的に使用されている方法は memcached を使用することです。 memcached-sesson-manager を使用して共有セッションを管理します。 Tomcat セッション管理
リファレンス (MSM を使用して Tomcat クラスター セッションを管理する)
3) セッション要件がそれほど強くない場合には、スティッキー セッション戦略を使用します。 (課金を伴わない、失敗しても再リクエストが許可される、など), nginx または apache によって、同じユーザーのセッションを同じ Tomcat に引き継ぐことができます。これは、現在使用されている、いわゆるセッション スティッキー戦略です。
参考: (Tomcat セッション スティッキー)
nginx にはデフォルトでセッション スティッキー モジュールが含まれていないため、再インストールする必要があります (Windows で再コンパイルする方法がわかりません)
利点は次のとおりです。処理効率ははるかに高いですが、セッション要件が強い場合には適さないという欠点があります
Tomcat の仮想ホストは使用せず、サイトごとに 1 つのインスタンスを使用します。つまり、複数の Tomcat を起動します。
これは、PHP の運用と保守でよくある間違いでもあります。PHP のアプローチは、ホストごとに Web サーバーを起動するのではなく、1 つの Web の下に複数の仮想ホストを配置することです。 Tomcat はマルチスレッドであり、メモリを共有します。仮想ホスト内のアプリケーションがクラッシュすると、すべてのアプリケーションが影響を受けます。複数のインスタンスを使用すると比較的コストがかかりますが、アプリケーションの分離とセキュリティが確保されます。
4. まとめ
上記は 1 と 2 を組み合わせて使用できる、具体的なシナリオを分析してみましょう
6. 時間がかかった主な問題。 Tomcat プロセスは、同時実行性、セッション数、メモリ、メモリのリサイクルなどのいくつかの側面によって発生します。問題が発生したら、それを分析する必要があります。
1. Tomcat セッションの数について
これは、Tomcat の Web 管理インターフェイスから直接表示することも、Tomcat 自身の管理よりもわずかに多くの機能を備えたサードパーティ ツール Lambda Probe を使用することもできます。
2. Tomcat のメモリ使用量を監視します
JDK に付属の jconsole を使用して、メモリ使用量、スレッドのステータス、現在ロードされているクラスの総数などを明確に確認します。 JDK に付属の jvisualvm は自動的に実行します。プラグイン (GC など) をダウンロードして、より豊富な情報を表示します。ローカル Tomcat を分析している場合は、メモリ サンプリングを実行して各クラスの使用状況を確認することもできます
3. クラスのロード ステータスとオブジェクトのリサイクル ステータスを出力します
これは、次の起動パラメータを設定することで実行できます。 JVM がこれらの情報を (画面 (デフォルトでは catalina.log にも) またはファイルに) 出力する場合、特定のパラメーターは次のとおりです:
-XX:+PrintGC: 出力形式: [GC 118250K->113543K(130112K)] 、0.0094143 秒] [フル GC 121376K ->10414K(130112K)、0.0650971 秒] -XX:+PrintGCDetails: 出力形式: [GC [DefNew: 8614K->781K(9088K)、0.0123035 秒] 118250K-> 113543K(1301 12K)、0.0124633 秒] [GC [DefNew: 8614K->8614K(9088K)、0.0000665 秒][Tenured: 112761K->10414K(121024K)、0.0433488 秒s] 121376K->10414K(130112K)、 0.0436268 秒] -XX:+PrintGCTimeStamps -XX:+PrintGC: PrintGCTimeStamps は上記の 2 つと組み合わせることができます。出力形式は次のとおりです: 11.851: [GC 98328K->93620K(130112K), 0.0082960 秒]
-XX:+ PrintGCApplicationConcurrentTime: 各ガベージ コレクションを出力する前に、プログラムが割り込みの実行時間を調べませんでした。上記と混合可能です。出力形式: アプリケーション時間: 0.5291524 秒
-XX:+PrintGCApplicationStoppedTime: ガベージ コレクション中にプログラムが一時停止された時間を出力します。上記と混合可能です。出力形式: アプリケーションスレッドが停止した合計時間: 0.0468229 秒
-XX:PrintHeapAtGC: GC 前後の詳細なスタック情報を出力
-Xloggc:filename: 上記と組み合わせて使用し、関連するログ情報を分析用にファイルに記録します
-verbose:class は、ロードされたクラスのステータスを監視します
-verbose:gc は、仮想マシンでメモリのリサイクルが発生したときに出力デバイスに関する情報を表示します
-verbose:jni は、ネイティブ メソッド呼び出しの関連状況を出力し、通常は jni の診断に使用されます呼び出しエラー メッセージ
4. JMS リモート モニタリングの追加
LAN 内の他のマシンにデプロイされた Tomcat の場合、LAN 内の他のマシンは、このポートを介していくつかの一般的に使用されるパラメータを表示できます。複雑な関数はサポートされていません)、JVM 起動パラメーターで構成することもできます。構成は次のようになります:
-Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname= 192.168.71.38 JVM JMS モニタリングの IP アドレスを設定します。主に、イントラネット アドレス 127.0.0.1 への誤ったモニタリングを防止するためです。 -Dcom.sun.management.jmxremote.port=1090 JVM JMS モニタリングを設定します。 port
- Dcom.sun.management.jmxremote.ssl=false JVM JMS モニタリングの設定は SSL では現実的ではありません
-Dcom.sun.management.jmxremote.authenticate=false JVM JMS モニタリングの設定には認証は必要ありません
5専門的な分析ツール
IBM ISA、JProfiler などがあり、特定の監視および分析方法をオンラインで検索できます。
以上がTomcat -- パフォーマンスの最適化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。