我实现了一个 Web 应用程序来快速启动 Tomcat 服务，但是花费数小时并且当更多用户进入时变得越来越慢（最多 15 个用户）。
检查 RAM 使用统计 (20%)、CPU (25%)
服务器特点：
我不使用Web服务器，我们直接在Tomcat上发布。
进入半夜仍保持缓慢（仅1个用户在线）
我的解决方案是重新启动 Tomcat 服务，响应时间再次非常好。
有没有人经历过这个问题？任何线索将不胜感激。
没有提供足够的细节。需要更多信息:(
使用htop或top查找每个进程和每个线程的内存和 CPU 使用情况。
在 4 核系统中恒定 25% 的 CPU 使用率表明单核应用程序/线程在它能够使用的唯一核上运行 100% CPU。
哪个应用程序正在吃 CPU？
20% 的内存约为 1.6GB。对于仅运行 tomcat + mysql 的空闲服务器，这比我预期的要多一点。告诉 tomcat预-Xms1024分配 1GB 内存以便解释它。
将 tomcat 设置更改为-Xms512和-Xmx2048。当你把一些用户扔给它时，观察 tomcat 的内存使用情况。如果它继续增长直到达到 2GB……然后冻结，这可能表明内存泄漏。
用于df -h检查磁盘使用情况。完整的分区可能会导致您遇到的问题。
Filesystem Size Used Avail Usage% Mounted on
/cygdrive/c 149G 149G 414M 100% /
（如果您刚刚在此示例中发现我的笔记本电脑空间不足。您做得对：D）
日志很棒。然而，他们有一个坏习惯来填满磁盘。检查日志磁盘使用情况。新用户连接时是否正确写入/擦除/旋转日志？删除日志可以解决问题吗？（在删除它们之前将它们复制到某处以供将来分析）
如果不。日志仍然很棒。他们有帮助您跟踪错误的好习惯。检查tomcat日志。您可能希望将日志记录级别设置为调试。网站死后最后会发生什么？任何有用的错误信息？用户连接是否仍被 tomcat 接收和接受？
我想 25% 的 CPU 用于 tomcat（而不是 mysql）。Tomcat 本身不会失败。在其上运行的应用程序必须失败。尝试从 tomcat 中删除应用程序（您最终可以使用 hello world 代替）。没有您的应用程序，tomcat 可以保持通宵工作吗？它可能可以，在这种情况下，故障出在应用程序上。
在您的应用程序中启用完整的调试日志记录并尝试跟踪问题。在调试模式下直接从 Eclipse 运行它，然后将用户扔给它。它是否以同样的方式持续失败？
如果是，请在 Eclipse 调试器中点击“暂停”并检查应用程序正在做什么。查看每个线程当前正在运行的代码段 + 它的调用堆栈。重复几次。如果出现死锁、无限循环或类似情况，您可以通过这种方式找到它。
如果你幸运的话，你现在已经发现了这个问题。如果不是，那么你很不幸，这是一个可能在应用程序内部很深的棘手错误。这可能很难追踪。决心将导致成功。祝你好运=)
我在干净的 Centos7 安装上遇到了一个非常慢的 Tomcat 仪表板，发现了以下原因和解决方案：
Tomcat 的缓慢启动时间通常与 Java 的 SecureRandom 实现有关。默认情况下，它使用 /dev/random 作为熵源。这可能会很慢，因为它使用系统事件来收集熵（例如磁盘读取、按键等）。正如 urandom 联机帮助页所述：
When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
通过将以下配置选项添加到您的 tomcat.conf 或（首选）自定义文件来修复它/tomcat/conf/conf.d/：
JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom"
对于与性能相关的问题，我们需要遵循给定的规则：
-Xms2048m -Xmx2048m
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
如果页面更改过于频繁而无法使此选项合乎逻辑，请尝试临时缓存动态内容，这样就不需要一遍又一遍地重新生成。应该使用任何可以用来缓存已经完成的工作而不是再次执行的技术——这是实现最佳 Tomcat 性能的关键。
如果有任何与数据库相关的问题，那么可以按照sql 查询性能调整
旋转Catalina.out日志文件，without restarting Tomcat.
具体来说，有两种方式。
第一个，更直接的是，您可以通过在 Catalina 的启动 shell 脚本中添加一个简单的管道到您选择的日志轮换工具来轮换 Catalina.out。这看起来像：
"$CATALINA_BASE"/logs/catalina.out WeaponOfChoice 2>&1 &
只需"WeaponOfChoice"用您最喜欢的日志轮换工具替换即可。
第二种方法不太直接，但最终更好。处理 Catalina.out 旋转的最佳方法是确保它永远不需要旋转。只需将 .swallowOutput 中的所有上下文设置为 true 即可"server.xml"。
这将路由System.err到System.out您已配置的任何日志记录实现，或者JULI，如果您尚未配置。
我们遇到了类似的问题，原因是“catalina.out”。它是“System.out”和“System.err”的标准目标日志文件。它的大小不断增加，从而减慢速度，最终 tomcat 崩溃了。通过旋转“catalina.out”解决了这个问题。我们使用的是redhat，所以我们制作了一个shell脚本来旋转“catalina.out”。
以下是一些链接：-
关于 catalina 的 Mulesoft 文章（也包含两种旋转方法）：
如果“catalina.out”不是问题，那么试试这个： -
Mulesoft 关于优化 Tomcat 的文章： Tuning Tomcat Performance For Optimum Speed
我们遇到了一个问题，看起来与您的问题相似。Tomcat 响应缓慢，但访问日志仅显示几毫秒的响应。问题是流响应。我们的一项服务返回了用户可以订阅的实时数据。EPOLL 变得臃肿。网络请求无法到达 Tomcat。更有趣的是，CPU 大部分时间都是空闲的（因为没有人可以要求服务器做任何事情）并且接受器/轮询器线程位于WAIT，而不是RUNNINGor IN_NATIVE。
当时我们只是限制了此类请求的数量，一切都变得正常了。