12-22-2011
Generally, no. Servers can operate weeks to months at a go, potentially years if it wasn't for kernel upgrades.
Often people do so because they see the value of "free" memory creeping very low and "cached" climbing very high, then reboot to forestall what they perceive as impending disaster. Many try putting strange settings into /proc/ to "flush the cache", as well. This isn't necessary, low free/high cache is normal operation, just count the value of "cached" in your estimation of free memory and usually everything is fine after all.
9 More Discussions You Might Find Interesting
1. SCO
Dear sir,
I am using sco open server 5.06.How we can reboot the system without using root password? Whar are the permision need to change to do this.
Thanks,
Mostafizur Rahman (3 Replies)
Discussion started by: rahmanm
3 Replies
2. Shell Programming and Scripting
I want to get an email alert from a cronjob when a server got rebooted unexpectedly. Please help. Thanks! :confused: (2 Replies)
Discussion started by: angloi
2 Replies
3. UNIX for Advanced & Expert Users
hi all, :)
for a reboot of sun box for patch installation i would like to know where do the reboot logs apart from /var/adm/messages and patch run messages would be available,
i would like to know the sequence of messages logged in the file like
requesting the users to log out
sending a... (1 Reply)
Discussion started by: matrixmadhan
1 Replies
4. AIX
I've recently changed my gateway setting using SMIT. Everything went fine except that the gateway setting kept reverting back to the old one everytime I reboot the server.
I'm on AIX 5.2 running p-Series. Thanks for any info. (3 Replies)
Discussion started by: dereklow
3 Replies
5. Solaris
Hi All,
I want to know the procedure like if server is down, i want to reboot the server through console ($rsc or $sc prompt).Could you please help me out.
I would really appreciate your cooperation.
thanks for understanding
regards
krishna (5 Replies)
Discussion started by: murthy76
5 Replies
6. UNIX for Advanced & Expert Users
Hi,
please could someone advise the best command to shutdown and then for it to reboot back online again.
Note: I shall be doing this from a telent session.
regards
venhart (3 Replies)
Discussion started by: venhart
3 Replies
7. Red Hat
Hi All,
Our Linux server were rebooted 723 days before and now We have decided to reboot the server due to server performance.
Could someone advise us what is the optimal duration of a server reboot ?
Thanks for your time.
Best Regards,
Arun (2 Replies)
Discussion started by: arunap44
2 Replies
8. Solaris
Hi,
anyone please let us know how to write shell script to find the missing mountpoints after server reboot.
i want to take the mountpount information before server reboot, and validate the mountpoints after server reboot if any missing.please let us know the shell script from begining to end as... (24 Replies)
Discussion started by: VenkatReddy786
24 Replies
9. Red Hat
Hi,
The server got rebooted and below messages can be seen in /var/log/messages
Sep 7 10:49:12 minersville kernel: Call Trace: <IRQ> <ffffffff80167420>{__alloc_pages+796}
Sep 7 10:49:12 minersville kernel: <ffffffff80182814>{kmem_getpages+106} <ffffffff80183c16>{fallback_alloc+304}... (3 Replies)
Discussion started by: admin_db
3 Replies
LEARN ABOUT REDHAT
slabinfo
SLABINFO(5) Linux manual SLABINFO(5)
NAME
/proc/slabinfo - Kernel slab allocator statistics
SYNOPSIS
cat /proc/slabinfo
DESCRIPTION
Frequently used objects in the Linux kernel (buffer heads, inodes, dentries, etc.) have their own cache. The file /proc/slabinfo gives
statistics. For example:
% cat /proc/slabinfo
slabinfo - version: 1.1
kmem_cache 60 78 100 2 2 1
blkdev_requests 5120 5120 96 128 128 1
mnt_cache 20 40 96 1 1 1
inode_cache 7005 14792 480 1598 1849 1
dentry_cache 5469 5880 128 183 196 1
filp 726 760 96 19 19 1
buffer_head 67131 71240 96 1776 1781 1
vm_area_struct 1204 1652 64 23 28 1
...
size-8192 1 17 8192 1 17 2
size-4096 41 73 4096 41 73 1
...
For each slab cache, the cache name, the number of currently active objects, the total number of available objects, the size of each object
in bytes, the number of pages with at least one active object, the total number of allocated pages, and the number of pages per slab are
given.
Note that because of object alignment and slab cache overhead, objects are not normally packed tightly into pages. Pages with even one in-
use object are considered in-use and cannot be freed.
Kernels compiled with slab cache statistics will also have "(statistics)" in the first line of output, and will have 5 additional columns,
namely: the high water mark of active objects; the number of times objects have been allocated; the number of times the cache has grown
(new pages added to this cache); the number of times the cache has been reaped (unused pages removed from this cache); and the number of
times there was an error allocating new pages to this cache. If slab cache statistics are not enabled for this kernel, these columns will
not be shown.
SMP systems will also have "(SMP)" in the first line of output, and will have two additional columns for each slab, reporting the slab
allocation policy for the CPU-local cache (to reduce the need for inter-CPU synchronization when allocating objects from the cache). The
first column is the per-CPU limit: the maximum number of objects that will be cached for each CPU. The second column is the batchcount:
the maximum number of free objects in the global cache that will be transferred to the per-CPU cache if it is empty, or the number of
objects to be returned to the global cache if the per-CPU cache is full.
If both slab cache statistics and SMP are defined, there will be four additional columns, reporting the per-CPU cache statistics. The
first two are the per-CPU cache allocation hit and miss counts: the number of times an object was or was not available in the per-CPU cache
for allocation. The next two are the per-CPU cache free hit and miss counts: the number of times a freed object could or could not fit
within the per-CPU cache limit, before flushing objects to the global cache.
It is possible to tune the SMP per-CPU slab cache limit and batchcount via:
echo "cache_name limit batchcount" > /proc/slabinfo
AVAILABILITY
/proc/slabinfo exists since Linux 2.1.23. SMP per-CPU caches exist since Linux 2.4.0-test3.
FILES
<linux/slab.h>
2001-06-19 SLABINFO(5)