couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jann Horn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1761) Couchdb does lots of useless syscalls
Date Wed, 22 May 2013 09:23:20 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663958#comment-13663958
] 

Jann Horn commented on COUCHDB-1761:
------------------------------------

This is a problem in the erlang core, e.g. see {noformat}erts/emulator/beam/erl_process.c{noformat}.
It contains things like a loop that spins {noformat}ERTS_SCHED_SYS_SLEEP_SPINCOUNT=10{noformat}
times (in other words, busyloops) before going to sleep for a little while. Closing the ticket
here as it doesn't seem to be a CouchDB-specific issue.
                
> Couchdb does lots of useless syscalls
> -------------------------------------
>
>                 Key: COUCHDB-1761
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1761
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>            Reporter: Jann Horn
>
> Try running a fresh couchdb with no replication jobs or so like this:
> {code}strace -tt -f utils/run{code}
> Don't connect to it or anything, just let it run. I'm seeing output like this:
> {code}
> [pid 18350] 17:40:15.086577 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086610 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086643 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086675 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086736 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086771 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.086940 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.087180 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.087219 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.087251 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.087287 epoll_wait(3, {}, 256, 228) = 0
> [pid 18350] 17:40:15.315646 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315718 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315751 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315800 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315833 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315865 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315900 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315953 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.315992 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.316081 epoll_wait(3, {}, 256, 651) = 0
> [pid 18350] 17:40:15.967979 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.969211 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.969926 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970484 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970616 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970717 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970806 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970895 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.970983 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.971071 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.971158 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.971243 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:15.971343 epoll_wait(3, {}, 256, 345) = 0
> [pid 18350] 17:40:16.316908 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.317266 epoll_wait(3, {}, 256, 650) = 0
> [pid 18350] 17:40:16.969333 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.970057 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.970580 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.970736 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.970827 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.970917 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971011 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971118 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971206 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971300 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971386 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:16.971485 epoll_wait(3, {}, 256, 115) = 0
> [pid 18350] 17:40:17.087042 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.087421 accept(10, 0x7fb208dbfba0, [28]) = -1 EAGAIN (Resource temporarily
unavailable)
> [pid 18350] 17:40:17.087915 epoll_ctl(3, EPOLL_CTL_DEL, 10, {EPOLLIN, {u32=10, u64=73199780460757002}})
= 0
> [pid 18350] 17:40:17.088035 epoll_ctl(3, EPOLL_CTL_ADD, 10, {EPOLLIN, {u32=10, u64=73199780460757002}})
= 0
> [pid 18350] 17:40:17.088139 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088231 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088327 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088477 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088565 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088660 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088746 epoll_wait(3, {}, 256, 0) = 0
> [pid 18350] 17:40:17.088833 epoll_wait(3, {}, 256, 0) = 0
> {code}
> Why is couchdb calling epoll_wait so often with a timeout of 0? Why does it remove an
entry from the watched set, then immediately re-add it?
> I have started looking at couchdb's syscalls because a couchdb instance on my computer
uses 2-4% CPU while it should be idle. It's not a big issue, but it shouldn't be that way,
I think.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message