小编nab*_*llo的帖子

我目前正在将Adobe Experience Manager(AEM也称为CQ)用于客户端站点(Java平台).它使用OpenJDK:

java version "1.7.0_65" 
OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) 
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

它在Rackspace上运行,具有以下内容:

vCPU: 4 
Memory: 16GB 
Guest OS: Red Hat Enterprise Linux 6 (64-bit)

由于它已经投入生产,我在应用程序方面遇到了非常慢的性能.它就是这样我启动应用程序,一切顺利然后7到10天后CPU使用率达到400%(每天约4000个用户点击网站).该网站变得异常缓慢,永远不会成为OOM例外.

由于我是Java内存管理的新手,我开始阅读它是如何工作的,并找到了像jstat和jmap这样的工具.当系统第二次被淹没时,我得到一个堆转储并挖到它.

这一切似乎都在指出org.slf4j.helpers.BasicMarkerFactory和org.slf4j.helpers.BasicMarker,因为当我用MAT eclipse进行分析时,我看到保留大小的最大保留对象是:

org.slf4j.helpers.BasicMarkerFactory @ 0x6021a4f00
Shallow Size: 16 B Retained Size: 6.8 GB

和

当我运行泄漏嫌疑人报告时,我得到以下结果:

Description
One instance of "org.slf4j.helpers.BasicMarkerFactory" loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x60219a878" occupies 7,263,024,848 (96.71%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded by "<system class loader>".

Keywords …

在过去的一个月里,我一直在处理一个AEM 6.0生产站点,在一周左右之后需要重新启动实例.在这种特殊情况下,我的出版商失败了.所以我进一步研究了一下,发现一切都很好,然后几天之后垃圾收集变得疯狂,所以CPU利用率就像疯了一样增加.从那里我重新启动了我的发布者并等待GC再次出现问题并使用MAT(来自eclipse的Memory Analyzer Tool)进行分析时等待堆转储.经过我的检查,我发现94%的堆都被ConcurrentHashMap占用.我潜入那个对象,发现Sessions是手头的问题,或者至少是一个主要问题.session-timeout值为0,因此会话没有超时.我的错误日志显示了这种类型的消息:

*WARN* [ip [1432319636774] GET something HTTP/1.1] org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been idle for 2 minutes and might be out of date. Consider using a fresh session or explicitly refresh the session. 

是否可以在AEM中配置会话管理器？以前有没有人在AEM看过这个？我应该将session-timeout设置为1还是某个值？欢迎任何建议知道我应该如何解决这个问题？

谢谢

当在调度程序上请求页面时，我在发布实例error.log中看到了这一点

18.12.2019 22:13:05.563 *INFO* [x.x.x.x [1576707185560] GET /etc.clientlibs/project/clientlibs/clientlib-all.fd5c5f2e8418f9ae1aa923efb9e7ad95.js HTTP/1.1] com.adobe.granite.ui.clientlibs.impl.ClientLibraryProxyServlet Proxy request to /etc.clientlibs/project/clientlibs/clientlib-all.fd5c5f2e8418f9ae1aa923efb9e7ad95.js not supported.\n

因此etc.clientlibs不会加载到调度程序中，而是发回 404。

过滤规则似乎默认允许 clientlibs/0002 { /type "allow" /url "/etc.clientlibs/*" }

我在网上做了一些挖掘，发现了以下潜在的解决方法：

\n
1. 允许匿名 读取访问/etc。
\n
2. 明确拒绝 的第一级子级的 匿名 读取访问，/etc以确保您不\xe2\x80\x99t 允许事物通过。
\n

虽然这似乎暂时解决了问题，但我认为这充其量只是一种解决方法。

有谁知道这个问题的解决方案以及如何在不更改 OOTB 权限的情况下解决此问题？

谢谢，

尼古拉

我目前在托管 Lucidworks Fusion 的 Amazon EKS 集群上遇到问题。首先，我有一个 Amazon EKS v1.18集群，然后我将其升级到v1.19，一切进展顺利。我的集群中还运行了ingress-nginx-3.7.1，然后我将其升级到ingress-nginx-4.0.19，此时一切似乎仍然正常运行。也就是说，一旦我将集群升级到v1.20，当耗尽我的 Pod 并在新工作节点中重新启动它们时，所有 Pod 都会正确重新启动，除了我的大使Pod 现在陷入CrashLoopBackOff状态。我查看了这个 pod 的日志，发现以下错误：

2022/04/08 14:00:35 ERROR(s): kubebootstrap: WORKER PANICKED: ingresses.networking.k8s.io is forbidden: User "system:serviceaccount:sandbox1:sandbox1-ambassador" cannot list resource "ingresses" in API group "networking.k8s.io" in the namespace "sandbox1"

有谁知道这意味着什么？我相信这告诉我一些与权限相关的事情，但我不太确定。另外我想了解导致此问题的原因，是将我的 EKS 集群升级到 v1.20 还是升级 ingress-nginx 或完全不同的东西？最后我想了解如何解决这个问题并使这个 Pod 再次正常运行？欢迎任何帮助。