Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-2114

Don't use select timeouts for fast coarse timing

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Networking
    • Environment:
      64 bit Ubuntu 10.10
    • Fully Compatible
    • Linux
    • Platforms 16 (06/24/16)
    • 0

      The mongod process causes wakeups 100 times per second as can be seen by calling strace on the process. This is done by calling having a one hundredth of a second timeout on a select call on the listening socket. These wakeups increase power consumption and utilization on virtual machines. It should be noted that this happens all the time even if there are no connections or any other activity happening. Powertop will consistently show mongod as a top offender. An explanation on the mailing list was given:

      > 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.

      Linux has has a system call for a number of years for getting a timer value - clock_gettime. Except for ancient 32 bit hardware this call is implemented using the VDSO mechanism - a page the kernel maps into process memory. clock_gettime is implemented without there being a system call at all! Heck they even added "a somewhat coarse timer that is as fast as possible"! http://lwn.net/Articles/342018/

      You should be able to replace the timeouts and variable they were updating with calls to clock_getttime.

        1. mongo-timer-fix-v1.patch
          6 kB
          Calvin Owens
        2. mongo-timer-fix-v3.patch
          6 kB
          Calvin Owens
        3. mongo-timer-fix-v4.patch
          7 kB
          Calvin Owens

            Votes:
            36 Vote for this issue
            Watchers:
            48 Start watching this issue

              Created:
              Updated:
              Resolved: