You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jann Horn (JIRA)" <ji...@apache.org> on 2013/05/22 11:23:20 UTC
[jira] [Commented] (COUCHDB-1761) Couchdb does lots of useless
syscalls
[ 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