У нас была проблема перегрузки GC с Tomcat, которая развернула наше веб-приложение.
Мы попробовали это в указанном порядке: 1. Уменьшено session-timeout до 10 2. Увеличена кучная память для Tomcat 3. Увеличена оперативная память для сервера, а затем снова увеличена кучная память для Tomcat
Теперьдаже при отсутствии перегрузки GC память Working Set в Process Explorer постоянно увеличивается, и через некоторое время сервер слишком медленно обрабатывает вход в систему.
Возможные причины, которые мы обнаружили на сервере:
- Слишком много запросов на вход со многими потоками.В журнале мы видим несколько попыток входа в систему с разными потоками каждый раз.Иногда они равны 2 в секунду и / или микросекунде.Все запросы совместно используют один и тот же идентификатор сеанса при входе в систему.
В дампе кучи,
a.ConcurrentHashMap ОГРОМНЫЙ b.Каждый узел имеет стандартную сессию.с.Каждый сеанс создает новый объект ServiceClient через UsernamePasswordAthenticationToken, который в памяти равен 2G.
В дампе ServiceClient имеет <class>, что указывает на WebappCassLoader, что вПоворот имеет <loader> с целым ConcurrentHashMap.
ServiceClient, унаследованным от WebServiceClient и имеет 4 строковых переменных с одной статической переменной, которая выглядит как приватная статическая java.net.URL url = ServiceClient.class.getResource ("server.wsdl")
server.wsdl находится в WEB-INF \ lib jar.
Возможно ли, что из-за статической переменной каждый ServiceClient в каждом сеансе имеетЖивым эталоном является JVM, и поэтому он никогда не будет собран GC?
Что может быть другой возможной причиной?