Tag Info

Hot answers tagged

14

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 ...


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?


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

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. ...


4

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 ...


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

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

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


3

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

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


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.


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

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 :)


2

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


2

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 ...


2

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


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 ...


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.


1

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, ...


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

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

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


1

This AWK script reads the second line and uses the field headers as indices into the data on each line so you can refer to them by name. Here is the one-liner. I break it out line by line below. vmstat -n 1 | awk 'NR == 1 {next} NR == 2 {for (i = 1; i <= NF; i++) fields[$i] = i; next} {split($0, data); item = data[fields["si"]]; print item; ...


1

I'm not sure what's being asked here but you do remember that the first line of the vmstat output shows the average values for the items since the last reboot ? Subsequent lines show the values for the last sampling period, so in general ignore the first line.



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