Memory Fully utilized by Java ConcurrentHashMap (under Tomcat)

前端 未结 5 2010
执笔经年
执笔经年 2020-12-02 19:17

This is a memory stack (serves as a cache) that consist of nothing but a static ConcurrentHashMap (CHM).

All incoming HTTP request data are store in this Concurrent

5条回答
  •  -上瘾入骨i
    2020-12-02 19:48

    Of course, it is too late to answer, but just for other people who will find this question by search. It might be useful.

    These 2 links are very useful
    https://issues.apache.org/bugzilla/show_bug.cgi?id=50685
    http://wiki.apache.org/tomcat/OutOfMemory

    Briefly, in most cases it is a wrong test or test software. When some custom software open URL, if this software cannot manage http session tomcat creates new session for each request. For example it is possible to check it with simple code, which can be added to JSP.

    System.out.println("session id: " + session.getId());
    System.out.println("session obj: " + session);
    System.out.println("session getCreationTime: " + (new Date(session.getCreationTime())).toString());
    System.out.println("session.getValueNames().length: " + session.getValueNames().length);
    

    If session ID will be the same for one user from load test point of view, it is fine, if each request generates new session ID, that means testing software does not manage the sessions very well and test result does not represent load from real users.

    For some application session.getValueNames().length also important, because For example, when normal user works it remain the same, but when load testing software do the same, it is grows. It also means, that load testing software does not represent real workload very well. In my case session.getValueNames().length for normal user was about 100, but qwith load testing software after 10 minutes is was about 500 and finally system crashes with the same OutOfMemory error and MAT shows the same:

    org.apache.catalina.loader.StandardClassLoader @ 0x853f0280" occupies 2,135,429,456 (94.76%) bytes.

提交回复
热议问题