четверг, 30 апреля 2015 г., 21:53:30 UTC+6 пользователь Nikolaus Rath написал: > > > I was transfering files with tar c|dd|ssh s3qluser@s3ql_host tar xC > > /s3ql_mount kill -USR1 $dd_pid shows the speed. It starts from 5M/sec > > and falls to 5k/s or even freeze. > > Well, did it fall to 5 k/s or did it freeze? > dd shows 5k/s If i did s3qlctrl flushcache then according to precise size of transferred its freeze.
> >> I see almost 16 connections with s3 servers, but tcpdump shows small > >> rate > >> > of uploading PUTs. > >> > >> What do you mean with small? What do you expect it to be, and what did > >> you find instead? > >> > > 200 bytes - 1k per file. > > The dirty size was big (1-2GiB). > > No, I was talking about the small rate of PUTs that you saw in tcpdump. > > If we assume about 100 ms network latency, then with 200 byte files > you'd be able to transfer at most 200 bytes / 100 ms = 2 kB/s for each > active thread. So your 5 kb/s isn't completely the wrong order of > magnitude. > > I would expect that the initial fast period is just when you file up > your cache. Am I right that, if you set the cache to something small > (say 2 * <number of threads> entries), you're getting a constant > transfer rate from the very beginning? > > In tcpdump, how many PUTs do you see per second? Is that number constant? > All right, but why only 16 threads were transferring? > > >> How did you determine that? > > > > strace -fp $mount.s3ql_pid showed many FUTEX messages. > > I think that doesn't mean that there's lock contention, just that locks > are being used. > Ok. 256 threads are running much nicely -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
