Rhinos uses 100 % cpu constantly

even when completely IDLE and in the background. Working on the file then stresses the cpu additionally.

just a random guess: do you have a 3dconnexion mouse? I’ve read that there could be some driver issues under macOS 11.0 causing this…
Did you already try unloading all plug-ins?

my 3dconnection is in the cupboard evading dust :slight_smile:

i restarted rhino and now it keeps calm again, i was working pretty intensive in rendered mode on a 1000sm model with quite some textures, hitting render 1 or twice in between something might have hooked up idk. it was just strange that even i did not work on it at all it kept at 80-100% cpu. and i only noticed because the cooler made a bit more noise, since my computer does never activate cooling before heavy gpu work (at least after i stopped using safari which is really naughty) i checked activity monitor.

1 Like

ah… I know why:

the first time you open the materials tab Rhino starts rendering those small thumbnails -> which takes up 100%… just tested it: I got 949% CPU usage

1 Like

nope its actually closed, i keep it that way since i noticed performance drops. at this state i was not changing any textures.

this still happens to me from time to time. Still could not figure out, what it is caused by, but here are two scenarios:

  1. Using Rhino for a longer period of time. After some time, the CPU usage goes to 100% and slows donw all modeling activities. After a restart of Rhino, everything works normal again and after about 2h of modeling the usage is at 100% again. Very frustrating.
  2. When leaving a Rhino file open, closing the MB lid and continuing on the next day.

Does anyone have any ideas why this is happening?

Cheers, Rudi

Hi @rudolf.neumerkel and @encephalon the next time this happens, could you make a dump file as described here
https://wiki.mcneel.com/rhino/manual_rhino_dmp_mac

Whether it works for this issue is not sure,
Another suggestion by @jeff is:

If you click the “i” instead, next to the drop-down for a spin dump, you’ll get a dialog that allows you to take “samples” of the process. So you can repeatedly see the call stack without having to produce an actual dump file.

1 Like

Thank you! Will do it and report back.
Cheers, Rudi

Hey @Gijs, I uploaded the file to the McNeel website.
Hope it helps.
Will also try the second approach you mentioned.

Cheers, Rudi

1 Like

thanks in advance!

What are your computer specs? I don’t recommend ‘onboard graphics’, or cheap graphics cards, etc.

I’ve been using 3D space navigator devices for 17yrs, and have never had such an issue described here. But doing fresh installs wouldn’t hurt.

:sob:nooooo…

Hi Rudolf, fyi the first method unfortunately did not give any useful info. Hopefully the second approach will.

Thanks for the reply, will text back here when the bug occurs (I am now mostly working from the PC at the office)

Hey @Gijs the bug happened again, howver i could not understand much analyzing the thread.

However a virtual memory of 47,12GB seems like a lot…

I uploaded the other analysis files again to the mcneel website.

Btw this is what the CPU utilization looks like:

Hope this helps,

Cheers
Rudi

thanks @rudolf.neumerkel I forwarded this to the developers to look at.

RH-74506 is fixed in the latest BETA

the tracker is not public, would be interesting what you guys found

It had to do with spinning up a thread (or many) every time the viewport got maximized or restored. Eventually, Rhino had so many threads running that it got very slow.

2 Likes

So cool that this bug has been fixed!!!
Can you fix it for RH 7 as well? I am always using the newest version, but just for all the other users

No; the fix I made was specific to metal and doesn’t have any relation to code running in 7