On Tuesday 10 November 2009 15:22:37 Daniel Cheng wrote: > On Mon, Nov 9, 2009 at 10:39 PM, Evan Daniel <[email protected]> wrote: > > On Mon, Nov 9, 2009 at 8:35 AM, Matthew Toseland > > <[email protected]> wrote: > >> Some Chinese feedback: Main point is there are a lot of old PCs with very > >> limited RAM, although new ones have plenty of RAM. Broadband is however > >> reasonable in general, making it a better candidate than Iran. Suggested > >> making startup on startup configurable, substantially reducing memory > >> footprint etc. My worry with the former is that opennet won't last > >> forever, and low-uptime darknet is very problematic. > >> > >> IMHO we could reasonably cut our default memory limit to 128M. The main > >> issues are: > >> - Sorting out Library memory issues (bug #3685) > >> - Sorting out Freetalk memory issues (I haven't seen OOMs from Freetalk > >> recently, maybe this really is fixed?) > >> - Sorting out - or ignoring - the startup memory spike on big inserts (4G > >> needs 192MB). > >> > >> On fast systems, a higher memory limit means less CPU spent in garbage > >> collection, so maybe there is an argument for reinstating the panel in the > >> wizard that asks the user how much memory to allocate... > >> > >> Our friend has also localised the wininstaller (this is subject to > >> technical issues Zero3 hopefully will be able to resolve), and jSite (I > >> will deal with this soon). > > > > It is my understanding (haven't personally tested) that we could > > reduce the memory footprint by reducing the per-thread stack size > > (-Xss option). Similarly, reducing the max thread count might help > > (we don't usually use all the threads, but worst-case behavior is what > > causes OOMs). > > > > Should we base the memory for RAM buckets on the configured maximum, > > instead of having a constant default? These are used for caching > > decoded data, right? So more buckets means that Library gets far more > > responsive on repeat searches. (Just tested this -- increasing RAM > > buckets to 80 MiB does seem to mean that Library skips directly to the > > "Parsing subindex" step on repeat or partially repeat searches. Of > > course, it's still glacially slow after that.) > > On an idle node, most of the memory are used by the FailureTable.
What is the memory footprint of an idle node? Pretty low, no? Isn't the big problem the client layer, the datastore, etc? > Is there any ways to cut down this memory without hurting routing? We could get a bit from cleaning the failure table more often. I've increased the frequency from every 30 minutes to every 10 minutes. This also improves privacy marginally. Also, as per bug 2477, it is possible for the failure table keys to have DSAPublicKey's, thus massively increasing their memory usage. I have fixed this too. I will send another reply with more info...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
