我们在容器化环境中运行我们的 Mule3.8.0EE 应用程序，每个容器一个应用程序。从容器层面，由于物理主机的资源池有限，我们限制了 cpu/memory 资源，我在高峰期指的这个 API 最多只能使用 1 个 cpu 核心和 512MB 内存(由 kubernetes 管理)
mule 流程相当简单 - 一个带有 APIKit 的 http 端点，然后通过 redis 连接器进行后端 Redis 调用以执行 get by key 操作，以及用于将数据转换为 json 并返回的 dataweave
我们检测到的问题是一旦有加载请求(100+ 并发)，使用所有默认的性能相关配置(策略、线程等)，应用程序总是触发 JVM 退出，然后在容器内重新启动自身
问题是鉴于这些有限的资源，我们应该如何调整它以至少不死但缓慢地处理这些负载。期望建议例如:我们应该增加线程池还是减少？我们应该使用同步处理策略吗？等等
更新:我们正在使用 docker json 日志驱动程序，因此 mule 应用程序将其所有日志输出到容器的控制台并由 docker 获取，如果我们为每个请求打印一行日志并且一旦有负载，我注意到这也是一个问题，这个 glibc/tanuki 包装问题(在 mule3.8 之后被认为是固定的)。
提前致谢
最佳答案
关于docker - 使用有限资源调整 Mule 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40730914/