An active RHEL system should be using almost all of the free physical memory for cache and buffers. Once you start doing application I/O, you'll see the memory get "used" by the OS quickly. Remember, the memory "used" for cache/buffers is actually free and the kernel can reclaim it very quickly if memory demand for processes increases. The "free" command shows you the difference between "used" memory with and without including the cache/buffers.
Older versions of Linux did have a penalty for very large memory because the algorithms used to manage memory pages were primitive. Many of those problems were addressed in later RHEL 4 releases and by the time we got to RHEL 5 and 6, those issues have been completely resolved. Many of our servers run 256 or 512GB of RAM. For a BL460c with maybe 8 cores, 32GB seems to me to be about right. If it's a BL460cG6 with 16 cores, 32GB seems small. It all depends on what applications or databases you're running on it.
Here's an example from a mid range system with 48 cores:
At first glance it looks like this system has no free memory. But the actual memory used by processes is actually only 24GB - the other 226GB is cache/buffers.
With very large amounts of RAM on certain hardware you can encounter NUMA issues, but as a general rule, you can never have too much memory. RHEL will find a way to use it.
Hello,
I need explanations about physical disks and physical volumes. What is the difference between these 2 things?
In fact, i am trying to understand what the AIX lspv2command does.
Thank you in advance. (2 Replies)
I was in smit, checking on disc space, etc. and it appears that one of our physical volumes that is part of a large volume group, has no free physical partitions. The server is running AIX 5.1. What would be the advisable step to take in this instance? (9 Replies)
Hi All,
I am trying to find the physical memory usage by each process/users.
Can you please let me know how to get the memory usage?.
Thanks,
bsraj. (12 Replies)
Hello All,
Can anybody please tell me what is the maximum limit of Physical IBM Power Machine which can be handled by single HMC at a single point of time?
Thanks,
Jenish (1 Reply)
I have a Sun T5120, and I want to programmatically determine how much RAM it has.
# uname -a
SunOS myhost 5.10 Generic_141444-09 sun4v sparc SUNW,SPARC-Enterprise-T5120
The box has 64Gb; I tried prtdiag and prtconf, but they give me bogus info
prtconf gives me:
# prtconf |grep -i... (12 Replies)
After a memory upgrade all network interfaces are misconfigued. How do i resolve this issue. Below are some out puts.thanks.
ifconfig: plumb: SIOCLIFADDIF: eg000g0:2: no such interface
# ifconfig eg1000g0:2 plumb
ifconfig: plumb: SIOCLIFADDIF: eg1000g0:2: no such interface
# ifconfig... (2 Replies)
Hi,
I am new to unix. I am working on Red Hat Linux and side by side on AIX also. After reading the concepts of Storage, I am now really confused regarding the terminologies
1)Physical Volume
2)Volume Group
3)Logical Volume
4)Physical Partition
Please help me to understand these concepts. (6 Replies)
Hi,
kstat -p -m zfs -n arcstats -s size returns
zfs:0:arcstats:size 8177310584
this values is approx (7.61 GB)
but my Physical Memory size is only 6144 Megabytes.
Can this happen ?
if yes, then how can I find free memory on the system.
BTW, I ran the kstat commands from a Non... (2 Replies)
Discussion started by: sapre_amit
2 Replies
LEARN ABOUT MOJAVE
systemd-cryptsetup-generator
SYSTEMD-CRYPTSETUP-GENERATOR(8) systemd-cryptsetup-generator SYSTEMD-CRYPTSETUP-GENERATOR(8)NAME
systemd-cryptsetup-generator - Unit generator for /etc/crypttab
SYNOPSIS
/lib/systemd/system-generators/systemd-cryptsetup-generator
DESCRIPTION
systemd-cryptsetup-generator is a generator that translates /etc/crypttab into native systemd units early at boot and when configuration of
the system manager is reloaded. This will create systemd-cryptsetup@.service(8) units as necessary.
systemd-cryptsetup-generator implements systemd.generator(7).
KERNEL COMMAND LINE
systemd-cryptsetup-generator understands the following kernel command line parameters:
luks=, rd.luks=
Takes a boolean argument. Defaults to "yes". If "no", disables the generator entirely. rd.luks= is honored only by initial RAM disk
(initrd) while luks= is honored by both the main system and the initrd.
luks.crypttab=, rd.luks.crypttab=
Takes a boolean argument. Defaults to "yes". If "no", causes the generator to ignore any devices configured in /etc/crypttab
(luks.uuid= will still work however). rd.luks.crypttab= is honored only by initial RAM disk (initrd) while luks.crypttab= is honored
by both the main system and the initrd.
luks.uuid=, rd.luks.uuid=
Takes a LUKS superblock UUID as argument. This will activate the specified device as part of the boot process as if it was listed in
/etc/crypttab. This option may be specified more than once in order to set up multiple devices. rd.luks.uuid= is honored only by
initial RAM disk (initrd) while luks.uuid= is honored by both the main system and the initrd.
If /etc/crypttab contains entries with the same UUID, then the name, keyfile and options specified there will be used. Otherwise, the
device will have the name "luks-UUID".
If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root.
luks.name=, rd.luks.name=
Takes a LUKS super block UUID followed by an "=" and a name. This implies rd.luks.uuid= or luks.uuid= and will additionally make the
LUKS device given by the UUID appear under the provided name.
rd.luks.name= is honored only by initial RAM disk (initrd) while luks.name= is honored by both the main system and the initrd.
luks.options=, rd.luks.options=
Takes a LUKS super block UUID followed by an "=" and a string of options separated by commas as argument. This will override the
options for the given UUID.
If only a list of options, without an UUID, is specified, they apply to any UUIDs not specified elsewhere, and without an entry in
/etc/crypttab.
rd.luks.options= is honored only by initial RAM disk (initrd) while luks.options= is honored by both the main system and the initrd.
luks.key=, rd.luks.key=
Takes a password file name as argument or a LUKS super block UUID followed by a "=" and a password file name.
For those entries specified with rd.luks.uuid= or luks.uuid=, the password file will be set to the one specified by rd.luks.key= or
luks.key= of the corresponding UUID, or the password file that was specified without a UUID.
rd.luks.key= is honored only by initial RAM disk (initrd) while luks.key= is honored by both the main system and the initrd.
SEE ALSO systemd(1), crypttab(5), systemd-cryptsetup@.service(8), cryptsetup(8), systemd-fstab-generator(8)systemd 237 SYSTEMD-CRYPTSETUP-GENERATOR(8)