question : slow response

[Rick Stevens]

GoijI P wrote:
>>>>> out of 1GB RAM on server only 23MB was free.
>>>>> after reboot almost all became free.
>>>>> memory leak?.  i never reboot my server.
>>>>> top does not show any abnormality.
>>>>
>>>>
>>>>
>>>> Memory is often allocated at the beginning.  Memory won't be "free"
>>>> unless memory which was committed to a program is actually needed
>>>> (this prevents the machine from swapping too often).
>>>>
>>>> If you think you're swapping, look a the "used" and "free" bits for
>>>> the "swap" (fourth line) of the "free" output.  You can also "vmstat 5"
>>>> to watch the system activity.  Look at the "si" (swap in) and "so" 
>>>> (swap
>>>> out) columns to see if the system is really swapping.  If you see that
>>>> those numbers are greater than zero more often than not, then the 
>>>> system
>>>> is swapping and you have a bit more investigation to do.  Hit CTRL-C to
>>>> terminate the vmstat program.
>>>>
>>>> Make sure you look at the "top" report WHEN YOUR SYSTEM IS SLOW to see
>>>> what's going on.  Don't just look at the "% CPU" column, also look at
>>>> the "SIZE" and "RSS" columns.
>>>>
>>>> The biggest "SIZE" is the process that's using the most memory, the
>>>> biggest "RSS" is the process that has the largest program code 
>>>> size.  If
>>>> you see a process where the "SIZE" is growing but the "RSS" is more or
>>>> less the same, that's a potential memory leak.  Unless you've written
>>>> your own code and haven't taken care to free allocated memory or 
>>>> haven't
>>>> kept your machine current, the odds of a memory leak are pretty small.
>>>
>>>
>>>
>>>
>>> right now 0 swap space is used (things are quiet). i have to look at 
>>> it when more clients run server
>>> based apps remotely.  But, one thing i have noiced is that server RAM 
>>> MB size is 4 times higher than swap partition size, 1GB<->256MB.
>>
>>
>> Well that's upside down.  The rule of thumb is to have swap 2x RAM size.
>> In your case, 2GB.  Be aware that if the system runs out of memory and
>> swap, the system will start killing random processes to free up memory.
>>
>> Try adding more swap.  Find a filesystem with enough free space (let's
>> say it's /usr), create a contiguous 2GB file on that filesystem filled
>> with zeroes and turn it into a second swap area:
>>
>>     # dd if=/dev/zero of=/usr/swapfile bs=1M count=2048
>>     # mkswap /usr/swapfile
>>
>> To start using it:
>>
>>     # swapon /usr/swapfile
>>
>> and you suddenly will have an additional 2GB of swap.  Note that swap
>> files are not quite as fast as swap partitions, but the difference in
>> speed is pretty small.  Edit your /etc/fstab file and add a line like:
>>
>>     /usr/swapfile    swap            swap    defaults        0 0
>>
>> and it'll get used on the next reboot, too.
>>
>> OS NOTE: No single swap partition or file may be larger than 2GB, but
>> you can have up to 8 swap files or partitions (maximum of 16GB total).
> 
> 
> 
> created swap file. ran "vmstat 5". si so were 0 at all times like 
> before. top did not reveal any
> peculiar errors but probbaly need to spend more time there.
> meanwhile. probably as my last question on this topic, any other clues 
> anyone can guess of?.
> my NIS server is relatively an old PC. That is one possibility. But, top 
> did not show much there.

It really depends on what's being slow.  You need to wait until the
system starts exhibiting the slowdown, then the following tools can
help:

"top" will show the processess sucking up the most resources.

"vmstat" will show the status of the virtual memory system (including
swaps).

"iostat" will show the I/O status (whether something is I/O bound, e.g.
slow disks).

"nfsstat -s" will show what kind of NFS server operations are going on,
if any ("nfsstat" alone shows client statistics).

If you're using a hub rather than a switch you may be having a whole
bunch of network collisions that are slowing you down.  Look at the
output of "ifconfig" and look at the error counts on each network
interface--specifically the "collisions" counter.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-   To understand recursion, you must first understand recursion.    -
----------------------------------------------------------------------