nodeUptime: 11h54m
On 2006-10-07 (Sat) at 08:01:33 -0500, Brandon Low wrote:
> Cached keys: 462,933 (14.1 GiB)
> Stored keys: 13,172 (411 MiB)
> Overall size: 476,105/2,455,108 (14.5 GiB/74.9 GiB)
> Cache hits: 4,820 / 30,204 (15%)
> Store hits: 85 / 23,627 (0%)
> Avg
Cached keys: 462,933 (14.1 GiB)
Stored keys: 13,172 (411 MiB)
Overall size: 476,105/2,455,108 (14.5 GiB/74.9 GiB)
Cache hits: 4,820 / 30,204 (15%)
Store hits: 85 / 23,627 (0%)
Avg. access rate: 1/s
On 2006-10-07 (Sat) at 00:01:21 +0100, Matthew Toseland wrote:
> 1. THE STORE IS *LESS* EFFECTIVE
Cached keys: 462,933 (14.1 GiB)
Stored keys: 13,172 (411 MiB)
Overall size: 476,105/2,455,108 (14.5 GiB/74.9 GiB)
Cache hits: 4,820 / 30,204 (15%)
Store hits: 85 / 23,627 (0%)
Avg. access rate: 1/s
On 2006-10-07 (Sat) at 00:01:21 +0100, Matthew Toseland wrote:
1. THE STORE IS *LESS* EFFECTIVE
nodeUptime: 11h54m
On 2006-10-07 (Sat) at 08:01:33 -0500, Brandon Low wrote:
Cached keys: 462,933 (14.1 GiB)
Stored keys: 13,172 (411 MiB)
Overall size: 476,105/2,455,108 (14.5 GiB/74.9 GiB)
Cache hits: 4,820 / 30,204 (15%)
Store hits: 85 / 23,627 (0%)
Avg. access rate: 1/s
On 2006-10-07
of uptime.
--Brandon
On Sat, 11/15/03 at 18:41:54 -0500, Edward J. Huff wrote:
On Fri, 2003-11-14 at 12:32, Brandon Low wrote:
And then it died overnight... gawdamnit... and that is with my max
open files set to 4096, bloody thing leaks socket handles.
My earlier reply to a later message
On Sat, 11/15/03 at 18:36:40 -0500, Edward J. Huff wrote:
On redhat 9 I put fs.file-max = 65536 in /etc/syscntrl.conf...
I found users still have ulimit -u showing max files 1024, and that
they can't increase it.
After googling a bit, I discovered two approaches (I fixed both)
1)
And then it died overnight... gawdamnit... and that is with my max open files set to
4096, bloody thing leaks socket handles.
Amazing, I went to bed at 2:30, and the 1:00-2:00 hour was the last hour
it was running properly for... I hate computers. Lasted on the order of
6 hours.
--B
Caught a
This is relevent only to Linux users, and probably only to fairly
advanced ones at that.
So Zab and I have been trying to find a way to run Freenet with NPTL
for some time now, because there are big performance and ease of use
benefits in doing this. Unfortunately Sun's JVMs have proven
On Thu, 11/13/03 at 23:46:29 -0600, Brandon Low wrote:
Other things to note about the IBM JDK: As the JIT compiler does it's
work, debugging symbols are stripped from the code, this means that call
traces after long uptimes will no longer contain line numbers of
references. This means
Since the refs are set at the highest sensitivity, it isn't really
possible to attack using this mechanism... consider it a weak hint.
--Brandon
On Wed, 11/12/03 at 21:54:46 -0600, Edgar Friendly wrote:
Toad [EMAIL PROTECTED] writes:
Freenet unstable build 6330 is in CVS. By the time you
The other things that really need fixing are:
Why would external bandwidth limiting cause very spiky performance
problems? (Supple)
Why does the node so often freeze while healing FEC?
Why doesn't the node return a CHK after inserting a CHK more than half
the time?
Otherwise, my node seems to
On Tue, 11/11/03 at 20:07:45 +, Toad wrote:
On Tue, Nov 11, 2003 at 02:00:31PM -0600, Brandon Low wrote:
The other things that really need fixing are:
Why would external bandwidth limiting cause very spiky performance
problems? (Supple)
YThreads, more NIO. Hopefully the former
Ahh, but look at your send queue... there isn't so much a performance
increase as a decrease in QRing and a decrease in BW-per-transfer.
--Brandon
On Mon, 11/10/03 at 10:15:58 -0800, Salah Coronya wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been running 6323 (compiled from
On Mon, 11/10/03 at 18:12:03 +, Toad wrote:
On Sun, Nov 09, 2003 at 12:33:48PM -0800, Brandon Low wrote:
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv21891/freenet/src/freenet/node/rt
Modified Files:
NGRoutingTable.java
Log
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these wait messages and therefore gets
performance, and market it as 'Freenet-Xtreme' or some damned thing.
--B
On Mon, 11/10/03 at 19:44:47 +, Ian Clarke wrote:
Ok, we forget about quotas, nice,
to this will rely on properly behaving other
nodes, and cannot be solved by banning misbehavers.
--Brandon
On Mon, 11/10/03 at 19:59:58 +, Ian Clarke wrote:
Brandon Low wrote:
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these wait messages
this
handle a node which can accept 30kqph... sounds like a lot of overhead.
But the point of this e-mail is that you guys win, it is feasible.
--B
On Mon, 11/10/03 at 17:08:00 -0500, Ken Corson wrote:
Brandon Low wrote:
How? Any node which sends another request before X has elapsed gets
banned? Any
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
Brandon Low wrote:
Freenet
doesn't work this way, watch this:
Node A wants something from Node B.
A sends a request to B
A replies and says wait X
B says to itself OK, I'll wait X
No, A sends a request to B. B eventually send
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
Brandon Low wrote:
Absolutely NOT, if node A waits for it's next request until it gets a
response to it's first request, we have just gone to a protocol with
worse problems than TCP w/o tcp transmit windows. This would cause
nodes like
Yeah, it could be accounted for... meh...
On Mon, 11/10/03 at 20:49:59 -0500, Ken Corson wrote:
Brandon Low wrote:
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
Brandon Low wrote:
Absolutely NOT, if node A waits for it's next request until it gets a
response to it's first request
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv21891/freenet/src/freenet/node/rt
Modified Files:
NGRoutingTable.java
Log Message:
Change how rt nodes are removed from the rt. This sorting seems to make more sense
logically, and in practice,
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv22647/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Fix minor NPE if a ignoredDNF message comes back after a FailureEntry has fallen out
of the FT (this somehow happened
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv7797/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Wow, lots more changes to FailureTable... accesses, and whatnot are much more
consistent now, hope toad likes it better
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv17296/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Oops, way to not test my last little change.
Works again.
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv4324/freenet/src/freenet/node/rt
Modified Files:
NGRouting.java
Log Message:
Add a counter for number of DNFs ignored per FailureEntry
Make HTML easier on browsers and eyes by separating into
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv4324/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Add a counter for number of DNFs ignored per FailureEntry
Make HTML easier on browsers and eyes by separating into
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv8950/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Damnit, another 'doh' in the FT, once this is tested, I should probably bump the
version, cuz it is pretty bad.
Index:
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv22045/freenet/src/freenet
Modified Files:
Version.java
Log Message:
6301:
Niklas:
Refactoring of routing points
OCM PeerHandler mode is default
Add some color methods for future graph improvements
Me:
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv26789/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Just add accounting of total blocks and total ignores to the HTML (It'd be better if
these could go ahead of the
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv1348/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Do accounting of total blocks and ignores, not just blocks and ignores caused by
current entries
Index:
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv19782/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Whee, nothing important, just kinda a 'key' for the page.
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv27598/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
After talking to zab, make DNFs on things in the failure table even less likely to
actually affect routing.
Index:
Toad moderates it and passes through valid mail, so unsub'd mails will
just take till toad gets to em to get on the list.
--B
On Mon, 11/03/03 at 23:20:38 -, Dave Hooper wrote:
Hm, so some of my emails are being duplicated. Part of the problems
definitely at my end :-) but the ones From
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv25689/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Add support for FailureEntrys w/o FailItems which are there for ignoring DNFs only.
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv7338/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
6300:
The removal of the functional checkpointing code in the FailureTable made things
_very_ unhappy, so I put it back.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv7338/freenet/src/freenet
Modified Files:
Version.java
Log Message:
6300:
The removal of the functional checkpointing code in the FailureTable made things
_very_ unhappy, so I put it back.
This may not
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv8309/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Oops, had cleaning time = failureTableTime not failureTableTime/10
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv27916/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
**stupid**
Index: FailureTable.java
===
RCS file:
The first commit of 6300 was messed up, I didn't properly fix the high
cpu usage bug. The next time the snapshot updates, please try again,
and it should go back to where it was for 6296.
--Brandon
On Sun, 11/02/03 at 21:27:44 -0600, Tom Kaitchuck wrote:
I'm seeing my cpu load maxed out on
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv23587/freenet/src/freenet/node
Modified Files:
FailureTable.java
Log Message:
Make the HTML reflect the internal structure and hopefully a little easier on browsers.
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv10035/node/states/request
Modified Files:
DataPending.java
Log Message:
Fix a little NPE to do with the SFT
Index: DataPending.java
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv15561/freenet
Modified Files:
Version.java
Log Message:
Fix ConcurrentModificationException in new FailureTable, up version for this and the
NPE I just fixed
Index: Version.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv15561/freenet/node
Modified Files:
FailureTable.java
Log Message:
Fix ConcurrentModificationException in new FailureTable, up version for this and the
NPE I just fixed
Index: FailureTable.java
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv5461/src/freenet/node/rt
Modified Files:
ResponseTimeEstimator.java
Log Message:
Fix an NPE in the Peer html stuff
Ensure that ResponseTimeEstimators always have a recent, not positive this fix
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv5461/src/freenet
Modified Files:
OpenConnectionManager.java Version.java
Log Message:
Fix an NPE in the Peer html stuff
Ensure that ResponseTimeEstimators always have a recent, not positive this fix is
Well this is hard to diagnose, but thus far, I've seen no reports of
problems with thread factory w/o the wait(timeout)... I'm inclined to
think that the JVMs were only having problems when the waitsets were
rapidly being screwed with, as in 10s of thousands of threads being
created and deleted
That juts means it retried on a different route... and the new route
happened to have the data right there.
--Brandon
On Tue, 10/28/03 at 10:57:07 -0800, Doug Bostrom wrote:
This seemed rather odd to me, but perhaps it's normal?
Retrieving this key:
[EMAIL PROTECTED]/magick/1//?htl=15
Toad, I think that Niklas knows how to set the protocol version back
down, dude... no need to yell ;-)
--B
On Tue, 10/28/03 at 01:35:52 +, Toad wrote:
On Mon, Oct 27, 2003 at 08:27:02AM +0100, Niklas Bergh wrote:
I recently upgraded my stable network node from build 6251 to 6281 (+some
On Wed, 10/22/03 at 22:58:20 -0700, Martin Stone Davis wrote:
To get on the new network, you'd have to do it intentionally: download
unstable.ref and overwrite your seednodes.ref. Furthermore, I'm not
sure how a network fork relates to privacy issues.
Initially, if people running unstable
Read before writing.
6266 and greater are designed to use a separate network to test
NGRouting's behaviour when it isn't sharing network space with
non-ngrouting.
--Brandon
On Thu, 10/23/03 at 01:54:48 +0200, Matthias wrote:
Don't upgrade to 6269, it wiped out my routing table and the node
ask you to stay
any longer.
--Brandon
On Thu, 10/23/03 at 02:05:23 +0200, Matthias wrote:
Brandon Low schrieb:
Read before writing.
Where has this been written, I don't see it the page or the mailing lists.
6266 and greater are designed to use a separate network to test
NGRouting's
My node didn't OOM overnight, but it is up to 320M of memory in use when
'normally' it uses 140M... also, first 2 hrs it was up only used about
80 threads, is up to 197 now... will be in the channel around 3:30-4:30
GMT.
--Brandon
On Wed, 10/15/03 at 09:27:42 +0200, Niklas Bergh wrote:
Now,
On Wed, 10/15/03 at 20:26:06 +0100, Toad wrote:
Current unstable - stable merge first, then multiplexing on unstable
branch with a split network between unstable and stable might be one way
to handle this.
If the unstable code is likely to become good enough to merge before
multiplexing
I believe that pcaching applies to local requests too... so why not just
let freenet take care of itself and stick to plausible deniability? You
could just have been the first person in line for the insertion of said
key or whatever...
--B
On Wed, 10/15/03 at 18:14:21 -0700, Martin Stone Davis
For Gentoo users, I have an init script which starts freenet as user and
group freenet after first setting the ulimit to 4096. it might be
advisable to provide instructions on this to users...
I do however think that freenet uses too many FHs for the datastore
sometimes.
--Brandon
On Mon,
On Fri, 10/03/03 at 19:15:52 +0100, Toad wrote:
On Sun, Sep 28, 2003 at 07:58:48AM -0700, Brandon Low wrote:
Modified Files:
OpenConnectionManager.java
Log Message:
Fix deadlock in the changes moving sync(lru) outside of KillSurplusConnections.
No more deadlocks, and since we now
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv27806
Modified Files:
Version.java
Log Message:
6212:
Niklas: better catching for bad DSASignatures
- Backout unneeded logging change from 6211
Brandon: 2 more QThreadFactory changes
- Don't
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv27806/thread
Modified Files:
QThreadFactory.java
Log Message:
6212:
Niklas: better catching for bad DSASignatures
- Backout unneeded logging change from 6211
Brandon: 2 more QThreadFactory
Hmm... *diffs 6205 and 6209*
I'll see if I can figure anything else out.
On Sun, 09/28/03 at 00:46:09 -0500, Salah Coronya wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brandon Low wrote:
| Threadlimits probably aren't the issue any more, can you check how many
| queries per minute
://lostlogicx.com/transfer/freenet-6205-6209.diff
--Brandon
On Sun, 09/28/03 at 02:07:42 -0400, Edward J. Huff wrote:
On Sun, 2003-09-28 at 01:59, Brandon Low wrote:
Hmm... *diffs 6205 and 6209*
I'll see if I can figure anything else out.
Could it be the change I put it to be slightly
freenet.ini as follows:
# The maximum number of outgoing connections established per
maxRequestsInterval.
maxRequestsPerInterval=3000
I'll let you know what happens.
-Martin
Salah Coronya wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brandon Low wrote:
| Threadlimits
I think toad told me those are basically RNFs, but I'm not sure ...
toad?
--B
On Sun, 09/28/03 at 08:43:38 +0200, Niklas Bergh wrote:
08:07:47Did not terminate [EMAIL PROTECTED]
(22d0edba9857bd4ad47c5a5a94e9e8fa92b5a265140302,request)null
08:07:47Did not terminate [EMAIL PROTECTED]
, Brandon Low wrote:
Hmm... I just noticed that in the version of your patch that I have at
least, the creator thread can have both countLock and headLock at the
same time, I tried to avoid any one thread grabbing more than one lock
at the same time... is that possible?
Ahh, I see if we
Ahh, I implimented one of toad's suggestions for KillSurplusConnections
(sync lru the whole thing) without thinking enough, moved the sync lru
back inside the function so that it can't deadlock. Will commit when
CVS starts listening to me again.
--Brandon
On Sun, 09/28/03 at 05:02:10 -0400,
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv24593/freenet
Modified Files:
OpenConnectionManager.java
Log Message:
Fix deadlock in the changes moving sync(lru) outside of KillSurplusConnections. No
more deadlocks, and since we now remove from lru
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv25393/freenet
Modified Files:
Version.java
Log Message:
Up version for deadlock fix
Index: Version.java
===
RCS file:
How much ram does your box have? My freenet runs at about 200M most of
the time to be 'comfortable' so the fact that it OOM'd when only being
allowed to use ~128M doesn't surprise me... if your box has at least
384M of ram, try running freenet with -Xmx256M.
--Brandon
On Sun, 09/28/03 at
sounds great! Strangely (very strangely) my node on 6211 hasn't started
leaking memory yet, and it has been up for 7 hours... wonder if
something automagically fixed that issue or something...
Anywho, if we can resolve the memory leak issue and have code that works
for 24 hour uptime then it is
Yeah, limiting don't work none here either :-D Seems like the async
trailer sends don't manage to get fully accounted for in bwlimiting or
something... hopefully toad will work on this tomorrow.
--B
On Sun, 09/28/03 at 23:47:55 -0400, Edward J. Huff wrote:
I have been saving bandwidth data ever
Ok, so I'm reading QThreadFactory ONE MORE TIME... There may be a
problem, we might _want to_ overestimate available during create thread,
return thread, but then underestimate it in destroy thread and get
thread, because of the following: what happens if by (relatively
impossible, but it is
Here is a proposed patch, tell me what you think.
(note this also goes back to wait(1000) once every loop of the creation
thread, I did this to ensure that one call to awaken() will _always_ put
the thread in creation mode.
--Brandon
On Sat, 09/27/03 at 10:47:30 -0500, Brandon Low wrote:
Ok
Not sure why this wouldn't have happened on older freenet build, but
freenet uses a LOT of http connections, you will probably need to set
your mozilla network.http.maxconnection (and related variables) to
higher values (I use 512 for max-connections I think) so that mozilla
can handle freenet.
Oh yeah, those options are in about:config
Zoiks
On Sat, 09/27/03 at 15:42:26 -0500, Brandon Low wrote:
Not sure why this wouldn't have happened on older freenet build, but
freenet uses a LOT of http connections, you will probably need to set
your mozilla network.http.maxconnection
I can provide some of these things... I have just about enough hardware
to run it (athlon-xp-1800) and can probably upgrade that to
dual-athlon-mp-2400 (or higher) in the near future... with 1g of ram...
I know nothing about site publishing on freenet, but I know freenet and
java, what I lack the
it will be
till the web interface loads on the second tab. I'm still waiting
after 5 minutes
-Martin
Brandon Low wrote:
Not sure why this wouldn't have happened on older freenet build, but
freenet uses a LOT of http connections, you will probably need to set
your mozilla
Threadlimits probably aren't the issue any more, can you check how many
queries per minute your node is accepting? There is a default in the
config file to only accept a max of 300 queries per minute, is it
possible that that is the limit you are hitting?
Also, it is possible that inserts are
PROTECTED] On Behalf Of Ed Tomlinson
Sent: den 26 september 2003 13:03
To: Brandon Low
Cc: [EMAIL PROTECTED]
Subject: Re: [freenet-dev] [PATCH] [JAR] More locking fixes (BIG ONE)
Hi,
Looks like something is not quite right in 6208. I am seeing
_lots_ of
these errors
Ok, the promised thread dump is here. (Freenet actually worked, and 25
minutes after he inserted it, I had it!)
This dump shows Suplus connection killing thread in an exception that
doesn't make sense to me, but hopefully someone out there who know more
about Java than I do can give me a hand.
Oh, my thought is that it might have to do with candidates not being
removed from LRU if they are selected for termination?
--Brandon
On Fri, 09/26/03 at 12:23:50 -0500, Brandon Low wrote:
Ok, the promised thread dump is here. (Freenet actually worked, and 25
minutes after he inserted it, I
Wait... now it seems that something between the patch I posted here and
what was marked 6208 in CVS fixed it.
--Brandon
On Fri, 09/26/03 at 12:26:07 -0500, Brandon Low wrote:
Oh, my thought is that it might have to do with candidates not being
removed from LRU if they are selected
Not deadlocked but close... 10s of threads blocked on one lock and the
like, this is now fixed in 6208, try it out... or wait for 6209 (in
about 20 minutes if all goes well)
--Brandon
___
Devl mailing list
[EMAIL PROTECTED]
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv24104/src/freenet
Modified Files:
ConnectionHandler.java OpenConnectionManager.java
Log Message:
Move KillSurplusConnections back out of a thread, but do it smarter. We will now keep
a queue of closed
The attached patch makes minor changes to QThreadFactory and
OpenConnectionManager to attempt to make it easier to share
contested locks.
In OCM I wasn't able to do as much as I had hoped, but using
a little bit of logic, I changed the order of if statements
and whatnot to try and shorten the
Ok, I think I've nailed down all of the remaining locking issues which
were plaguing my node. Last time I dumped threads there was only 1 out
of over 200 that was waiting for a monitor. This is a pretty extreme
patch, as it moves KillSurplusConnections to a daemon thread, and
completely redoes
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv22073/src/freenet
Modified Files:
OpenConnectionManager.java
Log Message:
More locking improvements.
-Moved KillSurplusConnections to a thread of it's own, this is in the hopes of
reducing contention
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv22073/src/freenet/thread
Modified Files:
QThreadFactory.java
Log Message:
More locking improvements.
-Moved KillSurplusConnections to a thread of it's own, this is in the hopes of
reducing
I probably shouldn't do this again, but I've made a build available on
my webserver which is from the latest CVS at the time of this writing.
That means it is 6205 + Blacklisting of bad node connections + No long
locking on lru in OCM thanks to Edward.
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv8958/src/freenet/thread
Modified Files:
QThreadFactory.java
Log Message:
Finer grained locking for Thread creation thread, this smooths out CPU and BW usage a
_lot_ because now if there is a
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv9492/src/freenet
Modified Files:
Version.java
Log Message:
Up version for Edward's fix, and my two fixes. These all go a long way toward fixing
CPU usage issues.
Index: Version.java
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv13618/src/freenet
Modified Files:
Version.java
Log Message:
6207:OK, so I was a bit hasty with my last Thread creation thread fix. This one makes
much better use of the pools of available threads and
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv13618/src/freenet/thread
Modified Files:
QThreadFactory.java
Log Message:
6207:OK, so I was a bit hasty with my last Thread creation thread fix. This one makes
much better use of the pools of
I get a build error on this:
[javac] /home/lostlogic/freenet/src/freenet/DSAIdentity.java:64:
variable hashed might already have been assigned
[javac] hashed = makeHashCode();
--Brandon
On Tue, 09/23/03 at 18:21:34 -0700, Edward J. Huff wrote:
Update of
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv16563
Modified Files:
DSAIdentity.java
Log Message:
Minor fix for Edward's stuff... (can't make hash code twice...)
Index: DSAIdentity.java
Good work on that... seems to make a noticible performance improvement
to my node... Definitely reduces the computational cost of connections.
--Brandon
On Tue, 09/23/03 at 21:49:53 -0400, Edward J. Huff wrote:
Zlatin Balevsky [EMAIL PROTECTED] posted a stack dump.
I looked at it, and
Update of /cvsroot/freenet/freenet/src/freenet/transport
In directory sc8-pr-cvs1:/tmp/cvs-serv17715/freenet/transport
Modified Files:
tcpAddress.java
Log Message:
Blacklist connections who are rapidly failing a lot, this should help with a lot of
the CPU overload on 6205, also fix the
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv17715/freenet
Modified Files:
ConnectionHandler.java OpenConnectionManager.java Peer.java
Log Message:
Blacklist connections who are rapidly failing a lot, this should help with a lot of
the CPU
Update of /cvsroot/freenet/freenet/src/freenet/support
In directory sc8-pr-cvs1:/tmp/cvs-serv17928/freenet/support
Added Files:
BlackLRUQueue.java
Log Message:
Forgot a file from last commit
--- NEW FILE: BlackLRUQueue.java ---
package freenet.support;
import java.util.Enumeration;
I've got an even more interesting one... once in a while my node goes
100% CPU and almost all the threads are in QThreadFactory.returnThread()
explain that one why doncha!
--Brandon
On Mon, 09/22/03 at 21:58:02 -0400, Zlatin Balevsky wrote:
I had a ~5 minute 100% cpu spike with latest cvs
Not sure how this is as far as correct ways to fix things, but the
attached patch is one potential way to fix the problems which we've been
having with excessive connections being opened all the time on recent
builds.
Applies to 6205 code.
Impliments a BlackListQueue by modifying LRUQueue to
-0500, Brandon Low wrote:
Not sure how this is as far as correct ways to fix things, but the
attached patch is one potential way to fix the problems which we've been
having with excessive connections being opened all the time on recent
builds.
Applies to 6205 code.
Impliments
1 - 100 of 107 matches
Mail list logo
