Re: [GNUnet-developers] high disk-io

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 April 2004 09:57 am, Christian wrote:
>  I saw this was a subject allready before. Since in my case gnunetd often
> got really agressive on the disk for hours i started to spread debug
> messages accross the manager, routing and migration code.
>
> There are many points which i just assume gnunet-behaviour so please
> correct me if somethings wrong. Whenever a package is about to leave the
> node it will be checked for padding space (up to MTU of the transport). If
> that space is bigger than about 1K (i guess less doesnt make sense) we
> start to pick random content to fill in that gap. (activeMigration) This
> data seems to be really random and not picked up as a linear stream or from
> a buffer. According to what i see in my logfile most disk io is generated
> by migration (roughly 80% i guess). Since many things are indexed here
> there is lots of on-demand encoding. But i dont think this is much
> different to inserted content at this point. (is it?) Now i had gnunetd
> running just for a couple of minutes with the debug output but i think it
> will not change much over the time.

Your description of what is going on is correct.  I find it interesting that 
80% of disk IO is activemigration, I had suspected it would be much less (but 
I don't have any numbers and you do :-).  Which gives us an interesting 
handle on the issue (if true in general).

> Conditions under which gnunetd is running here:
> MySQL (1024MB)
> free sais 100MB cached (its a small machine)
> 90000 (set as up & down bandwidth in config file)
>
>  I think there should be similar way of control be used for disk-io like
> for CPU and network load. To reduce padding at first and if it is not
> enough to reduce even query lookups.

Actually, there is one additional possibility, which is to make the disk-io 
less random.  If, for example, we gather more than just one block at a time 
from a file and instead read a dozen or two (possibly in sequence), that does 
not increase IO much but improves throughput dramatically.  The bad news is 
that it also makes deniability worse since chances of a peer that does not 
have the file pushing out closely related blocks from a presumably 'random' 
assembly of migrated blocks are low.  Anyway, together with the buffering of 
content by the active-migration thread (may cost memory) it should be 
possible to achieve an acceptable trade-off that can still be better than 
just not doing migration.

But for all three approaches to lower IO, we first need some code to measure 
how much (actual) IO is going on -- otherwise the code would not know when to 
throttle.

Thanks for the data-point, I'll definitely keep it in mind (though I have my 
doubts that it holds for machines with less bandwidth, but then again, those 
may also not have problems with the IO load...)

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAcZg69tNtMeXQLkIRAr1XAJwO413CReopA9PitvmTldplQ7Hx6ACaAtNm
qHcvl3PA+XnRBfUnLUa31UE=
=6ZCj
-----END PGP SIGNATURE-----