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. Is there any ways to cut down this memory without hurting routing? > > For inserts, we could also estimate how much RAM will be required, and > warn the user instead of trying to start an insert that is likely to > OOM. > > Evan Daniel > _______________________________________________ > Devl mailing list > [email protected] > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
