Tag Info

Hot answers tagged

16

What you're looking for is the output from "free": $ free total used free shared buffers cached Mem: 775556 759456 16100 0 22132 592484 -/+ buffers/cache: 144840 630716 Swap: 500344 21972 478372 Here's a tour: This is a box w/ 768MB of physical RAM and a 500344KB ...


6

you can try to use iostat to pin down which device generates the i/o wait: # iostat -k -h -n 5 see the iostat man page for further details. nfs is often part of the problem especially if you serve a large number of small files or have particular many file operations. you can tune nfs access by using the usual mount options like rsize=32768,wsize=32768. ...


6

I'll start by admitting that I don't much about running stuff in clouds - but based on my experience elsewhere, I'd say that this webserver config reflects a fairly low volume of traffic. That the runqueue is so large suggests that there just isn't enough CPU available to deal with it. What else is in the runqueue? We may be allowing far too many ...


5

The simplest way is at a command line do: systeminfo You will get a section that looks like: Total Physical Memory: 16,383 MB Available Physical Memory: 926 MB Page File: Max Size: 19,868 MB Page File: Available: 4,562 MB Page File: In Use: 15,306 MB That is taken directly from one of my machines. That info is near the top.


5

According to the man page, it includes all calls to fork, vfork or clone. The last one of these three (clone) is used by Java to implement its threads So each time your Java server creates a new thread, that value increments. Providing it doesn't go silly, it should be fine. How many per second do you see on average?


4

Try using pidstat -wt The 't' option shows the threads also. It might be a thread who is doing the context switches .


4

You should consider installing an asynchronous reverse proxy, because a number of processes in W state is quite high too. Your Apache processes seem to spend a lot of time sending content to slow clients over network being blocked on that. Nginx or lighttpd as a frontend to your Apache server can reduce a number of processes in W state dramatically. And yes, ...


3

It is based on the number of processes in a runnable or uninterruptable state. Runnable is either currently executing on a processor, or waiting for a processor to become free. The uninterruptable state is waiting for IO to complete - it's not "uninterruptable sleep" - the process is technically "sleeping", but it's waiting for a kernel call to complete. ...


3

From the man page: If no delay is specified, only one report is printed with the average values since boot. You are comparing the average idle time since the machine is up (92%) with five second intervals (10-12%), which doesn't make sense.


3

can it be that write-cache was turned off? maybe battery has died and it switched from write-back to write-through? some cheap hardware raids without battery and with cache by default enable the cache just for reads - can it be that you set it to use write-cache too and the controller 'lost' the settings? besides - maybe one of the drives is faulty? try ...


3

Too short periods. It would be better to have vmstat 60. Well, nevertheless: c - is OK. h - has something in si/so. Taking into account the large swpd, if you find the performance less than acceptable, add 521-1024 MB more RAM (892948 kB ideally). j - is OK. s - is OK. A little bit swpd, but no si/so. u - has quite a lot si/so. Taking into account the ...


3

My rule of thumb is "anything over zero is bad". Question becomes "how bad?". For webservers and database servers its very bad as the trip to disk is likely enough to have a very large performance impact on whatever transactions spilled over. In fact it will often cause a snowball effect until the kernel oom-kill's something. For a fileserver or ...


3

It's probably a lot better to run "iostat -x" which will often give a percentage utilization of disk I/O bandwidth for each device. If you don't have iostat, then I'd run "hdparm -t /dev/sda " in a loop for a while while running vmstat in another window to give you a baseline for what a lot of I/O looks like.


3

Idle time means your CPU is doing nothing. Your system is not performing any work, so your CPU is spending time idling.


3

Please note, that on most unix systems first line of vmstat output is average since last reboot. Next lines are current statistics. 99% CPU Idle means that your server is not really heavy loaded. Which is good. Nothing to worry about :)


3

Well, quite interesting case. Try observing watch -tdn1 cat /proc/interrupts. Do you see any valuable changes there?


2

Nonsense, the resource usage of vmstat is minimal.


2

You can continually run vmstat without fear of chewing up your resources. vmstat outputs all it's performance statistics in text form that is printed to standard output, nothing more. The overhead is incredibly small. As a test I ran vmstat on two different servers and in both cases it required approximately: 456k to 485k usage Additional ...


2

vmstat -n 1 | (while read; do echo "$(date +%Y%m%d.%H%M%S) $REPLY"; done) | tail -n +3


2

Some application is writing out data 6000 blocks per second. With a decent system that shouldn't be too much. What that application is, we can't tell you since your post lacks a lot of information. You can see the per-application I/O statistics with the command iotop.


2

This is because top, vmstat, iostat all in their first run collect data since the last reboot time of the system. And the successive iterations run on the sampling period that you specify. So, in the first run of top, you will see the %idle time because from the time of reboot to the time of running top, it was that much % idle. But in next iterations, ...


2

cs is "context switches", a context switch is basically "the CPU changing between tasks". It's normal for this value to be high, they can happen hundreds of times a second, as part of normal multitasking. Your load spike issue is unlikely to be related, busy systems will generally have a large cs counter.


2

Solaris? Which version (presumably 8 or 9 from the idle column)? Sun cluster or vcs? Anyway, ignore the first line since that is an average since boot. Is a backup running on the passive node, by the way, and causing the minor faults and page-ins on a machine ostensibly doing nothing? And look at the context switches. On the active node, memory usage at ...


1

You have two rows in your vmstat that show your CPU wait time is fairly high, and around those, you do a fair number of writes (io - bo) and context switching. I would look at what's writing blocks, and how to eliminate that wait. I think the most improvement could be found in improving your disk IO. Check syslog - set it to write async. Make sure your ...


1

collectd is available for FreeBSD. From the collectd website: collectd gathers statistics about the system it is running on and stores this information. Those statistics can then be used to find current performance bottlenecks (i.e. performance analysis) and predict future system load (i.e. capacity planning). Or if you just want pretty graphs of ...


1

I ended up using atop (which is available in FreeBSD ports as sysutils/atop), and it's awesome. I would very much consider using it in preference of sar on systems where sar is available. It comes with a curses-based UI that is easy to navigate and shows a lot of data at once. It's incredibly handy.


1

Vmstat cs column is displaying, at least on Solaris, voluntary context switches, i.e. those happening when a process (thread really) is releasing the CPU because it has nothing else to do with it, for example waiting for some external event like a pending I/O to finish. If you want to display involuntary context switches, you can use the mpstat command an ...


1

I think it may be OS-dependent. On AIX 6.1 you have (http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/vmstat_command.htm): "(cs is) Number of context switches per second observed in the interval. The physical CPU resource is subdivided into logical time slices of 10 milliseconds each. Assuming a thread is ...


1

If you run top you should see a line for Cpu(s): . At the end of the CPU line is ‘%st’. That stands for 'Steal Time'. Steal time is the time that the CPU was running something, but the hypervisor is running something else instead. If you don't see %st in top or ‘Stolen CPU ticks’ in ‘vmstat -s’, then I would try and upgrade your installation of procps.


1

SWAPIN=$(vmstat | egrep -v 'swap|si' | awk '{ print $7 }') SWAPOUT=$(vmstat | egrep -v 'swap|si' | awk '{ print $8 }') or more "standard" way: $ vmstat | awk '{ for (i=1; i<=NF; i++) if ($i=="si") { getline; print $i }}' The built-in NF variable gives you the number of fields in the current line getline reads the next input line



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