First, you are referring to Log4j 1.x. Most of our work is currently focused on Log4j 2. That said, you would have the same issue with Log4j 2, Logback or even java.util.logging.
What possible reason could you have for creating a logger per subscriber? The key to us being able to provide a solution is to know what you are attempting to accomplish by doing that. You cannot possibly configure 10 million loggers so it can't possibly have anything to do with that. If it is to have some mechanism to identify the subscriber than there are much better ways to do that. I would suggest reading through the Log4j 2 manual at http://logging.apache.org/log4j/2.x/manual/index.html and seeing if the facilities it has provide a solution. Ralph On Aug 26, 2013, at 1:32 PM, Deon van der Merwe wrote: > Hi, > > For every new category created a new entry is added into > org.apache.log4j.Hierarchy.ht. And at the same time also for any possible > parent category of that new entry. > > This cache is fine when you have a fairly fixed number possible categories. > That cache will grow to some size and remain that size. > > In our application we have several static categories but then also categories > which consists of some subscriber identity. Possible range here is in the > order of tens of millions. Most of these subscriber identity categories live > for a fairly short time, let's say less than 10 minutes. Below is a sample > output from jstat showing the number of Logger objects going over 11M. At > that point the GC starts to complain and the JVM is starting to suffer. > > Now, org.apache.log4j.Hierarchy has a "clear" method which will just clean > the ht lookup completely. Using that clear feels a bit harsh/extreme, > especially considering that we still have categories that do live a very long > time. > > So, the question is if using "clear" is good practice or not? If it is good, > then fine. If not: what is good practice for keeping this ht lookup size > down to more practical levels (looking at current/live traffic etc)? > > > > num #instances #bytes class name > ---------------------------------------------- > 28: 41807 1672280 org.apache.log4j.Logger > 20: 88086 3523440 org.apache.log4j.Logger > 15: 113835 4553400 org.apache.log4j.Logger > 18: 133267 5330680 org.apache.log4j.Logger > 16: 152379 6095160 org.apache.log4j.Logger > 15: 173559 6942360 org.apache.log4j.Logger > 11: 210480 8419200 org.apache.log4j.Logger > 11: 316526 12661040 org.apache.log4j.Logger > 10: 672608 26904320 org.apache.log4j.Logger > 2: 892928 35717120 org.apache.log4j.Logger > ... > ... > ... > 2: 11295227 451809080 org.apache.log4j.Logger > 2: 11301788 452071520 org.apache.log4j.Logger > 2: 11317688 452707520 org.apache.log4j.Logger > 2: 11352595 454103800 org.apache.log4j.Logger > 2: 11389363 455574520 org.apache.log4j.Logger > 2: 11428866 457154640 org.apache.log4j.Logger > 2: 11470739 458829560 org.apache.log4j.Logger > 2: 11514552 460582080 org.apache.log4j.Logger > 2: 11556256 462250240 org.apache.log4j.Logger > > > > -- > __Deon_______________________________________________ > TruTeq Wireless (Pty) Ltd. Tel: +27 12 667 1530 > http://www.truteq.co.za Fax: +27 12 667 1531 > Timezone: SAST GMT+2 > Copyright&Legal: http://truteq.co.za/legal_notice.pdf > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >
