On Wednesday 06 May 2009 19:12:17 Victor Denisov wrote: > >> The problem's that Freenet *doesn't* even use the amount of memory I > >> provide it with (I'm yet to see it use more than 120 megs out of 320 I > >> allow for the heap). I'd be willing to dedicate as much memory as > >> required if only it'd help. > > > > Well, a major objective of the db4o rewrite was precisely this. And I don't > > see that this is a problem - the OS will use the rest to cache the node.db4o > > file so that only writes need to go to disk. > > Yes, this I understand. I was one of those complaining of Freenet using > too much RAM :-(. But, IMO, using as much memory as possible (out of the > dedicated pool) could be important for performance. For example, by > increasing buffer sizes in db4o we can possibly make flushes more > "organized", reducing disk writes substantially.
No, I don't think we can, db4o is read-committed so avoiding commit() for a long period doesn't work afaik. > I wonder if there are > ways to tune db4o performance without rewriting the code, are there any > handles to turn in the db4o config? It may be possible to increase the cache size, but this is purely for avoiding calling into the OS disk cache. > > > I have seagate 1TB disks mirrored, may explain the difference. > > Unlikely, IMO. 1 Tb drives should have better throughput, but Freenet is > definitely limited by seek times, which should be only marginally better. > > >> My thinking exactly. Would providing you with a snapshot of CPU/memory > >> performance under YourKit Profiler (I have academic licenses for both > >> 7.5 and 8.0, IIRC) or VisualVM (which is now a part of the JDK > >> distributive) on my machine help? Any logging I can turn on to help? > >> BTW, I have logging set to ERROR for now, as with NORMAL level it logs > >> ~2Mb per minute, adding noticeably to overall disk contention. > > > > No, because it's an I/O problem, not a CPU/memory problem! > > I was thinking more about allocation/invocation counts, available in > both profilers. Perhaps some method/query is being called unexpectedly > often, or a certain object is being persisted too often, etc. Also, it > could be that a certain method blocks too often and for too much time in > Windows, leading to poor I/O performance. But it's a long shot, this I > agree with. > > Regards, > Victor Denisov. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/support/attachments/20090507/d2cde280/attachment.pgp>
