Constant polling of mongod

[Roger Binns]

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

Is there any particular reason mongod does constant polling? This is a
freshly started daemon with no connections:

select(8, [5 7], NULL, NULL, {0, 10000}) = 0 (Timeout)
select(8, [5 7], NULL, NULL, {0, 10000}) = 0 (Timeout)
select(8, [5 7], NULL, NULL, {0, 10000}) = 0 (Timeout)

ie it is doing this select with a 0.01 second timeout, or that call happens
100 times per second. lsof shows 5 and 7 are these:

mongod 5443 mongodb 5u IPv4 72572 0t0 TCP *:27017
(LISTEN)
mongod 5443 mongodb 7u unix 0xffff880199f2e4c0 0t0 72574
/tmp/mongodb-27017.sock

Official 10gen package of mongodb-stable 1.6.3 on 64 bit Ubuntu 10.10.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky+e1UACgkQmOOfHg372QR8/gCff4Ur/QfFNktd5koqROb04FHF
vXMAoJVQw23pHXZvqhaDD/T3PiBzhAWj
=cQTN
-----END PGP SIGNATURE-----

[Eliot Horowitz]

Yes - there are a few.
One main reason is we need a somewhat coarse timer that is as fast as possible.
So we use this one loop for incrementing that counter.
This is much faster than using any system call for getting wall time.

> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>

[Roger Binns]

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

On 10/19/2010 10:21 PM, Eliot Horowitz wrote:
> Yes - there are a few.
> One main reason is we need a somewhat coarse timer that is as fast as possible.
> So we use this one loop for incrementing that counter.
> This is much faster than using any system call for getting wall time.

Any chance it can be throttled back when there is less or no activity? The
main annoyance is using my development laptop and we also have some demo
systems using laptops. This is not production but it does show up as the
top offender in powertop. For virtualized environments it also creates
overhead and isn't likely to be that accurate.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky+iGsACgkQmOOfHg372QQudQCfXaiLMLjJcpEVffUx1R+auxJc
YE4AnRHQRPqRrT0+GW+cvVZRpJ+wXLUv
=XdwU
-----END PGP SIGNATURE-----

[Axel Kittenberger]

>
> Yes - there are a few.
> One main reason is we need a somewhat coarse timer that is as fast as
possible.
> So we use this one loop for incrementing that counter.
> This is much faster than using any system call for getting wall time.

Couldn't you just set the coarse time using clock() everytime an infinite select
returns? It returns a plain linux kernel konstant, so sure is one of the fastest
kernel calls around. Sounds to me more efficient and more exact than polling
select() everytime.

The other direction would be, how course can this coarse timer become? Wouldn't
it sufficide if its always incrementing? Then increment it by 1 every time
select() runs through, again no need for 10ms polling, if there is nothing
happing why should the course timer increment?

Kind regards, Axel

Eliot Horowitz <eliothorowitz@...> writes:

[Stephen Steneker]

On Saturday, July 14, 2012 2:48:53 AM UTC+10, Axel Kittenberger wrote:

Couldn't you just set the coarse time using clock() everytime an infinite select
returns? It returns a plain linux kernel konstant, so sure is one of the fastest
kernel calls around. Sounds to me more efficient and more exact than polling
select() everytime.

The other direction would be, how course can this coarse timer become? Wouldn't
it sufficide if its always incrementing? Then increment it by 1 every time
select() runs through, again no need for 10ms polling, if there is nothing
happing why should the course timer increment?

Hi Axel,

This is the same issue you've raised before (and commented on in Jira):
  https://jira.mongodb.org/browse/SERVER-2114

At the moment this issue only has 10 votes, so is rather far down the list of popular issues to address:
 https://jira.mongodb.org/browse/SERVER#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel 

If you have a better approach you could always test/benchmark a patch and submit a pull request for consideration ;-).

Cheers,

Stephen