Computer Architecture-Memory optimization

/proc/slabinfo
/proc/buddyinfo
/proc/zoneinfo
/proc/meminfo


[Email protected]/]# Slabtop

Active/total Objects (% used): 347039/361203 (96.1%)
Active/total Slabs (% used): 24490/24490 (100%)
Active/total Caches (% used): 88/170 (51.8%)
Active/total Size (% used): 98059.38k/99927.38k (98.1%)
Minimum/average/maximum object:0.02k/0.28k/4096.00k

OBJS ACTIVE use OBJ size slabs obj/slab CACHE size NAME
115625 115344 99% 0.10K 3125 Notoginseng 12500K buffer_head
73880 73437 99% 0.19K 3694 14776K dentry
42184 42180 99% 0.99K 10546 4 42184K Ext4_inode_cache
20827 20384 97% 0.06K 353 1412K size-64
16709 13418 80% 0.05K 217 868K Anon_vma_chain
15792 15708 99% 0.03K 141 564K size-32
11267 10323 91% 0.20K 593 2372K vm_area_struct
10806 10689 98% 0.64K 1801 6 7204K Proc_inode_cache
9384 5232 55% 0.04K 102 408K ANON_VMA
7155 7146 99% 0.07K 135 540K selinux_inode_security
7070 7070 100% 0.55K 1010 7 4040K Radix_tree_node
6444 6443 99% 0.58K 1074 6 4296K Inode_cache
5778 5773 99% 0.14K 214 856K Sysfs_dir_cache
3816 3765 98% 0.07K 288K Acpi-operand
2208 2199 99% 0.04K 96K acpi-namespace
1860 1830 98% 0.12K 248K size-128
1440 1177 81% 0.19K 288K size-192
1220 699 57% 0.19K 244K Filp
660 599 90% 1.00K 165 4 660K size-1024



[Email protected] xx]# cat/proc/meminfo |grep hugepageanonhugepages:2048kbhugepages_total:0Hugepages_free:0HUGEPAGES_RSVD:0hugepages_surp:0

1.vi/etc/sysctl.conf
Join
Vm.nr_hugepages = 10

2.sysctl-p
[Email protected]/]# cat/proc/meminfo |grep Huge
anonhugepages:2048 KB
Hugepages_total:10
Hugepages_free:10
hugepages_rsvd:0
hugepages_surp:0
hugepagesize:2048 KB

3. Apply to Applications
[Email protected]/]# mkdir/hugepages
[Email protected]/]# mount-t HUGETLBFS none/hugepages

[[email protected]/]# dd If=/dev/zero of=/hugepages/a.out bs=1m count=5

 hugetable page: 
 
 Hugetlbfs support is  built on top of multiple page size Support this is   provided by the most modern 
 Architecturesusers can use the huge page support  in  Linux kernel by either 
   
    using  
     The mmap system call or 
 Standard SYSV shared memory system calls (Shmget, Shmat) Cat /proc/meminfo | grep hugepage 
   

 improving TLB performance: 
 
 Kernel must usually flush TLB entries upon a context switch  use free, contiguous physical pages automatically via the buddy allocator /proc/buddyinfomanually via Hugepages (not pageable) Linux supports large sized Pages through the hugepages mechanism sometimes known   Bigpages, largepages or the HUGETLBFS filesystemconsequences TLB cache hits more likely reduces PTE visit count 

Tuning TLB Performance

Check size of Hugepages     -A | grep "Data TLB"     dmesg     /proc/meminfo
Enable hugepages    /etc/sysctl.conf       = n
    2.Kernel parameter     //operating system start simultaneous parameter        hugepages=if  needed by application
      is mounted     mkdir  /hugepages     -t  hugetlbfs  None  /Hugepages       do not require HUGETLBFS

 trace every system call made by a program 
 Strace -o/tmp/strace.out -p pidgrep mmap /tmp/strace.  out 
 
  summarize system Callsstrace -C-p PID orstrace -c COMMAND 
 Strace Co Mmandother usesinvestigate   Contentionsidentify problems caused by improper file Permissionspinpoint IO problems  

Strategies for using memory
Using memory optimization

 for Tiny Memory Objects  Slab Cache
  Cat/proc/slabinfo
 for Slower subsystems    Filesystem Metadata:buffer Cache (Slab cache)   //Cached file metadata    Disk io:page cache                              /cache data    interprocess Communications:shared       Memories//Shared memory    Network io:buffer cache, ARP cache, connection tracking      3. Considerations when tuning memory how    should pages is reclaimed to avoid pressure?     Larger writes is usually more efficient due to re-sorting

Memory parameter settings:
Vm.min_free_kbytes:
1. The system crashes because of memory consumption
2. So keep free memory remaining, when the process requests memory allocation, insufficient will swap the other memory to swap, thus freeing up enough space to give the request
Tuning Vm.min_free_kbytes only is necessary when the a application regularly needs to allocate a large block of memory and then Frees that same memory usage:
It may well is the CaseThat 
The system has too little disk bandwidth,
Too little CPU power, or
Too little memory to handle it load

Linux provides such a parameter, min_free_kbytes, to determine the threshold at which the system starts to reclaim memory and to control the system's free memory. The higher the value, the sooner the kernel starts to reclaim memory, and the higher the free memory.
Http://www.cnblogs.com/itfriend/archive/2011/12/14/2287160.htmlConsequences reduces service time forDemand Paging Memory isNot available forOther useage Can cause pressure on zone_normal

Linux server memory usage exceeds threshold, triggering alarms. Troubleshooting first, the memory usage of the system is observed through the free command, which is displayed as follows: Total used free shared buffers cached Mem:24675796   24587144      88652          0     357012    1612488-/+ Buffers/cache:22617644    2058152Swap:2096472     108224    1988248one can see that the total memory is 24675796KB, 22617644KB is used, and only 2058152KB is left. Then, with the top command, shift+m sort by memory, observe the system using the largest memory process, found that only occupied 18GB of memory, the other processes are very small, can be ignored. So there's nearly 4GB of memory (22617644KB-18GB, about 4GB) where to use it? Further, through the cat/proc/meminfo found that there were nearly 4GB (3688732KB) of slab memory: ... Mapped:25212KB Slab:3688732KB pagetables:43524KB ... Slab is used to store the kernel data structure cache, and then the Slabtop command is used to view this portion of memory usage: OBJS ACTIVE use obj SIZE slabs obj/SLAB CACHE SIZE NAME13926348 13926348  -%0.21K773686        -3494744K Dentry_cache334040 262056   +%0.09K8351        +33404K Buffer_head151040 150537   About%0.74K30208        5120832K Ext3_inode_cache found that most of them (about 3.5GB) were used in Dentry_cache. Problem solving1. Modify/proc/sys/vm/drop_caches, release the cache memory space occupied by slab (refer to Drop_caches's official documentation): Writing to ThisWould cause the kernel to drop clean caches, dentries and Inodes frommemory, causing that memory to become free. To free Pagecache:* Echo1>/proc/sys/vm/drop_caches to free dentries and inodes:* Echo2>/proc/sys/vm/drop_caches to free Pagecache, dentries and inodes:* Echo3>/proc/sys/vm/Drop_caches as This  isA non-destructive operation, and dirty objects is not freeable, the user should run"Sync"Firstinchorder to
Make sure allcached objects is freed. This tunable was addedinch 2.6. -. 2. Method 1 requires the user to have root privileges, if not root, but with sudo permissions, which can be set by the SYSCTL command: $sync $sudo sysctl-W vm.drop_caches=3$sudo sysctl-W vm.drop_caches=0#recovery drop_caches operation can be done via sudo sysctl-A | grep drop_caches to see if it takes effect.

Computer Architecture-Memory optimization