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.
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'm trying to find a efficient way to programmatically monitor, from user mode, what processes are started on my computer (OS X Yosemite). Since NSWorkspaceDidLaunchApplicationNotification only works for apps and kqueues (NOTE_EXIT) only allows one to monitor a specific process, dtrace probes seemed to be the way to go. I've played around with both /usr/bin/execsnoop and /usr/bin/newproc.d (and stripped down versions, that just install a single probe (syscall::posix_spawn:return) and do nothing else (e.g. no prints)).
These do great job getting me the info I need, but when I start an app that kicks off multiple processes/quickly execs multiple commands (e.g. VMWare Fusion) - the probe(s) seem to noticeably impact the system. Specifically kernel_task consistently spikes to 50%+ CPU usage for a few seconds and the OS UI (mouse, etc) noticeable slows/lags...if the dtrace probes are not installed, this behavior is never observed.
So a few questions:
1) any way to avoid this perf issue? (dtrace #pragmas?)
2) are dtrace probes cumulative? (if I install dtrace probes do I need to manually uninstall them, or does ctl+C clear/disable them?)
3) any way to see what dtrace probes are currently installed?
I'm not attached to using dtrace - but am not aware of another (non-polling) way to get the pid/process name of things that are started on OS X :/
I am extremely surprised to see a measurable impact after enabling a single probe; does even
dtrace -n syscall::posix_spawn:return
cause a problem? If so, are you running short of memory? DTrace does require a (by default) modest amount and its initialisation may be pushing you over the edge. Do you see the problem with anything besides Fusion? It appears to suffer from performance problems of its own on Yosemite.
Probes are shared between consumers. If there is only one running consumer (e.g. dtrace) then all DTrace probes will be removed when it exits. If two consumers have enabled the same probe then it will remain active until the last consumer exits.
Maybe. Someone with access to the OS X source code could modify this script.
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.
When developing an app, I have running morbo for several hours to check the impacts of my changes - so far, I think this is exactly what morbo has been developed for.
But after a while (aprox. 2 hours) the app starts to get unresponsive and finally hangs. If that happens I can not stop morbo anymore with Ctrl+C. The only way is to kill the two morbo-processes (ps -ax | grep morbo, kill -9 <id1> <id2>. Unfortunately that does not cure the system in an sustainable way - after a few minutes the app hangs again. The only way is to restart the whole machine, which is quiet uncommon for a UNIX based OS.
System: OS X, Perl v5.12.3 darwin-2level, Mojolicious (5.44, Tiger Face)
Any idea?
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.