Tomcat--optimisation des performances
- 巴扎黑original
- 2017-06-23 16:39:051891parcourir
1. Optimisation JVM
1. Optimisation de la mémoire.
2. Optimisation de la stratégie de collecte des déchets.
2. Optimisation du connecteur de server.xml (le connecteur est un conteneur lié au traitement des requêtes HTTP. La séquence d'initialisation des trois conteneurs est : Serveur->Service->Connecteur)
( 1) Spécifiez l'utilisation du modèle NIO pour accepter les requêtes HTTP
(2) Optimisation du connecteur http, spécifiez le nombre de threads de traitement
(3) Pool de threads
(4) Paramètres d'autres routines
3. Définition de l'heure d'expiration de la session
4. Plug-in apr pour améliorer les performances de Tomcat
5. Clustering
6 . Problème de localisation de
1. Optimisation JVM
Linux modifie TOMCAT_HOME/bin/catalina.sh, ajoutez
JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"
windows modifie TOMCAT_HOME/bin. /catalina.bat, devant Ajouter
set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m
1. Réglage de la mémoire
Le paramètre du mode mémoire est dans catalina.sh. Ajustez simplement la variable JAVA_OPTS, car les paramètres de démarrage suivants traiteront JAVA_OPTS comme les paramètres de démarrage de la JVM.
Les paramètres spécifiques sont les suivants :
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"
Les paramètres sont les suivants suit :
-Xmx3550m : Définissez la mémoire maximale disponible de la JVM sur 3550 M. La taille maximale du tas ne doit pas dépasser 80 % de la mémoire physique disponible
-Xms3550m : configurez la JVM pour que la mémoire soit de 3 550 m. Cette valeur peut être définie de la même manière que -Xmx pour éviter que la JVM ne réalloue la mémoire après chaque garbage collection.
-Xmn2g : Réglez la taille de la jeune génération sur 2G. La taille totale du tas = taille de la jeune génération + taille de l'ancienne génération + taille de la génération persistante. La génération persistante a généralement une taille fixe de 64 m, donc augmenter la jeune génération réduira la taille de l’ancienne génération. Cette valeur a un impact important sur les performances du système. Sun recommande officiellement de la configurer aux 3/8 du tas entier.
-Xss128k : Définissez la taille de la pile de chaque thread. Après JDK5.0, la taille de pile de chaque thread est de 1 Mo. Dans le passé, la taille de pile de chaque thread était de 256 Ko. Ajustez la taille de la mémoire requise pour davantage de threads d'application. Sous la même mémoire physique, la réduction de cette valeur peut générer davantage de threads. Cependant, le système d'exploitation a toujours une limite sur le nombre de threads dans un processus et ne peut pas être généré à l'infini. La valeur d'expérience est d'environ 3 000 à 5 000.
-XX:NewRatio=4 : Définissez le ratio de la jeune génération (y compris Eden et deux zones Survivor) par rapport à l'ancienne génération (hors génération persistante). Réglé sur 4, alors le rapport entre la jeune génération et l'ancienne génération est de 1:4, et la jeune génération représente 1/5 de la pile entière
-XX:SurvivorRatio=4 : Définissez le rapport de taille de l'Eden la zone et la zone Survivant chez la jeune génération. Réglé sur 4, le rapport entre deux zones Survivant et une zone Eden est de 2:4, et une zone Survivant représente 1/6 de l'ensemble de la jeune génération
-XX:MaxPermSize=16m : Définissez la taille de la génération persistante sur 16m.
-XX:MaxTenuringThreshold=0 : Définit l'âge maximum des déchets. S'il est défini à 0, les objets de la jeune génération entreront directement dans l'ancienne génération sans passer par la zone Survivant. Pour les applications comportant un grand nombre d’anciennes générations, l’efficacité peut être améliorée. Si cette valeur est définie sur une valeur plus élevée, l'objet de la jeune génération sera copié plusieurs fois dans la zone Survivant, ce qui peut augmenter la durée de survie de l'objet dans la jeune génération et augmenter la possibilité d'être recyclé dans la jeune génération.
2. Réglage de la stratégie de collecte des ordures
Le paramètre de collecte des ordures est également dans catalina.sh, ajustez la variable JAVA_OPTS.
Les paramètres spécifiques sont les suivants :
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
La stratégie spécifique de garbage collection et les paramètres du correspondant stratégie sont les suivantes :
Collecteur série (la principale méthode de recyclage avant JDK1.5)
-XX:+UseSerialGC : Configurer le collecteur série
Collecteur parallèle (priorité de débit)
java - Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:+UseParallelGC : Sélectionnez le ramasse-miettes comme collecteur parallèle. Cette configuration n'est valable que pour la jeune génération. Autrement dit, dans la configuration ci-dessus, la jeune génération utilise la collecte simultanée, tandis que l'ancienne génération utilise toujours la collecte en série.
-XX:ParallelGCThreads=20 : configurez le nombre de threads du collecteur parallèle, c'est-à-dire combien de threads peuvent effectuer le garbage collection en même temps. Il est préférable de configurer cette valeur égale au nombre de processeurs.
-XX:+UseParallelOldGC : configurez la méthode de récupération de place d'ancienne génération pour la collecte parallèle. JDK6.0 prend en charge la collecte parallèle de l'ancienne génération
-XX:MaxGCPauseMillis=100 : définissez la durée maximale pour chaque garbage collection de jeune génération. Si cette durée ne peut pas être respectée, la JVM ajustera automatiquement la taille de la jeune génération pour y répondre. valeur .
-XX:+UseAdaptiveSizePolicy : Après avoir défini cette option, le collecteur parallèle sélectionnera automatiquement la taille de la zone de jeune génération et le ratio de zone de survivant correspondant pour atteindre le temps de réponse minimum ou la fréquence de collecte spécifiée par le système cible. utiliser parallèle pour cette valeur. Le collecteur est toujours ouvert.
Collecteur simultané (priorité du temps de réponse)
Exemple : java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC : définissez l'ancienne génération pour la collecte simultanée. Après avoir configuré cela dans le test, la configuration de -XX:NewRatio=4 a échoué pour des raisons inconnues. Par conséquent, il est préférable d’utiliser le paramètre -Xmn pour la taille de la jeune génération pour le moment.
-XX:+UseParNewGC : Placer la jeune génération dans la collecte parallèle. Peut être utilisé simultanément avec la collection CMS. Pour JDK5.0 et versions ultérieures, la JVM le définira elle-même en fonction de la configuration du système, il n'est donc pas nécessaire de définir cette valeur.
-XX:CMSFullGCsBeforeCompaction : étant donné que le collecteur simultané ne compresse ni n'organise l'espace mémoire, une "fragmentation" sera générée après une exécution pendant un certain temps, réduisant ainsi l'efficacité opérationnelle. Cette valeur définit le nombre de fois que le GC sera exécuté pour compresser et organiser l'espace mémoire.
-XX:+UseCMSCompactAtFullCollection : Activer la compression de l'ancienne génération. Cela peut affecter les performances, mais cela peut éliminer la fragmentation
3 Résumé
Vous devez faire des compromis dans les paramètres de mémoire
1) Plus la mémoire est grande, plus la mémoire est grande. meilleure est l'efficacité du traitement dans des circonstances normales. Plus elle est élevée, mais en même temps, plus la collecte des ordures prend du temps, et l'efficacité du traitement pendant cette période sera inévitablement affectée.
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. Solution de cluster
Les performances de traitement d'un seul Tomcat sont limitées lorsque le degré de concurrence est important, plusieurs ensembles doivent être déployés pour l'équilibrage de charge.
Les points clés du cluster sont les suivants :
1. Présentation du côté chargement
Le chargement logiciel peut être effectué à l'aide de nginx ou d'apache, principalement à l'aide d'une fonction de distribution.
Référence :
(chargement nginx)
(chargement apache)
2. Traitement de session partagée
Les méthodes de traitement actuelles sont les suivantes :
1) Utiliser la propre fonction de réplication de session de Tomcat
Référence (Configuration de la réplication de session)
L'avantage de cette solution est qu'elle est simple à configurer. L'inconvénient est que lorsque le nombre de clusters est important, la réplication de session. le temps sera plus long, affectant l'efficacité de la réponse.
2) Utiliser un tiers pour stocker les sessions partagées
Actuellement, memcached est utilisé pour gérer les sessions partagées, et memcached-session-manager est utilisé pour gérer celles de Tomcat. sessions
Référence (utilisation de MSM Gérer la session du cluster Tomcat)
3). Utiliser la stratégie de session persistante
Pour les situations où les exigences de session ne sont pas trop strictes (aucune facturation n'est impliquée, une nouvelle demande est autorisée en cas d'échec). , etc.), la session du même utilisateur peut Nginx ou Apache est transmise au même Tomcat pour traitement. Il s'agit de la stratégie dite de persistance de session, qui est actuellement utilisée dans de nombreuses applications
Référence : (tomcat. session sticky)
nginx n'inclut pas le module session sticky par défaut et doit être recompilé OK (je ne sais pas comment recompiler sous Windows)
L'avantage est que l'efficacité du traitement est bien supérieure, mais. l'inconvénient est qu'il ne convient pas aux occasions avec de fortes exigences de session
3. Une instance pour chaque site. Démarrez plusieurs Tomcat.
N'utilisez pas l'hôte virtuel de Tomcat, une instance par site. Autrement dit, démarrez plusieurs Tomcats.
C'est également une erreur courante commise par l'exploitation et la maintenance de PHP ici. L'approche de PHP consiste à placer plusieurs hôtes virtuels sous un seul Web au lieu de démarrer un serveur Web pour chaque hôte. Tomcat est multithread et partage la mémoire Si une application d'un hôte virtuel tombe en panne, toutes les applications seront affectées. Bien que l’utilisation de plusieurs instances soit relativement coûteuse, elle garantit l’isolation et la sécurité des applications.
4. Résumé
Ce qui précède sont les points clés de la mise en œuvre d'un cluster 1 et 2 peuvent être utilisés en combinaison~
6. location
Le problème que Tomcat met beaucoup de temps à traiter est principalement causé par la concurrence à ce moment-là, le nombre de sessions, la mémoire et le recyclage de la mémoire, etc. Lorsqu’un problème survient, il faut l’analyser.
1. À propos du nombre de sessions Tomcat
Ceci peut être consulté directement depuis l'interface de gestion Web Tomcat
ou à l'aide de l'outil tiers Lambda Probe, it Par rapport à la gestion fournie avec Tomcat, il a un peu plus de fonctions, mais pas beaucoup
2. Surveiller l'utilisation de la mémoire de Tomcat
À l'aide de la jconsole fournie avec le JDK peut être plus clair. Voir l'utilisation de la mémoire, l'état des threads, le nombre total de classes actuellement chargées, etc.
Le jvisualvm fourni avec JDK peut télécharger des plug-ins (tels que GC, etc.) pour afficher des informations plus riches. Si vous analysez Tomcat local, vous pouvez également effectuer un échantillonnage de mémoire et vérifier l'utilisation de chaque classe
3 Imprimer l'état de chargement des classes et l'état de recyclage des objets
Ceci. Vous pouvez imprimer ces informations (à l'écran (également sur catalina.log par défaut) ou dans un fichier) en configurant les paramètres de démarrage de la JVM. Les paramètres spécifiques sont les suivants :
-XX:+PrintGC : Format de sortie : [. GC 118250K-> 113543K(130112K), 0,0094143 secondes] [GC complet 121376K->10414K(130112K), 0,0650971 secondes]
-XX:+PrintGCDetails : Format de sortie : [GC [DefNew : 8614K- > 781 Ko (9088K), 0,0123035 secondes] 118250K->113543K(130112K), 0,0124633 secondes] [GC [DefNew : 8614K->8614K(9088K), 0,0000665 secondes][Tenured : 112761K-> 10414K(121024K), 0,0433488 secs] 121376K-> 10414K(130112K), 0,0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC : PrintGCTimeStamps peut être mélangé avec les deux ci-dessus, format de sortie : 11.851 : [GC 98328K->93620K( 130112K), 0,0082960 sec s]
-XX:+PrintGCApplicationConcurrentTime : Imprime le temps d'exécution ininterrompu du programme avant chaque garbage collection. Peut être mélangé avec ci-dessus. Format de sortie : Temps d'application : 0,5291524 secondes
-XX:+PrintGCApplicationStoppedTime : Imprime l'heure à laquelle le programme a été mis en pause pendant le garbage collection. Peut être mélangé avec ci-dessus. Format de sortie : durée totale pendant laquelle les threads d'application ont été arrêtés : 0,0468229 secondes
-XX:PrintHeapAtGC : imprimer les informations détaillées sur la pile avant et après GC
-Xloggc:filename : à utiliser en conjonction avec ce qui précède pour enregistrer les informations de journal pertinentes dans fichier pour analyse
-verbose:class surveille l'état des classes chargées
-verbose:gc affiche des informations sur le périphérique de sortie lorsque le recyclage de la mémoire se produit dans la machine virtuelle
-verbose:jni génère une méthode native appels Les situations associées sont généralement utilisées pour diagnostiquer les messages d'erreur d'appel jni
4. Ajouter une surveillance à distance JMS
Pour Tomcat déployé sur d'autres machines du LAN, vous pouvez ouvrir le port de surveillance JMX. , LAN D'autres machines peuvent afficher certains paramètres couramment utilisés via ce port (mais certaines fonctions plus complexes ne sont pas prises en charge). Elles peuvent également être configurées dans les paramètres de démarrage de la JVM. La configuration est la suivante :
-Dcom.sun.management. .jmxremote.ssl =false -Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.71.38 Définissez l'adresse IP de surveillance JVM JMS, principalement pour éviter une surveillance incorrecte sur 127.0.0.1 Cette adresse intranet
-Dcom.sun.management.jmxremote.port=1090 Définit le port pour la surveillance JVM JMS
-Dcom.sun.management.jmxremote.ssl=false Définit la surveillance JVM JMS et il n'est pas pratique de utilisez SSL
-Dcom.sun.management.jmxremote.authenticate=false La configuration de la surveillance JVM JMS ne nécessite pas d'authentification
5. Les outils d'analyse professionnels incluent
IBM ISA, JProfiler, etc., recherchez simplement en ligne des méthodes de surveillance et d'analyse spécifiques.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!