On Wednesday 21 January 2009 18:16, Dennis Nezic wrote: > On Wed, 21 Jan 2009 17:28:47 +0000, Matthew Toseland wrote: > > On Wednesday 21 January 2009 03:01, Dennis Nezic wrote: > > > On Mon, 19 Jan 2009 23:52:26 +0100, bqz69 wrote: > > > > > > > > > > Now my freenet is running on my fit-pc - has been running > > > > > > properly the last week. > > > > > > > > > > > > I did following (I am using ubuntu 8.04): > > > > > > > > > > > > 1. Created a text file /etc/cron.allow containing my username. > > > > > > > > > > That might explain why your wrapper's wrapper (your crontab-run > > > > > script) wasn't working. Though you don't have to manually > > > > > specify a cron.allow file... you can just delete it, and it > > > > > allows everyone by default, unless they're mentioned in > > > > > cron.deny. > > > > > > > > > > > 2. Inserted following line in /etc/crontab: > > > > > > > > > > > > @hourly myusername ~/Freenet/run.sh start > > > > > > > > > > > > (Probably not necessary) > > > > > > > > > > This one, the system-cron file, is necessary. The second one is > > > > > useless, I believe. Cron never checks > > > > > ~/.crontab--only /etc/crontab, and /var/spool/cron/crontabs, > > > > > for individual users. > > > > > > > > > > > 3. Created a text file ~/.crontab with the following line: > > > > > > > > > > > > @hourly myusername ~/Freenet/run.sh start > > > > > > > > > > > > The freenet system seems however to very sensitive, and stops > > > > > > when I do some other work, and then I have to restart freenet, > > > > > > but as a mini-freenet server just serving data, it seems to > > > > > > work well. > > > > > > > > > > Interesting. And bad! :). How sure are you that the crashes > > > > > occur when you're doing other work on the system? > > > > > > > > Ok, not so sure, just tried again and freenet did not stop this > > > > time. > > > > > > > > > (Is it wishful thinking? ;). > > > > > What is the "nice" value for freenet's java process? > > > > > > > > It is 10 > > > > > > > > > (You can check > > > > > it via the "top" command.) I had mine at a brutal 20 (the lowest > > > > > priority of all my processes on my system), and toad suggested > > > > > that this may have been the cause of my crashes. I have raised > > > > > it's priority now, and will continue to test. Though I am > > > > > skeptical. Crashing should not happen. Ever! > > > > > > > > > > > Thanks everybody so far, for your help > > > > > > > > > > "So far". I'm sure we haven't heard the end of this one :). > > > > > > Mine just "crashed" recently. Actually, it shuts itself down pretty > > > cleanly, after outputting the following age-old messages: > > > > > > Restarting node: PacketSender froze for 3 minutes! > > > Exiting on deadlock. > > > Restarting node: MessageCore froze for 3 minutes! > > > (USM deadlock) > > > Goodbye. > > > > > > In general, I do notice that freenet bogs down my 1.2GHz machine > > > quite a bit. Could that be the cause of these freezes/deadlocks? > > > Can't it be less cpu/mem intensive? If I recall correctly, it does > > > run smoothly for the first few hours, then slowly grinds itself > > > (apparently) and my box to an unbearable crawl. > > > > > > Maybe we could make those messages more informative? For example, > > > before having the node shut itself down, have it dump it's list of > > > threads or queues or whatever. > > > > Give it more memory. If you can't give it more memory, throw the box > > out the window and buy a new one. If you can't do that wait for the > > db4o branch. > > My main point in my last post was a suggestion to have the error > message more informative. As another example, have it output it's > memory/cpu usage before it shuts itself down, in the case of the > deadlock I mentioned.
How do we get CPU usage from java? We can say how much memory is in use, how many threads are running, get a thread dump... > > Also, why is there such a high requirement?? Why on earth is 100MB > memory not enough? If it can't allocate any more memory, it should wait > or throttle itself. Restricting freenet to the latest unecessary > super-computers is dumb. (It really should be developed on a 486.) Because it has a lot of stuff to track. People propose rewriting Freenet in kernel-mode C with 1KB blocks every so often, as an example. That means 32X more disk seeks, 32X bigger bloom filter, and so on; it's not feasible. Memory requirements depend on two things: - The datastore. The bdbje datastore uses a significant amount of memory, with significant churn, inside the JVM's allocated space; the salted hash datastore uses very little memory inside the memory limits but uses 1/2048th of the store outside of the limits as a memory mapped bloom filter to limit I/O. - Client layer activity. Lots of large downloads use lots of memory, uploads use even more (because of inefficient architecture). > > When is the db4o stuff expected to be released? When I get around to it. :| The immediate todo: - Release 1203 - Implement basic progress screen. - Get db4o sorted and merged. - Sort out plugins (IMHO important for 0.8). - Auto-update (and update.* update) the seednodes file. - Maybe new metadata (IMHO the assumptions underlying this item may no longer be valid...) > > > Seriously, EVERY time I have investigated these sorts of issues the > > answer has been either that it is showing constant Full GC's because > > it has slightly too little memory, or that there is external CPU > > load. Are you absolutely completely totally > > 100000000000000000000000000% sure that that is not the problem? > > AFAICS there are two posters here, and just because one of them is > > sure that the problem isn't memory doesn't necessarily mean that the > > other one's problems are not due to memory?? > > There are reports on FMS of people with gigs of ram, and powerful > machines, with crashing nodes. Just because they have lots of RAM doesn't mean they've set the wrapper memory limit that high. > Though, I'm not sure if it's the same > problem, as my node hasn't really crashed this time--it just shut > itself down. (Before I would get JVM hung errors, without any clean > shut downs.) This is closely related IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/support/attachments/20090121/05159148/attachment.pgp>
