On Tue, Jan 30, 2007 at 09:39:05PM +0000, Bob Ham wrote: > On Tue, 2007-01-30 at 16:54 +0000, Matthew Toseland wrote: > > After various reports of OOMs, and after high CPU usage which might have > > been related to excessive GCing, I did some profiling. > > I've done some profiling of my own: > > http://teasel.6gnip.net/~rah/freenet-threads-2007-01-30-21:23:18.png > > The red line is the effective maximum memory that fred should use, as > configured in wrapper.conf, in addition to the default DB memory usage.
The configured limit in wrapper.conf is absolute. The memory usage *as reported by the JVM* will never exceed this. I am not able to retrieve the png in the time it has taken to write this email. > The brown line is the actual memory usage. The JVM in use is sun's, > version 1.5.0, release 9. > > It's clear to see that the configured limits are wholly ignored, and by > significant percentages. This is a major problem. On the contrary this is utterly irrelevant. It is Sun's problem, not our problem; the JVM itself uses a significant amount of memory, and there is literally nothing we can do about this. Also normally these reports are usually the result of people taking the wrong memory measurement; in linux there is RSS and VIRT; VIRT is more or less irrelevant. > On my own machine, > fred will get so large as to cause the kernel to start killing processes > due to lack of memory. These include named, cron, mysql and apache, in > addition to fred itself. What was the limit set to? What was the usage reported in the log file (Memory in use: <blah> - only enabled with minor logging)? What was the reported RSS? How much memory do you actually have (and swap)? > > I only recently got my node back up after it refused to be able to start > for some time. This I've noted on the IRC, if you recall. The problem > would seem to be the size of the data store: after removing all of the > data files, the node starts without any problems. Needless to say, I've > reduced the size now. > > > Any ideas? We can: > > - Just ignore it > > Not an option in my opinion. You have configured your memory limit too high for your actual RAM, or something. This is irrelevant to the core issue, which is why does BDB use so much memory. > > > - Use another database. BDB has been fairly unreliable, hence the code > > in the store to reconstruct the database (store index) from the store > > file by deleting the database and parsing each key. > > - Given the second item, if we had a reliable database we could store > > queued requests in it, thus limiting the overall memory usage > > regardless of the size of the request queue. But that would be a > > significant amount of work even with a database. > > I think there are deeper issues to deal with. Please answer the questions I have posed above. It is likely that you have configured your maximum memory to be greater than your total RAM or something; this is absolutely not Fred's fault; it might conceivably be a JVM problem. > Even disregarding the > database, fred's memory footprint is massive. Negative. I was running it with a maximum memory setting of 100MB, and 54MB+ of that was used by the database. If the database had respected the configured setting of 20MB, that would be a grand total of 64MB. Which IMHO is very reasonable. > For the functionality > that it provides, it seems to me to be excessive. I can't understand > why fred would need anything in excess of a few 10s of megabytes. Where > is this memory going? > > Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070201/2fa9bd3c/attachment.pgp>
