Running on Macbook Pro unibody OSX 10.6 Snow Leopard, dual-core. I notice Activity Monitor is stating the ruby process running at 50% consistently...
Is anyone seeing the same results? Is this 'normal'?
EDIT:
Further into clarifying. My hands are not on the keyboard. The Rails server and ruby console are running, but without any activity. I am also running Rails 3.1 RC1.
It depends on what you are doing. If you do simply nothing, then no, this isn't normal. If you are actively developing, then you might have created an endless loop.
Usually, one infinity loop uses one core of CPU (50% usage in your case, because your Mac has got dual-core).
It's not common, no. I've seen it happen a few times, but I don't know why.. It's not a endless loop in my code. I suspect a race condition somewhere deep in the stack or in the interpreter. It happens most often after a resume from sleep event I think.
I just kill the process.
I've restarted the server. The CPU process for Ruby seems to have subsided to a more reasonable state / percentage. At the moment, at a 0.2.
I'm starting to suspect that something may have triggered a CPU spike with Rails 3.1 RC1. After all, it is still not the stable release of Rails. Will observe how this plays out.
Related
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
I have an OS X Server 10.4 that started Kernel Panicking on me late december. It had Mail, Web and SQL services turned on.
I switched to another Mac, problem persisted. Updated to 10.6.8, no difference. Switched to a third Mac, no difference.
In short; It gets 1-3 Kernel Panics per day.
I have noticed that the CPU load slowly rises until it panics.
So during this weekend I turned off all services except Mail. It worked very good during the weekend. Today 1500 (15pm) I turned on Web services, and after that the CPU load started to rise...
Among the processes I found more than 300 perl processes owned by the _www user. As well as the clamavd (owned by amisvd if I remember correctly) eating a lot of memory.
Clamavd is the anti virus and spam processes, right? I have tried to turn them off in the OS X Server admin app. It won't turn off.
Regarding the Perl processes I really don't know where that is used. The info panel doesn't give me any idea. I think it means that one of the sites (I have about 20) is using perl, but I don't know which one.
So, some questions:
- Is it safe to upgrade to OS X El Capitan Server? Should I?
- How can I kill all Perl processes at one time? (I have googled this but couldn't find any working tips)
- Any idea of what's going on?
As you may tell I'm not very skilled with Apache, but I still think it's funny and educating to do this.
Graph
Perl processes
How can you kill all Perl processes at one time? killall is available on OS X. Try
killall -9 perl
HTH
btw - my apologies to ThisSuitIsBlackNot -- I see he referred to this in his comments.
Our iOS automation tests on simulator have gone through disaster since upgrading to Xcode6.
We can observe view switching slowing down, UIAutomation felt it too and often returned an empty or not fully updated app main window, you can imagine the stability.
Part of the reason is that we have slow VMs, but still we need to find ways to workaround it.
Then I notice there's the CoreSimulatorService process staying alive between the launches and shutdowns of simulator. So I killed it to see what change would it make:
killall -9 com.apple.CoreSimulator.CoreSimulatorService
After it was killed and relaunched, the performance of simulator seem to get much better, at least I don't see random fails anymore (hopefully). I guess this is kind of cleaning up.
So I hope to get a better idea about what function does CoreSimulatorService perform exactly?
Also, I am confused about where to find the documents when Apple releases new things (forgive my ignorance). For example, I didn't find any documents in iOS developer library mentioning simctl except Xcode Release Note.
Thanks!
I just faced a unexpected CPU spike due to this process (Xcode 12 & macOS 12).
A quick look on the web showed that most of the time your look for com.apple.CoreSimulator.CoreSimulatorService you will find people afraid of "something" and that are resetting everything. Ultimately this will "resolve" (as a workaround) the problem that isn't really one.
I opened ActivityMonitor (and not just looking at iStat Menu CPU widget), I found that the process update_dyld_sim_shared_cache was responsible for this CPU high usage.
Just reading the name show that the process is probably doing something expected after all (I got this issue after an OS update).
I just waited a around half a hour and the CPU went back to normal.
It must be obvious, but I cant get a usecase of Delayed Job, cause due to ruby`s Gargabe Collector specific, it doesnt free memory back to OS. And once delayed job process will take all memory anyway. And the only way is to restart delayed job process.
But if I restart delayed job process and there is currenlty running task - it will never be completed. Probably, there is some workaround to restart that task later, but this approach seems ugly to me.
I tried real jobs and some simple computatuin without any variables, symbols or links so I dont think that "my code leaks". Still, every new job increases memory of delayed_job process.
May be I use Delayed job for something that its not designed? Or it could be environment problem (besides, tried on local machine and on VPS) ?
Tested on: Ubuntu 14.04 and Debian 6 (both x86), Rails 3.2, delayed_job 4.0.2, delayed_job_active_record 4.0.1, ruby 2.1.2
I could give some code examples, but, as I mentioned, I tried both: real job and simple computation. So I won`t if it is not significant and my mistakes are fundamental.
Due to my conditions - my tasks can be executed for couple of minutes, read and write about 100K records to database and require a lot of computation, tasks cant be interrupted, and number of tasks limited by 10-20 dayli, may be - I only guess to use Resque, because it forks process everytime, so there should be no problems with accumulating memory with time.
So do I realy do something wrong or this is a nature of DJ - to occupie all memory or require a restart - and if I cant restart it, I shouldnt use its approach ?
Everything I read on the internet (not so much, by the way) tells that its rubys GC trouble that it doesnt free memory back to OS, and some advises to profile code for unlinked objects (it sounds the most realistic to my case, but, I tried a lot with code that doesnt create any objects, and I explicitly set everything to nil and call GC.start)
happens to me occasionally:
I start my program in visual studio and due to some bug my program goes into 100% cpu usage and basically freezes windows completely.
Only by utter patience requesting the task manager (takes forever to come up and paint itself) I can kill my process.
Do others encounter this too sometimes? Is there a clever trick to get this process down (other than pulling the plug and possible ruining files on the HD)? It now takes 5-10 minutes to kill it properly if the task manager is not accidentally present and I have to request this first
R
p.s. weird that a 'multitasking os' can still allow processes to eat up so much time that nothing else can be done anymore. My program doesn't even bump up it's thread priorities or anything
Check out Process Lasso
"Process Lasso is a unique new technology that will, amongst other things, improve your PC's responsiveness and stability. Windows, by design, allows programs to monopolize your CPU without restraint -- leading to freezes and hangs. Process Lasso's ProBalance (Process Balance) technology intelligently adjusts the priority of running programs so that badly behaved or overly active processes won't interfere with your ability to use the computer!"
http://www.bitsum.com/prolasso.php
I am not affiliated with Bitsum, just a user of their product, and it helps me solve this type of problems.
For what it's worth, I've never see this on either XP 64 or Vista 64, developing C++ apps in Visual Studio. Perhaps an OS upgrade is in order?
Edit: I use Process Explorer as a replacement Task Manager - it wouldn't surprise me if it did a better job of appearing in good time even when there's a rogue process running. And you can use it to boost its own priority.
I usually hit ctrl-alt-delete start the task manager sort by cpu find the offending process and right click and end the process..
task manager usually has enough priority to do this although it may be slow.
I think a shotgun to the head is the only way to be sure.
I generally don't see anything like this happen strictly as a function of an app that's eating 100% CPU. As part of stability / performance testing, I've gotten apps to cause Windows to get very slow, but this is usually done by writing heavily threaded apps (thus causing the O/S scheduler to thrash), or by writing apps that consume all available system memory or resources (much more impactful to the GUI apps than simply one thread that consumes its full share of processor time during its slices).
You say you get this behavior under Visual Studio? VS has a "Pause" button...