Tag Info

Hot answers tagged

8

CPUs (or individual cores) can be put into "deep" C-states by an OS kernel. You're thinking that the processor "puts itself to sleep" when it "detects" inactivity. This isn't how it works. The OS scheduler determines system idle percentage based on the amount of time spent in the system idle loop to detect system inactivity. The CPU itself (in x86 land, at ...


6

Performance of EBS volumes can be affected by things like: New EBS volumes have a first-use penalty, even if they are created from an EBS snapshot. The first time you read or write to each block on the volume will take much longer than subsequent hits. When an EBS snapshot has been initiated, the EBS volume may experience high iowait when you try to write ...


5

In addition to nice, looking at limiting CPU time, using ulimit -t (assuming you are on a *nix platform)


5

If it happens again, run strace -p <PID> -T or swap the -T with -c. The -T option prints a time delta after each system call that lets you know how long it took. If you see particular calls like stat() and open() taking a long time you can infer one thing and if you see ones like semop() or poll() taking a long time you can infer something else. The ...


5

You can use Process Explorer to see the CPU history of each process and to see which was the most expansive process at a certain moment of time. Note if the load is in user space or kernel space (Interrupts or DPCs). If it is kernel space you will need to upgrade the drivers or the firmware (usually the ones for the disc controller or network card). See ...


5

If the server is under warranty, have the vendor replace the part. If the server is not under warranty and the part cannot be replaced, the end-all-answer will be subjective. Is this a server that CANNOT fail (ie: running life support, handling real time financial transactions)? Or is this just a web server for a puppy fan site? Either way, just run the ...


4

You can give your preferred user account or user group a nice value in /etc/security/limits.conf, at least if we are talking about Linux. Then when you login via sshd, you will have nice value of X, whatever you set it. In my experience the CPU scheduler in kernel is nowadays so good it's hard to make server unmanageably sluggish just by burning CPU cycles, ...


4

Try using Process Explorer and Task Manager to figure out what service is hogging the CPU. Once you know that much, edit it in to the question and we might be able to help.


4

Download and run Process Explorer. When you launch it you should see quite a bit of information, but what you should look at are two processes just under the System Idle Process node. You should see one called Interrupts and DPCs. If those are spiking along with the System process, the problem is being caused by drivers. Generally you'll see this caused by ...


3

Again...favorite recipe of mine...download sysinternals and use procmon, filemon/regmon to see if something is getting hammered there. Use process explorer to see if there are anomalous files open from the open file handle list. Is there anything showing up in the logs for IIS? If it's something with processing a particular file or script you might get a ...


3

I figured out the actual cause of the problem a while back, and figured I should document it here for the sake of others who may have similar issues. The root cause turned out to be trickier and more complicated than I initially expected. In short, run-parts was working fine all along. Its going haywire was just the symptom of a different problem. The ...


3

Four things come to mind when store.exe is seeing high usage. Third-party applications on the Exchange server. It could be anti-virus (that's usually the case) that checks the mailbox database. Perhaps some form of special indexing or archiving tool. If you have non of those, move on. The Exchange server itself has a virus. This happens sometimes. Sad, but ...


3

It's likely that nearly all of the CPU time spent during the grep you mention was due to iowait. Run top in another terminal during the grep and watch the %wa value. That value is the amount of time being spent waiting for IO to complete. It's a well-known and well-discussed fact that EBS volumes perform quite poorly when it comes to IO. This is why many ...


3

You could start by reducing Google and Bing requests... Have you set up a robots.txt? Exclude the ScriptPath from crawling, so that only the canonical page URLs are indexed, but not any URL with parameters to api.php or index.php. Also set a crawl-delay if needed. Many MediaWiki sites are slowed down by search engines due to small configuration errors.


3

zabbix_server is the most CPU consumer but I don't see any relation between zabbix_server and software interrupts. I wonder how exactly do you try seeing a relation? Have you tried stopping it, for example? Since this problem has arisen after kernel change, it looks reasonably to assume this is a bug of OVZ 2.6.32-5. I suggest using ...


3

From the top output, it is pretty clear that you need more RAM or more swap for the workload you are running. The way I reach this conclusion is from the following: The amount of free swap is exactly 0k The CPU usage of kswapd is high The amount of free memory, buffers, and cached are all fairly low. When those conditions are present I have always seen ...


3

Without access to the host you will never be able to control this. (Or the ability to predict that your VM will share resources and contend with other VMs to the point that there are contention issues on the host.) CPU Steal Time Definition Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing ...


2

Run your commands through nice. nice runs utility at an altered scheduling priority. If an increment is given, it is used; otherwise an increment of 10 is assumed. The super- user can run utilities with priorities higher than normal by using a neg- ative increment. The priority can be adjusted over a range of -20 (the ...


2

Yum is not a service it is a command, so you don't restart it like a service - you kill it and if need be re-run it. However interrupting yum can leave yum in an inconsistent state, which can be a problem when you next try to use it. If you do interrupt yum, you may want to have a look at the yum-complete-transaction command. You may also want to look at ...


2

If this is happening every day, could you not start up proc explorer and leave it running and disconnect from the RD session instead of logging out, that way once you are able to get logged back in you can see the immediate history?


2

It is a regularly scheduled cron job that gathers performance data. Look here for (light) removal instructions. To just remove it entirely if you don't care about the data collection, either remove the package (if it will let you) or just find the crontab entry for it and comment it out.


2

Based on this fix: https://code.launchpad.net/~jammy/+archive/upstart.fix-880049 Below steps fixed my problem in Ubuntu 11.10 today. Add this PPA to your system: add-apt-repository ppa:jammy/upstart.fix-880049 Update your system: apt-get update apt-get upgrade


2

Since you're running Server 2008 and if you don't want to install software to figure out what's causing this (and really, process explorer is very good), you can now do this from Task Manager. The process is to... Go to View -> Select Columns. Ensure that "PID" is selected. Identify the consuming process and note the process ID (PID) Select the ...


2

You might try using the Sysinternals tools Process Explorer and Process Monitor. For example, in Process Explorer - select the relevant svchost.exe instance, right click and choose properties and then go to the Threads tab. You may see a dll name in there that gives you a clue.


2

There is a hotfix for this specific problem on Windows 2003. http://www.microsoft.com/downloads/details.aspx?FamilyID=0638D919-109B-41C6-851D-0BE19D29172E&displaylang=en. Hopefully the fix is that easy. You can also check your WMI-related logs in %SystemRoot%\SYSTEM32\WBEM\Logs. There could be a clue in there. Edit: The hotfix looks to be related to ...


2

I actually had this problem once. We pulled up filemon and found that WMI was writing to a log file a lot (Framework.log). We checked out the file and found it grew over 2 GB in size. We either renamed the file or stopped the service and renamed it (can't remember). At any rate, we found that it relieved the CPU. There is a KB article with a fix ...


2

One thing I'd be tempted to try are the tools in sysinternals like procmon and filemon and regmon. These might give a hint whether something in particular is being continually hit and by what particular process. Wouldn't hurt to try it.


2

You can enable performance tracing on the database and monitor the execution of your queries with some built in utilities. I personally haven't done this on Oracle, but they do have online documentation to point you in the right direction. http://download.oracle.com/docs/cd/B19306%5F01/server.102/b14211/sqltrace.htm#sthref2019


2

When production reaches 100% CPU, you (or your DBA) can run "top" command, grab the process id that contributes most to the CPU (assuming you have just a few of these) and then use the following query to catch the session and what's it doing at the time: select p.SPID UnixProcess ...



Only top voted, non community-wiki answers of a minimum length are eligible