Nick,
I agree %100 that 1 GB a day is too much, and so would our ops group. It's
not my decision, and apparently I don't have enough influence yet :) It's
a system that went into production recently and the managers aren't willing
to turn off debug even temporarily right now. It's not my code or my
system. I'm just doing what I can to grease it. If I can make the cost of
logging negligible it will make it that much easier to analyze memory usage
on the rest of the application.
Chris
"Bauman, Nick"
<nick_bauman@rete To: "Log4J Developers List"
<[EMAIL PROTECTED]>
k.com> cc:
Subject: RE: Proposed architecture
changes to log4j for improved memory usage
10/03/2002 05:58
PM
Please respond to
"Log4J Developers
List"
Chris, your input is very helpful.
You say that per day, you're logging ~1 GB. What is that, something like,
1.15 MB per second? Isn't that too much?
We did once have an issue with too much logging bringing performance down.
To solve it, we added a feature in our logging component where we can raise
and lower logging levels on a per Logger basis on a running system. This
means we log almost nothing most of the time. We have to do this if we are
tp support ~10,000 concurrent users. If we think there's a problem, we can
turn up a single Logger to debug level and get more information.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thu 10/3/2002 2:35 PM
To: Log4J Developers List
Cc:
Subject: RE: Proposed architecture changes to log4j for improved memory
usage
I'm glad to see the feedback and interest on the message I
posted. I will
try to start responding to specific questions early next week.
For memory and object count I used JProbe 4.0.
I very much appreciate the functionality of Log4J. I am sold
on the API.
Any changes I am proposing I believe do not interfere with the
current
usage of the API or current performance WRT response time(it
might even
improve however slightly). I believe 0 transient object usage
is a worthy
goal and would not be difficult to fit into the existing
framework. The
main premise is this, move the formatting of the response out
of a full in
memory representation(StringBuffer) and stream it in fragments
to a
destination via a buffer(BufferedWriter).
On my project we have alot of GC. The app does alot of
logging, ~1 GB a
day and we are just starting to ramp up users. Alot of the
garbage is not
from logging. The log4j changes I've made have really helped
the system
overall because it is memory hungry to begin with.
Chris
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
(See attached file: winmail.dat)--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
winmail.dat
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
