Note LPI trong ngày (31/07/2008)

Tháng Bảy 31, 2008

1. download and untar metasploit framework
$ wget
$ tar xvzf framework-x.x.tar.gz
$ cd framework*

2. install ruby
# yum -y install ruby

3. install subversion-perl
# yum -y install subversion-perl

4. $svn update

Done !

How to install MYTOP

Tháng Bảy 26, 2008

Description: “mytop is a console-based (non-gui) tool for monitoring the threads and overall performance of a MySQL 3.22.x, 3.23.x” ( )

Note: Is necessary to install 2 perl modules to ensure that mytop will work.

1. Installing TermReadKey
On some folder (eg. /root/dwl):
# wget
# tar -zxf TermReadKey-2.30.tar.gz
# cd TermRead*
# perl Makefile.PL
# make test
# make
# make install

2. Installing DBI
On some folder (eg. /root/dwl):
# wget
# tar -zxf DBI-1.48.tar.gz
# cd DBI*
# perl Makefile.PL
# make test
# make
# make install

3. Installing mytop:
On some folder (eg. /root/dwl):
# wget
# tar -zxf mytop-1.4.tar.gz
# cd mytop*
# perl Makefile.PL
# make test
# make
# make install


Run : mytop -u root -p password -d database_name

Variables in Linux

Tháng Bảy 26, 2008

The env, set, and printenv commands display all environment variables and their values. env and set are also used to set environment variables and are often incorporated directly into the shell

set : hiển thị cả environment variables & shell variables (các giá grị này được khởi tạo ban đầu bởi file /etc/bashrc)

env/printenv : chỉ hiển thị  environment variables (các giá grị này được khởi tạo ban đầu bởi file /etc/profile)

Shell Variable (lệnh set bao gồm shell & environment variables) : Variable trong một shell chỉ có giá trị trong shell đó. Khi exit khỏi shell này, variables bị hủy.

Environment Variable (lệnh printenv, env, export trong bash hoặc setenv trong csh) : Variable trong environment có giá trị trong mọi shell thuộc về account đó. Tạo shell nào ra (với cùng account và cùng environment variables) cũng mang các variables ấn định sẵn như nhau.

Hiểu tổng quan thì environment variable là permanent còn shell variable chỉ có giá trị tức thời trong shell đó

let : Perform arithmetic on shell variables

In Linux (Shell), there are two types of variable:
(1) System variables – Created and maintained by Linux itself. This type of variable defined in CAPITAL LETTERS.
(2) User defined variables (UDV) – Created and maintained by user. This type of variable defined in lower letters.

You can see system variables by giving command like $ set, some of the important System variables are:

System Variable
BASH=/bin/bash Our shell name
BASH_VERSION=1.14.7(1) Our shell version name
COLUMNS=80 No. of columns for our screen
HOME=/home/vivek Our home directory
LINES=25 No. of columns for our screen
LOGNAME=students students Our logging name
OSTYPE=Linux Our Os type
PATH=/usr/bin:/sbin:/bin:/usr/sbin Our path settings
PS1=[\u@\h \W]\$ Our prompt settings
PWD=/home/students/Common Our current working directory
SHELL=/bin/bash Our shell name
USERNAME=vivek User name who is currently login to this PC

*note : /etc/profile là global file để set value của các environment variables & set các startup program. Còn /etc/bashrc là global file để set default permission, permanent aliases và permanent functions

Statup script for Login shell :

+ /etc/profile : global file chứa các environment variable và các startup program (affect for all user)

+ /etc/bashrc : global file chứa các default permission, permanent alias và các permanent function (affect for all user)

+ /etc/profile.d

+ ~/.bash_profile (affect for specific user)

+ ~/.bashrc (affect for specific user)

Statup script for Non-Login shell :

+ ~/.bashrc

+ /etc/bashrc

+ /etc/profile.d

+ ~/.bash_logout (affect for specific user)

Note about ps

Tháng Bảy 13, 2008

Trong lệnh ps thì -e là show dạng standard syntax, còn a là dạng BSD syntax

vd : ps -e => Standard syntax

      ps ax => BSD syntax

ps -ejH & ps axjf: show process theo tree

ps ax : chỉ show process và id, ko có memory usage và các info khác

ps aux : show process cùng với memory usage, cột thứ 6 chính là total memory mà process đó đả sử dụng(dạng KB)

ps axuf : vừa xem process dạng tree và show luôn memory usage của process đó

TLB – HugePage …

Tháng Bảy 12, 2008

Translation lookaside buffer (TLB) là CPU cache để cache  các virtual-to-physical memory address translation, TLB được sử dụng bởi memory management

TLB là 1 table gồm chứa các các entry (mỗi entry là Page Table, map từ virtual address sang physical adress ). Nó còn gọi là content-addressable memory (CAM), nếu 1 requested address có trong bảng TLB thì nó sẽ lấy ra xài cò nếu ko có thì translation sẽ diễn ra (bằng cách sử dụng Page Table) nhưng việc translation này sẽ chậm hơn

TLB nằm giữa CPU và CPU cache hoặc nằm giữa CPU cache và primary storage memory, việc này phục thuộc cache sử dụng physical hay virtual address. Nếu cache sử dụng virtual memory, request được send trực tiếp từ CPU đến cache (cache sẽ sử dụng TLB nếu cần). Nếu cache sử dụng physical memory, cứ mỗi khi có memory operation thì CPU sẽ lookup TLB và kết quả là physical adress sẽ được send đến cache

1 cách optimize phổ biến trong việc cache physical address là thực hiện song song TLB lookup với cache access


Huge Page (hay còn gọi là bigpages) là 1 feature trong Linux kernel cho phép memory được manage với những larger page (default thì 1 page chỉ có 4 KB, Default Huge Page là 2MB) 2MB – 4MB. Huge Page được sử dụng cả trong hệ thống 32-bit và 64-bit, việc sử dụng Huge Page ko phụ thuộc vào 32-bit hay 64-bit mà phục thuộc vào lượng memory trong system vì Huge Page chỉ đặc biệt hiệu quả trong system với lượng memory lớn (do lượng memory lớn thì phải đi kèm với 64-bit => huge page thường được sử dụng trong 64-bit system), còn trong hệ thống với memory ít thì nó lại phản tác dụng. Do 1 khi đã sử dụng, các Huge Page là những phần physical memory liên tiếp nhau và sẽ ko bao giời được swap out => dẫn đến việc memory swapping ko hiệu quả

Trong Linux Kernel 2.6, support thêm 1 feature mới là Huge TLB Page, thay thế cho chức năng Huge Page ở trên. Huge TLB cũng giống như Huge Page nhưng nó khác 1 ít trong cơ chế họat động. Vì số lượng entry trong TLB thì rất limited và 1 TLB miss thì rất hao tốn. Do đó, với Huge TLB Page support, mỗi 1 large TLB entry riêng có thể map 1 page nặng 2MB – 4MB, dẫn đến việc giảm số lượng các TLB miss và gia tăng performance. Chức năng Huge Page này rất quan trọng trong các system có hàng GB RAM trở lên và trong các Database System

Các Huge Page được reserve bên trong kernel và được map bởi các large TLB entry, đây là chức năng rất cần thiết trong các database application lớn. User application có thể sử dụng Huge Page thông qua mmap system calls hoặc shared memory system calls

Các Huge Page trong Huge TLB Page phải được cấp phát trước (preallocated) bởi super user

How to build rpm package from source file (*.src.rpm) ?

# rpmbuild –rebuild *.src.rpm

Most probably, you’ll find the sources in /root/rpmbuild/SOURCES and the RPM file in /root/rpmbuild/RPMS . If not, try /usr/src/redhat/SOURCES and /usr/src/redhat/RPMS

Nguồn :

Hardening the TCP/IP stack to SYN attacks
Mariusz Burdach 2003-09-10


Most people know how problematic protection against SYN denial of service attacks can be. Several methods, more or less effective, are usually used. In almost every case proper filtering of packets is a viable solution. In addition to creating packet filters, the modification of the TCP/IP stack of a given operating system can be performed by an administrator. This method, the tuning of the TCP/IP stack in various operating systems, will be described in depth in this article.

While SYN attacks may not be entirely preventable, tuning the TCP/IP stack will help reduce the impact of SYN attacks while still allowing legitimate client traffic through. It should be noted that some SYN attacks do not always attempt to upset servers, but instead try to consume all of the bandwidth of your Internet connection. This kind of flood is outside the scope of scope of this article, as is the filtering of packets which has been discussed elsewhere.

What can an administrator do when his servers are under a classic, non-bandwidth flooding SYN attack? One of most important steps is to enable the operating system’s built-in protection mechanisms like SYN cookies or SynAttackProtect. Additionally, in some cases it is worth tuning parameters of the TCP/IP stack. Changing the default values of stack variables can be another layer of protection and help better secure your hosts. In this paper I will concentrate on:


  • Increasing the queue of half-open connections (in the SYN RECEIVED state).
  • Decreasing the time period of keeping a pending connection in the SYN RECEIVED state in the queue. This method is accomplished by decreasing the time of the first packet retransmission and by either decreasing the number of packet retransmissions or by turning off packet retransmissions entirely. The process of packet retransmissions is performed by a server when it doesn’t receive an ACK packet from a client. A Packet with the ACK flag finalizes the process of the three-way handshake.

Note that an attacker can simply send more packets with the SYN flag set and then the above tasks will not solve the problem. However, we can still increase the likelihood of creating a full connection with legitimate clients by performing the above operations.

We should remember that our modification of variables will change the behavior of the TCP/IP stack. In some cases the values can be too strict. So, after the modification we have to make sure that our server can properly communicate with other hosts. For example, the disabling of packet retransmissions in some environments with low bandwidth can cause a legitimate request to fail. In this article you will find a description of the TCP/IP variables for the fallowing operating systems: Microsoft Windows 2000, RedHat Linux 7.3, Sun Solaris 8 and HP-UX 11.00. These variables are similar or the same in current releases.

Definitions: SYN flooding and SYN spoofing

A SYN flood is a type of Denial of Service attack. We can say that a victim host is under a SYN flooding attack when an attacker tries to create a huge amount of connections in the SYN RECEIVED state until the backlog queue has overflowed. The SYN RECEIVED state is created when the victim host receives a connection request (a packet with SYN flag set) and allocates for it some memory resources. A SYN flood attack creates so many half-open connections that the system becomes overwhelmed and cannot handle incoming requests any more.

To increase an effectiveness of a SYN flood attack, an attacker spoofs source IP addresses of SYN packets. In this case the victim host cannot finish the initialization process in a short time because the source IP address can be unreachable. This malicious operation is called a SYN spoofing attack.

We need to know that the process of creating a full connection takes some time. Initially, after receiving a connection request (a packet with SYN flag set), a victim host puts this half-open connection to the backlog queue and sends out the first response (a packet with SYN and ACK flags set). When the victim does not receive a response from a remote host, it tries to retransmit this SYN+ACK packet until it times out, and then finally removes this half-open connection from the backlog queue. In some operating systems this process for a single SYN request can take about 3 minutes! In this document you will learn how to change this behavior. The other important information you need to know is that the operating system can handle only a defined amount of half-open connections in the backlog queue. This amount is controlled by the size of the backlog queue. For instance, the default backlog size is 256 for RedHat 7.3 and 100 for Windows 2000 Professional. When this size is reached, the system will no longer accept incoming connection requests.

How to detect a SYN attack

It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.


# netstat -n -p TCP

tcp        0      0       SYN_RECV    -
tcp        0      0       SYN_RECV    -
tcp        0      0       SYN_RECV    -
tcp        0      0       SYN_RECV    -
tcp        0      0     SYN_RECV    -
tcp        0      0         SYN_RECV    -
tcp        0      0        SYN_RECV    -
tcp        0      0     SYN_RECV    -
tcp        0      0      SYN_RECV    -

We can also count how many half-open connections are in the backlog queue at the moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state are kept in the backlog queue.


# netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l

The other method for detecting SYN attacks is to print TCP statistics and look at the TCP parameters which count dropped connection requests. While under attack, the values of these parameters grow rapidly.

In this example we watch the value of the TcpHalfOpenDrop parameter on a Sun Solaris machine.


# netstat -s -P tcp | grep tcpHalfOpenDrop
       tcpHalfOpenDrop     =   473

It is important to note that every TCP port has its own backlog queue, but only one variable of the TCP/IP stack controls the size of backlog queues for all ports.

The backlog queue

The backlog queue is a large memory structure used to handle incoming packets with the SYN flag set until the moment the three-way handshake process is completed. An operating system allocates part of the system memory for every incoming connection. We know that every TCP port can handle a defined number of incoming requests. The backlog queue controls how many half-open connections can be handled by the operating system at the same time. When a maximum number of incoming connections is reached, subsequent requests are silently dropped by the operating system.

As mentioned before, when we detect a lot of connections in the SYN RECEIVED state, host is probably under a SYN flooding attack. Moreover, the source IP addresses of these incoming packets can be spoofed. To limit the effects of SYN attacks we should enable some built-in protection mechanisms. Additionally, we can sometimes use techniques such as increasing the backlog queue size and minimizing the total time where a pending connection in kept in allocated memory (in the backlog queue).

Built-in protection mechanisms

Operating system: Windows 2000

The most important parameter in Windows 2000 and also in Windows Server 2003 is SynAttackProtect. Enabling this parameter allows the operating system to handle incoming connections more efficiently. The protection can be set by adding a SynAttackProtect DWORD value to the following registry key:



In general, when a SYN attack is detected the SynAttackProtect parameter changes the behavior of the TCP/IP stack. This allows the operating system to handle more SYN requests. It works by disabling some socket options, adding additional delays to connection indications and changing the timeout for connection requests.

When the value of SynAttackProtect is set to 1, the number of retransmissions is reduced and according to the vendor, the creation of a route cache entry is delayed until a connection is made. The recommended value of SynAttackProtect is 2, which additionally delays the indication of a connection to the Windows Socket until the three-way handshake is completed. During an attack, better performance in handling connections is achieved by disabling the use of a few parameters (these parameters are usually used by the system during the process of creating new connections). The TCPInitialRTT parameter, which defines the time of the first retransmission, will no longer work. It’s impossible to negotiate the window size value. Also, the scalable windows option is disabled on any socket.

As we can see, by enabling the SynAttackProtect parameter we don’t change the TCP/IP stack behavior until under a SYN attack. But even then, when SynAttackProtect starts to operate, the operating system can handle legitimate incoming connections.

The operating system enables protection against SYN attacks automatically when it detects that values of the following three parameters are exceeded. These parameters are TcpMaxHalfOpen, TcpMaxHalfOpenRetried and TcpMaxPortsExhausted.

To change the values of these parameters, first we have to add them to the same registry key as we made for SynAttackProtect.

The TcpMaxHalfOpen registry entry defines the maximum number of SYN RECEIVED states which can be handled concurrently before SYN protection starts working. The recommended value of this parameter is 100 for Windows 2000 Server and 500 for Windows 2000 Advanced Server.

TcpMaxHalfOpenRetried defines the maximum number of half-open connections, for which the operating system has performed at least one retransmission, before SYN protection begins to operate. The recommended value is 80 for Windows 2000 Server, and 400 for Advanced Server.

The TcpMaxPortsExhausted registry entry defines the number of dropped SYN requests, after which the protection against SYN attacks starts to operate. Recommended value is 5.

Operating system: Linux RedHat

RedHat, like other Linux operating systems, has implemented a SYN cookies mechanism which can be enabled in the following way:


# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Note that to make this change permanent we need to create a startup file that sets this variable. We must do the same operation for other UNIX variables described in this paper because the values for these variables will return to default upon system reboot.

SYN cookies protection is especially useful when the system is under a SYN flood attack and source IP addresses of SYN packets are also forged (a SYN spoofing attack). This mechanism allows construction of a packet with the SYN and ACK flags set and which has a specially crafted initial sequence number (ISN), called a cookie. The value of the cookie is not a pseudo-random number generated by the system but instead is the result of a hash function. This hash result is generated from information like: source IP, source port, destination IP, destination port plus some secret values. During a SYN attack the system generates a response by sending back a packet with a cookie, instead of rejecting the connection when the SYN queue is full. When a server receives a packet with the ACK flag set (the last stage of the three-way handshake process) then it verifies the cookie. When its value is correct, it creates the connection, even though there is no corresponding entry in the SYN queue. Then we know that it is a legitimate connection and that the source IP address was not spoofed. It is important to note that the SYN cookie mechanism works by not using the backlog queue at all, so we don’t need to change the backlog queue size. More information about SYN cookies can be found at

Also note that the SYN cookies mechanism works only when the CONFIG_SYNCOOKIES option is set during kernel compilation.

The next section will describe other useful methods of protection against SYN attacks. I would like to emphasize that under heavy SYN attacks (like Distributed SYN flooding attack) these methods may help but still not solve the problem.

Increasing the backlog queue

Under a SYN attack, we can modify the backlog queue to support more connections in the half-open state without denying access to legitimate clients. In some operating systems, the value of the backlog queue is very low and vendors often recommend increasing the SYN queue when a system is under attack.

Increasing the backlog queue size requires that a system reserve additional memory resources for incoming requests. If a system has not enough memory for this operation, it will have an impact on system performance. We should also make sure that network applications like Apache or IIS can accept more connections.

Operating system: Windows 2000

Aside from described above TcpMaxHalfOpen and TcpMaxHalfOpenRetried variables, in Windows 2000 the number of connections handled in the half-open state can be set through a dynamic backlog. Configuration of this dynamic backlog is accomplished via the AFD.SYS driver. This kernel-mode driver is used to support Windows Socket applications like FTP and Telnet. To increase the number of half-open connections, AFD.SYS provides four registry entries. All of these values, corresponding to AFD.SYS, are located under the following registry key:



The EnableDynamicBacklog registry value is a global switch to enable or disable a dynamic backlog. Setting it to 1 enables the dynamic backlog queue.

MinimumDynamicBacklog controls the minimum number of free connections allowed on a single TCP port. If the number of free connections drops below this value, then additional free connections are created automatically. Recommended value is 20.

The MaximumDynamicBacklog registry value defines the sum of active half-open connections and the maximum number of free connections. When this value is exceeded, no more free connections will be created by a system. Microsoft suggests that this value should not exceed 20000.

The last DynamicBacklogGrowthDelta parameter controls the number of free connections to be created when additional connections are necessary. Recommended value: 10.

The table below shows the recommended values for the AFD.SYS driver:


Subkey Registry Value Entry Format Value
EnableDynamicBacklog DWORD 1
MinimumDynamicBacklog DWORD 20
MaximumDynamicBacklog DWORD 20000
DynamicBacklogGrowthDelta DWORD 10

Operating system: Linux

A tcp_max_syn_backlog variable defines how many half-open connections can be kept by the backlog queue. For instance 256 is a total number of half-open connections handled in memory by Linux RedHat 7.3. The TCP/IP stack variables can be configured by sysctl or standard Unix commands. The following example shows how to change the default size of the backlog queue by the sysctl command:


# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"

Operating system: Sun Solaris

In Sun Solaris there are two parameters which control the maximum number of connections. The first parameter controls the total number of full connections. The second tcp_conn_req_max_q0 parameter defines how many half-open connections are allowed without the dropping of incoming requests. In Sun Solaris 8, the default value is set to 1024. Using the ndd command we can modify this value.


# ndd -set /dev/tcp tcp_conn_req_max_q0 2048

Operating system: HP-UX

In HP-UX, a tcp_syn_rcvd_max TCP/IP stack variable is responsible for control of the maximum number of half-open connections in the SYN RECEIVE state. In HP-UX 11.00 this value is set to 500. We can change this value by using the ndd command, similar to the one used in a Sun Solaris system.


# ndd -set /dev/tcp tcp_syn_rcvd_max 2048


Decreasing total time of handling connection request

As we know, SYN flooding/spoofing attacks are simply a series of SYN packets, mostly from forged IP addresses. In the last section we tried to increase the backlog queue. Now that our systems can handle more SYN requests, we should decrease the total time we keep half-open connections in the backlog queue. When a server receives a request, it immediately sends a response with the SYN and ACK flags set, puts this half-open connection into the backlog queue, and then waits for a packet with the ACK flag set from the client. When no response is received from the client, the server retransmits a response packet (with the SYN and ACK flags set) several times (depending on default value in each operating system) by giving the client a chance to send the ACK packet again. It is clear that when the source IP address of client was spoofed, the ACK packet will never arrive. After a few minutes the server removes this half-open connection. We can speed up this time of removing connections in the SYN RECEIVED state from the backlog queue by changing time of first retransmission and by changing the total number of retransmissions.

Another technique of protection against SYN attacks is switching off some TCP parameters that are always negotiated during the three-way handshake process. Some of these parameters are automatically turned off by mechanisms described in the first section (SynAttackProtect and Syncookies).

Now, I will describe TCP/IP stack variables which allow a decrease in the time half-open connections are kept in the backlog queue.

Operating system: Windows 2000

In Windows 2000, the default time for a first retransmission is set to 3 seconds (3000 milliseconds) and can be changed by modifying the value of the TcpInitialRtt registry entry (for every interface). For example, to decrease time of a first retransmission to 2 seconds we have to set this registry value to 2000 milliseconds in decimal format. The number of retransmissions (packets with the SYN and ACK flags set) is controlled by a TcpMaxConnectResponseRetransmissions registry parameter which has to be added to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key.

The table below contains a few examples of values and corresponding times for keeping half-open connections in the backlog queue (the time of a first retransmission is set to 3 seconds).


Value Time of retransmission Total time to keep half-open connections in the backlog queue
1 in 3rd second 9 seconds
2 in 3rd and 9th second 21 seconds
3 in 3rd , 9th and 21st second 45 seconds

We can set this registry value to 0, whereby Windows doesn’t try to retransmit packets at all. In this case, the system sends only one response and cancels the half-open connection after 3 seconds. This setting is ignored when its value is equal or greater than 2 and when SynAttackProtect is enabled.

Operating system: Linux RedHat

A tcp_synack_retries variable is responsible for controlling the number of retransmissions in Linux operating system. Its default value is set to 5 for most Linux operating systems, which causes the half-open connection to be removed after 3 minutes. In the below table there are calculations for other values.


Value Time of retransmission Total time to keep half-open connections in the backlog queue
1 in 3rd second 9 seconds
2 in 3rd and 9th second 21 seconds
3 in 3rd , 9th and 21st second 45 seconds

Operating system: Sun Solaris

In this operating system it is impossible to turn off retransmissions of packets directly using the ndd command. Moreover, in Sun Solaris there are parameters which are non-configurable by ndd and which control the number of retransmissions (at least 3) and total time of packet retransmissions (at least 3 minutes). More information about these parameters can be found in the “Solaris 2.x – Tuning Your TCP/IP stack and More” document.

Operating system: HP-UX

For HP-UX, the time spent handling half-open connections in the backlog queue is controlled by the tcp_ip_abort_cinterval parameter. By using the ndd command we can define how long a HP-UX operating system will be waiting for the ACK packet. We can control how many retransmissions will be performed indirectly by changing this value. Have a look at the table below.


Value Time of retransmission Total time to keep half-open connections in the backlog queue
1000 1 second
5000 in 2nd second 5 seconds
10000 in 2nd and 5th second 10 seconds
60000 In 2nd, 5th, 11th, 23rd and 47th second 1 minute

We can change the time of a first retransmission by modifying tcp_rexmit_interval_initial. Intervals of subsequent retransmissions are controlled by two parameters: tcp_rexmit_interval and tcp_rexmit_interval_min. These three variables are the same as in a Sun Solaris operating system.


The methods of hardening the TCP/IP stack that are presented in this article make servers more resistant to SYN flooding and SYN spoofing – Denial of Service attacks. A modification of your default TCP/IP stack settings is also recommended during the process of securing of the operating system.


Mariusz Burdach is a computer security consultant who specializes in vulnerability assessment, intrusion detection and computer forensics. During the last few years he has worked as a consultant in the European Network Security Institute where he conducted penetration tests, vulnerability assessments and security audits for Internet banks, government and financial institutions in Poland. He is co-author of the Solaris Security Administrator’s Guide, a step-by-step guide to securing SUN’s Solaris operating system. Comments on this article are appreciated, send them to

Source ::

If you need any assistance, We can provide you for a small fee. please email us


Tháng Bảy 10, 2008

Hugepages is a mechanism that allows the Linux kernel to utilise the multiple page size capabilities of modern hardware architectures. Linux uses pages as the basic unit of memory, where physical memory is partitioned and accessed using the basic page unit. The default page size is 4096 Bytes in the x86 architecture. Hugepages allows large amounts of memory to be utilised with a reduced overhead. Linux uses “Transaction Lookaside Buffers” (TLB) in the CPU architecture. These buffers contain mappings of virtual memory to actual physical memory addresses. So utilising a huge amount of physical memory with the default page size consumes the TLB and adds processing overhead. The Linux kernel is able to set aside a portion of physical memory to be able be addressed using a larger page size. Since the page size is higher, there will be less overhead managing the pages with the TLB. In the Linux 2.6 series of kernels, hugepages is enabled using the CONFIG_HUGETLB_PAGE feature when the kernel is built. Systems with large amount of memory can be configured to utilise the memory more efficiently by setting aside a portion dedicated for hugepages. The actual size of the page is dependent on the system architecture. A typical x86 system will have a Huge Page Size of 2048 kBytes. The huge page size may be found by looking at the /proc/meminfo :

# cat /proc/meminfo |grep Hugepagesize Hugepagesize: 2048 kB

Number of Hugepages can be allocated using the /proc/sys/vm/nr_hugepages entry, or by using the sysctl command.

To view the current setting using the /proc entry:
# cat /proc/sys/vm/nr_hugepages 0

To view the current setting using the sysctl command:
# sysctl vm.nr_hugepages vm.nr_hugepages = 0

To set the number of huge pages using /proc entry:
# echo 5 > /proc/sys/vm/nr_hugepages

To set the number of hugepages using sysctl:
# sysctl -w vm.nr_hugepages=5 vm.nr_hugepages = 5

It may be necessary to reboot to be able to allocate the number of hugepages that is needed. This is because hugepages requires large areas of contiguous physical memory. Over time, physical memory may be mapped and allocated to pages, thus the physical memory can become fragmented. If the hugepages are allocated early in the boot process, fragmentation is unlikely to have occurred.

It is recommended that the /etc/sysctl.conf file should be used to allocate hugepages at boot time. For example, to allocate 5 hugepages at boot time add the line below to the sysctl.conf file :

vm.nr_hugepages = 5

If the machine supports para virtual guests, then you should see a “pae” flag in /proc/info. This means – the machine has PAE support and can run para virtual guests.

[root@unixfoo root]# cat /proc/cpuinfo | grep pae
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm nx lm
[root@unixfoo root]#

If there is no output for the above command, then the machine is not capable of running a para-virtualized guest.