Let's see if this helps. It is from a test run that took less than 5 
seconds, where I downloaded 100 files *one at a time*. There should not be 
much contention here, and it is very strange that only 9 calls to futex can 
spin so much. Any ideas?

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.94    4.150578      461175         9         1 futex
  0.01    0.000599           5       119           mmap
  0.01    0.000550           6        85           mprotect
  0.01    0.000354           9        40           read
  0.01    0.000247           6        41           open
  0.00    0.000190           5        42        42 access
  0.00    0.000140           3        41           fstat
  0.00    0.000125           3        42           close
  0.00    0.000065          22         3           clone
  0.00    0.000031           5         6           brk
  0.00    0.000019           5         4           munmap
  0.00    0.000014           5         3           clock_gettime
  0.00    0.000012           6         2           eventfd2
  0.00    0.000012           6         2           pipe2
  0.00    0.000007           2         4           write
  0.00    0.000007           4         2           rt_sigaction
  0.00    0.000005           5         1           epoll_create1
  0.00    0.000004           4         1           rt_sigprocmask
  0.00    0.000004           4         1           execve
  0.00    0.000004           4         1           getrlimit
  0.00    0.000004           4         1           set_tid_address
  0.00    0.000003           3         1           arch_prctl
  0.00    0.000003           3         1           set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00    4.152977                   452        43 total


On Monday, March 24, 2014 11:00:11 AM UTC-7, Damián Lezama wrote:

> Let me see what I can do about collecting strace data or sharing code. I 
> wonder if you had some profiling/metrics to know how to expect. I'm writing 
> to the disk as fast as I can (in my setup network is not the bottleneck, 
> the disk is), and I'm writing in quite small chunks (16k because of 
> libcurl).
>
> On Friday, March 21, 2014 11:23:05 AM UTC-7, Fedor Indutny wrote:
>>
>> Hi! 
>>
>> I'm afraid it is hard to say what's going on without taking a look at 
>> actual implementation. Is it opensource? 
>>
>> If not - could you please provide `strace` output of your program 
>> execution? 
>>
>> Cheers, 
>> Fedor. 
>>
>> On Fri, Mar 21, 2014 at 10:20 PM, Damián Lezama <[email protected]> 
>> wrote: 
>> > Hi, 
>> > 
>> > I have a prototype that downloads multiple files at the same time with 
>> libuv 
>> > and libcurl. On my tests with very high bandwidth, the main loop thread 
>> gets 
>> > close to 100% CPU usage, while every thread pool thread is at about 20% 
>> or 
>> > 30%. If I run my prototype using the time command, I get very high 
>> system 
>> > time. If I remove the file system operations and just download and 
>> discard 
>> > the data, the CPU usage is very low and libcurl and libuv do a great 
>> job. 
>> > What may be going on here? 
>> > 
>> > Thanks, 
>> > Damian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "libuv" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to [email protected]. 
>> > To post to this group, send email to [email protected]. 
>> > Visit this group at http://groups.google.com/group/libuv. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to