hardware settings
CPU

The /proc directory is mounted to a special filesystem contained within RAM that lists system information made available by the Linux kernel; because this is an administrative filesystem, all files within are readable only by the root user.

/proc/cpuinfo

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
stepping        : 2
cpu MHz         : 2393.963
cache size      : 12288 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
  • Processor: The total threads. Start from 0, The processor numbers (which are the number of the cpuNUMBER entries in /sys/devices/system/cpu) correspond to the total threads. if you have 2 physical cpu, 4 cores of each , 2 Thread(s) per core, then you have 16 threads in total, the processor from 0 to 15.
  • cpu cores: the cores per physical cpu.
  • physical id: The id of the physical cpu,start from 0. If you have 2 physical cpu, you will see physical id 0 and 1.

Another command is lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    2
Core(s) per socket:    4
CPU socket(s):         2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Stepping:              2
CPU MHz:               2393.963
BogoMIPS:              4787.83
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15
Memory

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-proc-meminfo.html

Terms

  • Anonymous pages – Pages that are allocated by applications. So if you do malloc() you are going to get an anonymous page.
  • Pagecache – Pages that contain data from a disk somewhere.

Values

  • MemTotal: How much RAM you have plugged into your motherboard.
  • MemFree: How much of that RAM isn’t being used.
  • Buffers: How much RAM is used by struct buffer_heads. Basically if you use ext* this is how much metadata is being held in ram.
  • Cached: How much RAM is being used by file data.
  • SwapCached: Total amount of Swap space that’s actually in memory right now.
  • Active: Active anonymous pages + Active pagecache.
  • Inactive: Inactive anonymous pages + Inactive pagecache.
  • Unevictable: These pages aren’t going anywhere, they are pinned, cannot be swapped or reclaimed. Includes kernel pages and Mlocked pages.
  • Mlocked: Just mlocked() pages from userspace.
  • SwapTotal: Total swap space.
  • SwapFree: How much swap space is free.
  • Dirty: Pagecache pages that are dirty, waiting to be written to disk.
  • Writeback: Pagecache pages that are currently being written to disk but have not been completed yet.
  • AnonPages: Total number of anonymous pages, will include anonymous hugepages.
  • Mapped: Number of file backed mmap()’ed pages.
  • Shmem: Size of shared memory, anybody who did mmap() with MAP_SHARED|MAP_ANONYMOUS
  • Slab: Size of allocations made by the kernel
  • SReclaimable: Kernel allocations that are reclaimable, for example XFS has a shrinker for its metadata allocations and so allocations made of that pool are marked as reclaimable
  • SUnreclaim: Kernel allocations that are unreclaimable
  • KernelStack: Pages used for kernel stack space
  • PageTables: The memory needed to keep track of all the pages in the system
  • NFS_Unstable: Like Writeback but for NFS, since it has no “completion” in the same sort of way device backed pages do. Pages being written and waiting on a COMMIT message from the * NFS server to say that the write has completed. (I could be a little off on the semantics since I’m not an NFS developer but I think it’s mostly correct)
  • Bounce: Bounce buffers. Some file systems will allow you to dirty pages while they are being written, which if you do things like data csumming can fuck you because you need the csum to match what makes it to disk. So if your device requires stable pages it will allocate a page, copy the dirty page into it, and then write the copy to disk to make sure it is stable. That’s what this is for.
  • WritebackTmp: Used for FUSE, it’s the same thing as Writeback or NFS_Unstable, just FUSE-ified.
  • CommitLimit: How much we are allowed to try to allocate. You can malloc() to your hearts content but until you go to write to that area there are no pages backing that address. That is what the commit/overcommit stuff does, allows you to malloc() up to the CommitLimit before malloc() returns -ENOMEM.
  • Committed_AS: How much is currently committed. Basically all of the malloc()’s added up.
  • VmallocTotal: How much the kernel can vmalloc() before it complains loudly.
  • VmallocUsed: How much the kernel has vmalloc()’ed.
  • VmallocChunk: The largest chunk of vmalloc’able area. Usually just == to VmallocTotal.
  • HardwareCorrupted: ECC at it’s finest.
  • HugePages*: Accounting for hugepages
  • Hugepagesize: The size of each hugepage on this system
  • DirectMap*: This is x86 specific, basically available direct mapped slots. I don’t quite understand the direct mapping scheme, but it’s more for MM/arch developers than users.

Some things not shown in my meminfo

  • HighTotal, HighFree, LowTotal, LowFree: If you have a 32bit kernel with a shittone of memory then your memory will be split between low and high sections. Low memory is available for the kernel to use since it can just address it and get to it. High memory is for pagecache and user memory since we are allowed to go through the fault handler to get to that stuff.

 

 

SAN and ISCSI

A single iSCSI target can be used by multiple computers or iSCSI initiators across a network. The computers that use the same iSCSI target are said to be part of the same SAN. As a result, iSCSI is often referred to as a SAN technology.

RAID

Three types of RAID: software, hardware, firmware.

First RAID volume will use a multiple disk (md) device file that starts with number 127 (/dev/md127). Your second RAID volume will use the device file /dev/md128, and so on.

Command to manage software RAID: mdadm

 Zettabyte File System (ZFS)

ZFS is a high-performance filesystem and volume management software that was designed for large-scale Linux systems that need to store data on multiple
disks, SANs, and remote systems.

Zpool: command to manage the ZFS.

    • zpool create: create a ZFS volume
    • zpool list volume name: list the detail of the volume
    • zpool remove: remove the ZFS volume
    • zpool status volume: list the detail of the disks which are part of the volume
    • zpool iostat volume:

For example we can use the following command to view detailed performance metrics of fpool for 100 times in 5 seconds interval we can use the following command.

1
# zpool iostat –v fpool 5 100
  • zpool detach volume disk: detach the disk from the volume.
  • zpool attach volume disk: attach the disk to the volume

Server installation: no GUI is loaded during the installation.

  • To view the hardware detected during boot time, you can use the dmesg command.
  • /var/log/boot.log: view the system processes that started successfully or unsuccessfully during boot time.
  • journalctl command: with the –b option to view the same information that would normally be stored within /var/log/boot.log, /var/log/messages, or /var/log/syslog files.For example: The following command only displays boot information from the current day:
    [root@server1 ~]# journalctl –b ––since=today | less
System Rescue:

The process of using a live OS to repair problems on another Linux system installed on the hard disk is commonly called system rescue.