rpcsvchost using 99% CPU !!

Discussion in 'OS X Mavericks (10.9)' started by the bug, Sep 24, 2014.

  1. the bug macrumors member

    the bug

    Joined:
    Feb 21, 2014
    #1
    On my mid 2010 Mac Mini running 10.9.5 I noticed that every time I cold boot it the process "rpcsvchost" is using 99% of the CPU in activity monitor.

    Most times rebooting takes care of it, until it sits powered off overnight, then on the first boot up it is back to eating 99% again.

    I have reset SMC and PRAM, turned off all unnecessary items but it still continues.

    I've searched online and found a few others that have had the same problem, but haven't found any answers.

    Any advice would be appreciated, since I think my next step may be re-loading Mavericks.

    Thanks in advance for any help.

    - Jay
     
  2. the bug, Sep 25, 2014
    Last edited: Sep 25, 2014

    the bug thread starter macrumors member

    the bug

    Joined:
    Feb 21, 2014
    #2
    Wow, almost 100 views and nobody else has seen this.
    Here's a little more info :
    I reinstalled Mavericks last night and it seemed better after a couple of reboots, then today rpcsvchost was back up to using 99%.
    It's running as root, so I don't think it's a startup item from any particular account.

    Only a couple of entries in the console about it, I will post those and a spindump log below.

    Very strange that it is only after it has been sitting off for a while.

    - Jay

    _____________________

    9/25/14 6:31:25.000 PM kernel[0]: process rpcsvchost[89] thread 692 caught burning CPU! It used more than 50% CPU (Actual recent usage: 62%) over 180 seconds. thread lifetime cpu usage 90.015346 seconds, (71.342635 user, 18.672711 system) ledger info: balance: 90007778831 credit: 90007778831 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 143033006696

    ______________________________________________________

    9/25/14 6:31:28.915 PM spindump[290]: Saved cpu_resource.spin report for rpcsvchost version ??? (???) to /Library/Logs/DiagnosticReports/rpcsvchost_2014-09-25-183128_UpstairsMini.cpu_resource.spin

    _______________________________________________________

    Date/Time: 2014-09-25 18:28:59 -0400
    OS Version: 10.9.5 (Build 13F34)
    Architecture: x86_64
    Report Version: 18

    Command: rpcsvchost
    Path: /usr/libexec/rpcsvchost
    Version: ??? (???)
    Parent: launchd [1]

    PID: 89
    Event: cpu usage (microstackshots only)
    Thread: 0x2b4 (62% cpu over 146 seconds)
    Duration: 146.00s
    Steps: 98

    Hardware model: Macmini4,1
    Active cpus: 2
    Fan speed: 1800 rpm


    Powerstats for: rpcsvchost [89] thread 0x2b4
    Start time: 2014-09-25 18:29:54 -0400
    End time: 2014-09-25 18:31:25 -0400
    Parent: launchd
    Microstackshots: 76 samples (77%)
    Primary state: 59 samples Non-Frontmost App, Non-Background Priority, User mode
    User Activity: 0 samples Idle, 76 samples Active
    Power Source: 0 samples on Battery, 76 samples on AC
    76 thread_start + 13 (libsystem_pthread.dylib) [0x7fff90865fc9]
    76 _pthread_start + 137 (libsystem_pthread.dylib) [0x7fff9086172a]
    76 _pthread_body + 138 (libsystem_pthread.dylib) [0x7fff90861899]
    76 proxy_start + 57 (DCERPC) [0x10782baa1]
    67 timer_loop + 239 (DCERPC) [0x10785b439]
    65 dcethread_cond_timedwait_throw + 11 (DCERPC) [0x10782d4f7]
    31 dcethread_cond_timedwait + 111 (DCERPC) [0x10782d496]
    28 __gettimeofday + 10 (libsystem_kernel.dylib) [0x7fff852e11cb]
    17 <Kernel mode>
    2 _pthread_cond_wait + 142 (libsystem_pthread.dylib) [0x7fff908639f2]
    1 _pthread_testcancel + 56 (libsystem_pthread.dylib) [0x7fff90862929]
    1 DYLD-STUB$$OSSpinLockLock + 6 (libsystem_pthread.dylib) [0x7fff9086610a]
    1 _pthread_cond_wait + 154 (libsystem_pthread.dylib) [0x7fff908639fe]
    15 dcethread_cond_timedwait + 85 (DCERPC) [0x10782d47c]
    6 dcethread__begin_block + 149 (DCERPC) [0x10782d073]
    5 dcethread__unlock + 32 (DCERPC) [0x10782cbfe]
    5 pthread_mutex_unlock + 60 (libsystem_pthread.dylib) [0x7fff908648f3]
    2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    2 __mtx_droplock + 590 (libsystem_pthread.dylib) [0x7fff9086450c]
    1 __mtx_droplock + 615 (libsystem_pthread.dylib) [0x7fff90864525]
    1 dcethread__debug_set_callback + 20 (DCERPC) [0x10782c0b5]
    5 dcethread__begin_block + 141 (DCERPC) [0x10782d06b]
    1 _pthread_cond_signal + 144 (libsystem_pthread.dylib) [0x7fff9086374a]
    1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    1 _pthread_cond_signal + 39 (libsystem_pthread.dylib) [0x7fff908636e1]
    1 _pthread_cond_check_init + 6 (libsystem_pthread.dylib) [0x7fff90863ce9]
    1 _pthread_cond_signal + 52 (libsystem_pthread.dylib) [0x7fff908636ee]
    1 _pthread_cond_signal + 227 (libsystem_pthread.dylib) [0x7fff9086379d]
    4 dcethread__begin_block + 38 (DCERPC) [0x10782d004]
    3 dcethread__lock + 18 (DCERPC) [0x10782cb05]
    1 _pthread_mutex_lock + 565 (libsystem_pthread.dylib) [0x7fff9086483a]
    1 pthread_mutex_unlock + 223 (libsystem_pthread.dylib) [0x7fff90864996]
    1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    1 dcethread__lock + 89 (DCERPC) [0x10782cb4c]
    13 dcethread_cond_timedwait + 144 (DCERPC) [0x10782d4b7]
    6 dcethread__end_block + 28 (DCERPC) [0x10782d12c]
    4 dcethread__lock + 18 (DCERPC) [0x10782cb05]
    2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    1 _pthread_mutex_lock + 229 (libsystem_pthread.dylib) [0x7fff908646ea]
    1 _pthread_mutex_lock + 51 (libsystem_pthread.dylib) [0x7fff90864638]
    1 pthread_threadid_np + 30 (libsystem_pthread.dylib) [0x7fff90861b43]
    1 dcethread__lock + 53 (DCERPC) [0x10782cb28]
    1 dcethread__lock + 65 (DCERPC) [0x10782cb34]
    1 dcethread__sanity + 112 (DCERPC) [0x10782cd25]
    4 dcethread__end_block + 96 (DCERPC) [0x10782d170]
    3 dcethread__unlock + 32 (DCERPC) [0x10782cbfe]
    1 pthread_mutex_unlock + 217 (libsystem_pthread.dylib) [0x7fff90864990]
    1 pthread_mutex_unlock + 75 (libsystem_pthread.dylib) [0x7fff90864902]
    1 pthread_mutex_unlock + 60 (libsystem_pthread.dylib) [0x7fff908648f3]
    1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    1 dcethread__unlock + 15 (DCERPC) [0x10782cbed]
    1 dcethread__sanity + 101 (DCERPC) [0x10782cd1a]
    2 dcethread__end_block + 88 (DCERPC) [0x10782d168]
    2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
    1 dcethread__init_self + 75 (DCERPC) [0x10782caf3]
    3 dcethread_cond_timedwait + 59 (DCERPC) [0x10782d462]
    2 dcethread__self + 25 (DCERPC) [0x10782ca64]
    1 pthread_once + 87 (libsystem_pthread.dylib) [0x7fff90862893]
    1 dcethread__self + 37 (DCERPC) [0x10782ca70]
    2 dcethread__new + 145 (DCERPC) [0x10782ca4b]
    1 dcethread_cond_timedwait + 114 (DCERPC) [0x10782d499]
    1 dcethread_cond_timedwait_throw + 37 (DCERPC) [0x10782d511]
    1 mach_thread_self + 5 (libsystem_kernel.dylib) [0x7fff852de15f]
    5 timer_loop + 73 (DCERPC) [0x10785b393]
    5 rpc__clock_update + 33 (DCERPC) [0x10785a6df]
    4 ??? [0]
    3 __commpage_gettimeofday + 41 (libsystem_kernel.dylib) [0x7fff852ddbd9]
    2 mach_absolute_time + 26 (libsystem_kernel.dylib) [0x7fff852dcca6]
    1 mach_absolute_time + 28 (libsystem_kernel.dylib) [0x7fff852dcca8]
    1 __commpage_gettimeofday + 83 (libsystem_kernel.dylib) [0x7fff852ddc03]
    1 gettimeofday + 6 (libsystem_c.dylib) [0x7fff851051a9]
    2 timer_loop + 78 (DCERPC) [0x10785b398]
    2 rpc__timer_callout + 228 (DCERPC) [0x10785b87f]
    2 timer_loop + 246 (DCERPC) [0x10785b440]
     
  3. the bug thread starter macrumors member

    the bug

    Joined:
    Feb 21, 2014
    #3
    I am starting to wonder if this may have something to do with the PRAM battery.

    I see a bunch of references to setting the time from the Apple server in the spindump log, but I never lose the startup disk selection in the control panel, which I thought that was another symptom of a dead battery.

    I'm also suspecting battery since my son just came in, and told me not to kill the light switch while the mini is running, since he had to move the plug to the same outlet the light switch controls.

    So for the last few weeks (AFIK) the mini has had the mains disconnected all day, since the light switch stays off all day, DOH !

    I plugged it into a non switched outlet for tonight and will try it again tomorrow.

    Hopefully if it is the battery it's not too far gone, since it looks like a bitch to replace it in one of these unibody mini's.
    I installed an SSD in my other mini, and still have nightmares about it from time to time . :)

    If anyone has any other suggestions to check in the meantime, it would be appreciated, since I won't know if it's the battery or not until tomorrow, thanks.

    - Jay
     
  4. satcomer macrumors 603

    satcomer

    Joined:
    Feb 19, 2008
    Location:
    The Finger Lakes Region
    #4
    Did you check /Applications/Utilities/Activity Viewer.app to quit the run away service? Did you run that link free application EtreCheck and see if that service needs updating or deletion?
     
  5. the bug thread starter macrumors member

    the bug

    Joined:
    Feb 21, 2014
    #5
    Thanks for the reply satcomer,
    I am able to quit the process in Activity Monitor, and it stays gone until the machine sits unplugged for a few hours, then it was coming back.
    I did use EtreCheck, and no 3rd party daemons or outdated stuff to speak of.

    I'm thinking it is the PRAM battery on it's way out, since I haven't had the problem at all today after it was plugged in overnight.

    I think the problem was that my son switched the AC power cord to an outlet that stays switched off most of the time, and that was killing an already weak battery.

    I have never seen a PRAM battery cause a system to slow down before, so that's a new one on me.

    Hopefully it will charge back up and be alright, since like I said before, it looks like a bear to get to the battery.

    Thanks again for the reply, I will be keeping an eye on it, but hopefully it is good now.

    Thanks.

    - Jay
     
  6. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #6
    I don't think the Mini's PRAM battery is rechargeable. Per this photo, it's a 2032-type coin cell (3V), which are not rechargeable in general:
    [​IMG]

    What's happening now is that the PRAM is being powered by the trickle (low-current) supply. When you unplug it or switch the outlet off, the weak/dead battery takes over, which is when it fails. It could keep working for any number of minutes after power loss, but still be essentially a dead parrot battery.

    FWIW, the clock is probably going to be the first thing to fail, since it has to keep counting. The setting of the startup disk is static (doesn't change while power is removed). As low-power SRAM, a static values is easy to maintain, or as EEPROM it can be maintained with no battery at all. Offhand I don't know how the static storage cells are implemented (SRAM or EEPROM), but the clock is almost certainly not EEPROM (it'd wear out too quickly).
     

Share This Page