From: Mickael Bailly <mickael.bailly@telintrans.fr>
To: linux-mm@kvack.org
Subject: Re: looking for explanations on linux memory management
Date: Thu, 27 Nov 2003 15:53:13 +0100 [thread overview]
Message-ID: <200311271553.13324.mickael.bailly@telintrans.fr> (raw)
In-Reply-To: <Pine.LNX.4.44.0311261351220.18209-100000@coffee.psychology.mcmaster.ca>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
Hello!,
I try to merge answers from Rob Love and Mark Hahn.
On Wednesday 26 November 2003 20:01, Mark Hahn wrote:
> > 1/ can you explain me what happened in week 47 so cached memory don't get
> > down anymore ? Nothing really changed in this week on the server.
>
> I'm guessing someone did a "find /" or similar, which caused lots of
> dcache/icache entries to be created. of course, it could also be normal
> cached file pages, stale SHM segments (run ipcs -a), or maybe even
> a big-VM proces that's gotten into some limbo state...
o no one did a "find /" , however as in any RedHat each night at 4 pm the
'updatedb' script is launched (even before week 47).
o for ipcs output I got lots of things but I don't understand it yet I have
to read some docs on that.
I attach output from '/proc/meminfo' and '/proc/slabinfo' to this mail.
>
> > 2/ how can I know when my server needs more RAM/SWAP, if free memory is
> > always about 0
>
> free memory is WASTED memory - you might as well have not bought it.
> you know you need more memory when you see swapin traffic (NOT swapouts,
> which are normal and in fact good). swapins are a sign that the kernel
> has either chosen the wrong pages to swap out, or is needing to swap out
> so much that hot pages are getting swapped, or that you simply have a
> working set that's larger than physical memory.
I suppose 'swapin' is the 'Swap - si' column of the 'vmstat' utility, for
example. OK then if I want to create a script that tell me when memory is
needed I should monitor this value, right ? (sorry again, my questions are a
little bit 'corporate'... :-\ )
For my RedHat kernel I'll work on compiling my own... Unfortunately the
'.spec' of vanilia kernel distributions don't create -BOOT , -smp, etc...
kernels, which are needed for kickstart installs.
--
Mickael Bailly
[-- Attachment #2: meminfo.log --]
[-- Type: text/x-log, Size: 656 bytes --]
total: used: free: shared: buffers: cached:
Mem: 2114347008 2074492928 39854080 0 277983232 1528950784
Swap: 270360576 31682560 238678016
MemTotal: 2064792 kB
MemFree: 38920 kB
MemShared: 0 kB
Buffers: 271468 kB
Cached: 1483524 kB
SwapCached: 9592 kB
Active: 1535044 kB
ActiveAnon: 176340 kB
ActiveCache: 1358704 kB
Inact_dirty: 0 kB
Inact_laundry: 361692 kB
Inact_clean: 22008 kB
Inact_target: 383748 kB
HighTotal: 1179560 kB
HighFree: 1024 kB
LowTotal: 885232 kB
LowFree: 37896 kB
SwapTotal: 264024 kB
SwapFree: 233084 kB
[-- Attachment #3: slabinfo.log --]
[-- Type: text/x-log, Size: 4256 bytes --]
slabinfo - version: 1.1 (SMP)
kmem_cache 80 80 244 5 5 1 : 252 126
ip_conntrack 242 9790 384 26 979 1 : 124 62
ip_fib_hash 336 336 32 3 3 1 : 252 126
journal_head 938 21098 48 28 274 1 : 252 126
revoke_table 500 500 12 2 2 1 : 252 126
revoke_record 588 1344 32 7 12 1 : 252 126
clip_arp_cache 0 0 128 0 0 1 : 252 126
ip_mrt_cache 0 0 128 0 0 1 : 252 126
tcp_tw_bucket 384 510 128 17 17 1 : 252 126
tcp_bind_bucket 420 672 32 5 6 1 : 252 126
tcp_open_request 654 780 128 26 26 1 : 252 126
inet_peer_cache 232 232 64 4 4 1 : 252 126
ip_dst_cache 399 525 256 34 35 1 : 252 126
arp_cache 450 450 128 15 15 1 : 252 126
blkdev_requests 810 810 128 27 27 1 : 252 126
dnotify_cache 0 0 20 0 0 1 : 252 126
file_lock_cache 594 720 96 18 18 1 : 252 126
fasync_cache 0 0 16 0 0 1 : 252 126
uid_cache 672 672 32 6 6 1 : 252 126
skbuff_head_cache 810 1440 256 63 96 1 : 252 126
sock 223 253 1408 23 23 4 : 60 30
sigqueue 628 754 132 26 26 1 : 252 126
kiobuf 174 174 64 3 3 1 : 252 126
cdev_cache 496 3016 64 26 52 1 : 252 126
bdev_cache 232 232 64 4 4 1 : 252 126
mnt_cache 232 232 64 4 4 1 : 252 126
inode_cache 5596 7091 512 1013 1013 1 : 124 62
dentry_cache 2730 6660 128 222 222 1 : 252 126
dquot 0 0 128 0 0 1 : 252 126
filp 1290 1290 128 43 43 1 : 252 126
names_cache 113 173 4096 113 173 1 : 60 30
buffer_head 365612 559400 96 11582 13985 1 : 252 126
mm_struct 579 705 256 47 47 1 : 252 126
vm_area_struct 3480 4110 128 125 137 1 : 252 126
fs_cache 570 696 64 12 12 1 : 252 126
files_cache 330 392 512 52 56 1 : 124 62
signal_act 152 242 1408 22 22 4 : 60 30
pte_chain 25392 54120 128 894 1804 1 : 252 126
size-131072(DMA) 0 0 131072 0 0 32 : 0 0
size-131072 0 0 131072 0 0 32 : 0 0
size-65536(DMA) 0 0 65536 0 0 16 : 0 0
size-65536 0 0 65536 0 0 16 : 0 0
size-32768(DMA) 0 0 32768 0 0 8 : 0 0
size-32768 0 2 32768 0 2 8 : 0 0
size-16384(DMA) 0 0 16384 0 0 4 : 0 0
size-16384 3 5 16384 3 5 4 : 0 0
size-8192(DMA) 0 0 8192 0 0 2 : 0 0
size-8192 9 16 8192 9 16 2 : 0 0
size-4096(DMA) 0 0 4096 0 0 1 : 60 30
size-4096 830 890 4096 830 890 1 : 60 30
size-2048(DMA) 0 0 2048 0 0 1 : 60 30
size-2048 136 196 2048 68 98 1 : 60 30
size-1024(DMA) 0 0 1024 0 0 1 : 124 62
size-1024 588 712 1024 160 178 1 : 124 62
size-512(DMA) 0 0 512 0 0 1 : 124 62
size-512 420 544 512 60 68 1 : 124 62
size-256(DMA) 0 0 256 0 0 1 : 252 126
size-256 402 780 256 35 52 1 : 252 126
size-128(DMA) 0 0 128 0 0 1 : 252 126
size-128 2742 8790 128 112 293 1 : 252 126
size-64(DMA) 0 0 128 0 0 1 : 252 126
size-64 582 1590 128 40 53 1 : 252 126
size-32(DMA) 0 0 64 0 0 1 : 252 126
size-32 1042 1798 64 28 31 1 : 252 126
prev parent reply other threads:[~2003-11-27 14:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-26 17:30 Mickael Bailly
2003-11-26 18:13 ` Rob Love
2003-11-26 19:01 ` Mark Hahn
2003-11-27 14:53 ` Mickael Bailly [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200311271553.13324.mickael.bailly@telintrans.fr \
--to=mickael.bailly@telintrans.fr \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox