Linux: Find Out What Process Are Using Swap Space

The top and free command display the total amount of free and used physical and swap memory in the server. How do I determine which process is using swap space under Linux operating systems? How do I find out swap space usage of particular process such as memcached?

You can use the any one of the following techniques but keep in mind that because of shared pages, there is no reliable way to get this information[1]

[a] /proc/meminfo – This file reports statistics about memory usage on the system. It is used by free to report the amount of free and used memory (both physical and swap) on the system as well as the shared memory and buffers used by the kernel. You can also use free, vmstat and other tools to find out the same information.


[b] /proc/${PID}/smaps, /proc/${PID}/status, and /proc/${PID}/stat : Use these files to find information about memory, pages and swap used by each process using its PID.

[c] smem – This command (python script) reports memory usage with shared memory divided proportionally.

Finding out process ID and swap usage

Type the following pidof command to find the process ID of a running program called memcached:

# pidof memcached

Alternatively, use pgrep command to lookup process PID, enter:

# pgrep memcached

Sample outputs (note down PID number #1):

48440
To see swap space used by memcached (PID # 48440), enter (number #2):

# grep --color VmSwap /proc/48440/status

Sample outputs (number #4):

VmSwap:         900 kB
Or the following awk command (number #3):

# awk '/VmSwap/{print $2 " " $3}' /proc/48440/status

Sample outputs (number #4):

Fig.01: Finding out memcached process swap usage
Fig.01: Finding out memcached process swap usage
Listing all process swap space usage

Type the following bash for loop command to see swap space usage per process:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done

Type the following command to sort out output:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less

Sample outputs:

php-cgi 11964 kB
php-cgi 11016 kB
php-cgi 10392 kB
php-cgi 10336 kB
php-cgi 9844 kB
php-cgi 9780 kB
php-cgi 8584 kB
php-cgi 7996 kB
php-cgi 7960 kB
php-cgi 7956 kB
php-cgi 7796 kB
php-cgi 7540 kB
php-cgi 6884 kB
squid 6864 kB
php-cgi 6640 kB
php-cgi 6556 kB
php-cgi 5848 kB
php-cgi 5744 kB
php-cgi 5636 kB
php-cgi 5592 kB
php-cgi 5488 kB
php-cgi 5132 kB
php-cgi 4584 kB
php-cgi 4508 kB
php-cgi 4388 kB
lighttpd 4100 kB
php-cgi 3984 kB
php-cgi 3644 kB
php-cgi 3616 kB
php-cgi 3604 kB
rpc.mountd 3580 kB

Read More

Monitor ping other host using zabbix agent

We needed to monitor ping times from one server to another, neither being the Zabbix server.  Zabbix doesn’t have a way to do this; the only pings that Zabbix can do are from the Zabbix server to another server.

I wrote the attached script to solve this problem.  Install the script onto each client that you need to do this sort of monitoring, in the /etc/zabbix/externalscripts directory (or wherever you have configured them to be).  Make it executable, and add the following lines to the /etc/zabbix/zabbix_agentd.conf file:

       # For pingserver.sh
       UserParameter=pingTimeToServer[*],/bin/bash /etc/zabbix/externalscripts/pingserver.sh $1 $2 $3 $4 $5

Restart the Zabbix client after you put this line in.

You can run the script by hand if you like, the options are:

       pingserver.sh server [option] [count] [maxage] [interval]

server    Server to ping, either ip or dns
option    blank for a single ping
“loss” to get the percentage of lost pings in a range of pings
“min” to get the minimum time in a range of pings
“avg” to get the average time
“max” to get the max time
count     How many times to ping when doing a range of pings
maxage    Max age of tmpfile before doing pings again
interval    Interval between pings during a range.  Must be
greater than 0.2 (only root can go less than 0.2)
To use as an item inside Zabbix, create an item (either in a template or a host) with the following options:

Type:    Zabbix agent
Key:    pingTimeToServer[server [,option [,count [,maxage [,interval]]]]
Type of info:    Numeric (float) (except for “loss”)
For loss option:  Numeric (unsigned)
Units:    all options except loss:        ms
for loss option:                    %

#cat /etc/zabbix/zabbix_agentd.d/userparameter_ping.conf
UserParameter=custom.ping.reachable[*],/bin/ping -c 1 -W 1 -q -n $1 &> /dev/null && echo 1 || echo 0
#systemctl restart zabbix-agent

Zabbix:
Add new item: Key: custom.ping.reachable[8.8.8.8]
Add new trigger: {Hostname:custom.ping.reachable[8.8.8.8].max(#3)}=0

Read More

Cannot start the snmpd service Esxi

Cannot start the snmpd service Esxi

Call "HostServiceSystem.Start" for object "serviceSystem" on ESXi \ failed.

Cannot start the snmpd service Esxi 5.5

Symptoms

The snmpd service fails to start from vCenter Server with the error:

Call "HostServiceSystem.Start" for object "serviceSystem" on "some_IP" ESXi \ failed.

Resolution

To copy the contents of the file to the problem host: 

1. Log in to a console or SSH session on your host. 
2. Go to the directory /etc/vmware:
   
   cd /etc/vmware
3. Run this command to backup the snmp.xml file.
   
   cp snmp.xml snmp.xml.bkup
4. Copy and paste this content into the snmp.xml file:
   
   <?xml version="1.0" encoding="ISO-8859-1"?>
   <config>
   <snmpSettings>
   <enable>true</enable>
   <port>161</port>
   <syscontact></syscontact>
   <syslocation></syslocation>
   <EnvEventSource>indications</EnvEventSource>
   <communities>public</communities>
   <loglevel>info</loglevel>
   <authProtocol></authProtocol>
   <privProtocol></privProtocol>
   </snmpSettings>
   </config>
5. Save and close the file.
6. Start the snmpd service from vCenter Server using the Sphere Client.

source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2056832

Trying to start snmpd on vmware from where i get the following error:
Call "HostServiceSystem.Start" for object "serviceSystem" on ESXi "10.0.0.5" failed.

Turns out that more people are having this problem on ESXi, but there is an easy fix.
ssh into your server and run:

• esxcli system snmp set --communities public
• esxcli system snmp set --enable true
• /etc/init.d/snmpd restart

Read More

{Rảnh Story} wtf rm -rf /* is removed ?

Download Full Log here: https://www.fshare.vn/file/2UVL3EDGTHOO

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.07.22 08:12:30 =~=~=~=~=~=~=~=~=~=~=~=
Using username "hungnv".
Authenticating with public key "rsa-key-20170627"

[root@localhost /]# rm -rf /*
removed ‘/bin’
removed ‘/boot/'
removed ‘/dev/'
removed ‘/etc/'
removed ‘/home'
removed ‘/lib’
removed ‘/lib64’
removed directory: ‘/lost+found’
removed directory: ‘/media’
removed directory: ‘/mnt’
removed directory: ‘/opt’
removed ‘/usr'
rm: cannot remove ‘/proc/
removed ‘/root
removed ‘/run/
removed ‘/sbin’
removed directory: ‘/srv’
rm: cannot remove ‘/sys/
removed directory: ‘/tmp/
removed ‘/var/

Read More

mysql innodb crash recovery như thế nào

Mysql innodb internal là một chủ đề khá sâu. Bản thân tôi cũng chưa bao quát hết. Bài viết này chỉ cung cấp một cái nhìn sơ lược.

Để các bạn không cảm thấy bài viết quá dài dòng, tôi sẽ tóm tắt qua những gì sẽ viết. Từ một hình vẽ về kiến trúc hoạt động của mysql innodb tôi sẽ đi vào phân tích nhiệm vụ chức năng của những khối chính trong hình vẽ, quá trình hoạt động của innodb và sau đó là quá trình mysql thực hiện crash recovery.

Sơ lược mysql innodb internal

Hình vẽ dưới là kiến trúc mysql innodb

Nguồn của hình vẽ nằm tại:
https://www.percona.com/blog/2010/04/26/xtradb-innodb-internals-in-drawing/

KIến trúc gồm hai phần nằm ở cả memory và disk. Mọi thay đổi về dữ liệu đều được thực hiện trên buffer pool trước - Đây là một thành phần của innodb nằm trên memory. Data nằm trong buffer pool ở dạng các page. Mỗi page có kích cỡ chừng 16KB. Một page có hai trạng thái: Dirty page hoặc clean page.

• Dirty page: Là những page có data trong đó thay đổi và chưa được flush xuống disk
• Clean page: Là những page không có data thay đổi hoặc có data thay đổi những vừa được flush xuống disk.

Hành động flush dirty page trong memory xuống disk cũng khá phức tạp. Mysql innodb sử dụng nhiều thành phần khác nhau để đảm bảo data có thể được bảo toàn và phục hồi khi có các sự cố nghiêm trọng như sụt nguồn hay kernel OS có vấn đề gì đó...Mỗi lần flush, innodb flush toàn bộ page 16KB thay vì chỉ flush những thay đổi trên page. Mục đích của mysql innodb là đẩy data từ memory xuống data files (ibd files hoặc ibdata1 tùy vào cấu hình mysql có sử dụng innodb_file_per_table hay không). Các thành phần khác: redo log, undo log, doublewrite buffer chỉ hỗ trợ, nâng cao tính an toàn cho quá trình này.

Để đảm bảo replay được các data nằm trong memory nhưng chưa được flush xuống disk. Innodb sử dụng các redo log (số lượng cũng như kích cỡ của từng redo log có thể được cấu hình). Mặc định innodb sử dụng hai redo log: ib_logfile0 và ib_logfile1. Data được flush đồng thời vào cả hai redo log để tăng tốc.

Để đảm bảo rollback được các transaction chưa kịp commit hoặc có explicit rollback, innodb sử dụng undo log nằm trong system table space ibdata1.

Để đảm bảo loại bỏ các half written pagem innodb sử dụng thêm một doublewrite buffer nằm trong system table space ibdata1

Quá trình hoạt động như sau:
Như hình vẽ, các bạn có thể thấy, từ khu vực memory, có bốn luồng data đẩy xuống khu vực disk. Chúng ta đi vào ba luồng đẩy data xuống redo log, doublewrite buffer và data files.

Innodb sẽ đẩy data xuống redo log nằm trên disk qua một log buffer nằm trên memory. Data ghi xuống redo log thì theo kiểu sequence còn data ghi xuống data files (ibd hoặc ibdata1) thì theo kiểu random do vậy, quá trình ghi data xuống redo log của innodb thường nhanh hơn nhiều. Innodb sẽ cố gắng ghi lại các thay đổi càng nhanh càng tốt xuống redo log còn với data files (ibd hoặc ibdata1) nó sẽ flush định kỳ. Để giảm dung lượng của redo log, bản thân redo log chỉ lưu các thay đổi trong page memory mà không phải toàn bộ page.

Khi flush page memory vào data files, innodb rất có thể gặp phải tình huống half written page. Một page memory có kích cỡ chừng 16KB trong khi đó một block data, đơn vị mang dữ liệu trên disk lại có kích cỡ nhỏ hơn nhiều chỉ là 4KB (Có thể xem block size qua output của lệnh dumpe2fs) nên OS sẽ cần phải fragment data. Trong quá trinhg fragment đó có thể vì nhiều lý do mà toàn bộ các fragment không được flush xuống disk nên data không còn toàn vẹn. Một tình huống khác là các lỗi vê hardware hay nguồn điện có thể làm cho innodb không kịp flush hết 16KB. Kết quả là sẽ có những half written page xuất hiện trong data files. Để giải quyết vấn đề này, innodb sử dụng thêm một doublewrite buffer. ( Tại sao redo log không giúp được gì trong tình huống này ? Vì redo log chỉ chứa các thay đổi trong page chứ không phải toàn bộ page memory ). Như tên gọi, innodb sẽ flush toàn bộ page memory vào doublewrite buffer trước, sau đó nó gọi system call fsync (data chỉ được flush xuống disk sau khi fsync call thành công). Tiếp đó, cũng page memory đó, innodb lại flush vào data files (ibd hoặc ibdata1), sau đó nó gọi system call fsync. Như vậy là cùng một data được flush hai lần. Sự dư thừa này có tác động gì lên performance không ? Thực sự thì không nhiều lắm. Mặc định, innodb vẫn sử dụng doublewrite buffer. Một fsync call không được gọi để flush cho từng page memory một mà thường là cho nhiều page memory nên sẽ không tạo ra quá nhiều hoạt động IO. Nhưng dữ liệu phải được flush vào doublewrite buffer trước khi đi xuống data files nên cũng có hạn chế nhất định. Tình huống khi mà doublewrite buffer đầy thì các page memory sẽ không thể flush được ngay xuống data files mà phải chờ.

Một số thông tin khác:

• redo log, undo log, doublewrite buffer đều được flush theo kiểu sequence. Kiểu đẩy data tuần tự này rất thích hợp với các thiết bị lưu trữ như HDD. Một số chuyên gia khuyến cáo nên đặt redo log, undo log, doublewrite buffer trên HDD.
• data files (ibd, ibdata1) lại được flush theo kiểu random. Kiểu đẩy data này lại thích hợp với các thiết bị lưu trữ như SSD. Một số chuyên gia khuyến cáo nên đặt data files trên SSD

Thực sự tôi chưa thực hiện các test case này và tôi cũng chưa có điều kiện ứng dụng các điều chỉnh vào thực tế. Các bạn có thể coi các thông tin về vị trí lưu log, data files trên HDD, SDD là một tham khảo.

• Để tăng hiệu năng của quá trình flush data, innodb có sử dụng cấu hình innodb_flush_method=O_DIRECT cho phép data được flush xuyên thẳng đến buffer của device luôn mà không cần đi qua buffer của kernel.
• Thời điểm innodb flush data từ log buffer xuống redo log được điều khiển bởi option innodb_flush_log_at_trx_commit. Mặc định giá trị này là 1. Đây là giá trị an toàn nhất. Bất cứ lúc nào có một transaction, log buffer được write xuống redo log và sau đó redo log flush liền xuống disk. Giá trị bằng 0 thì log buffer được write xuống redo log xấp xỉ sau mỗi giây và sau đó redo log liền được flush xuống disk. Khoảng thời gian mỗi giây không được đảm bảo vì CPU phải schedule để thực hiện nhiều tiến trình khác trong hệ thống chứ không hoàn toàn dành riêng cho mỗi mysqld. Giá trì bằng 2 thì log buffer được write xuống redo log khi có transaction, sau đó redo log được flush xuống disk sau mỗi giây (khoảng thời gian này không được đảm bảo cũng vì CPU scheduler).

Mysql innodb thực hiện crash recovery như thế nào ?

Sau một sự cố nghiêm trọng chẳng hạn như sụt nguồn, mysqld khi startup trở lại sẽ cần thực hiện quá trình gọi là crash recovery. Ban đầu mysqld sẽ đọc redo log để replay các transaction chưa kịp flush vào data files. Trong các transaction đó có những transaction chưa kịp commit hoặc kết thúc bởi một explicit rollback. Mysqld sẽ tiếp tụic đọc undo log để rollback các transaction đó. Cuối cùng mysqld cần phải loại bỏ các half written page khỏi data files. Nó sẽ thực hiện kiểm tra trong data files. Nếu nó thấy half written page, nó sẽ thay thế bằng full page có trong doublewrite buffer. Tất nhiên, bản thân trong doublewrite buffer cũng có thể có half written page, innodb sẽ discard các page này trong doublewrite buffer vì nó không thể tìm được nguồn thay thế.

Read More

Encode Bash Script

1. Demo Nội dung file cần encode:

[root@localhost Desktop]# cat script.sh
#!/usr/bin/env bash
echo "Day la noi dung test"

2. Tạo file encode base64

[root@localhost Desktop]# echo '#!/usr/bin/env bash' > other.sh
[root@localhost Desktop]# echo "echo '$(base64 script.sh)' | base64 -d | sh" >> other.sh
[root@localhost Desktop]# cat other.sh
#!/usr/bin/env bash
echo 'IyEvdXNyL2Jpbi9lbnYgYmFzaAplY2hvICJEYXkgbGEgbm9pIGR1bmcgdGVzdCIK' | base64 -d | sh

3. Encode sử dụng hex

[root@localhost Desktop]# cat ./obfuscate.sh
#!/bin/bash
if [[ $# -ne 1 ]] ; then
  CMD="echo 'IyEvdXNyL2Jpbi9lbnYgYmFzaAplY2hvICJEYXkgbGEgbm9pIGR1bmcgdGVzdCIK' | base64 -d | sh"
else
  CMD=$1
fi
B64=$(echo -n $CMD | base64)
MIDDLE="eval \`echo \"$B64\" | base64 -di\`"
CODE=$(echo -n $MIDDLE | hexdump -v -e '"\\\x" 1/1 "%02x"')
LOL="eval \`echo -e \"$CODE\"\`"
echo $LOL
[root@localhost Desktop]#

4. Run code  obfuscate.sh

 [root@localhost Desktop]#echo '#!/usr/bin/env bash' > script_enc.sh
 [root@localhost Desktop]# ./obfuscate.sh >> script_enc.sh

Done
Ta được file đã encode:

 [root@localhost Desktop]# cat script_enc.sh
#!/usr/bin/env bash
eval `echo -e "\x65\x76\x61\x6c\x20\x60\x65\x63\x68\x6f\x20\x22\x5a\x57\x4e\x6f\x62\x79\x41\x6e\x53\x58\x6c\x46\x64\x6d\x52\x59\x54\x6e\x6c\x4d\x4d\x6b\x70\x77\x59\x6d\x6b\x35\x62\x47\x4a\x75\x57\x57\x64\x5a\x62\x55\x5a\x36\x59\x55\x46\x77\x62\x46\x6b\x79\x61\x48\x5a\x4a\x51\x30\x70\x46\x57\x56\x68\x72\x5a\x32\x4a\x48\x52\x57\x64\x69\x62\x54\x6c\x77\x53\x55\x64\x53\x20\x4d\x57\x4a\x74\x59\x32\x64\x6b\x52\x31\x5a\x36\x5a\x45\x4e\x4a\x53\x79\x63\x67\x66\x43\x42\x69\x59\x58\x4e\x6c\x4e\x6a\x51\x67\x4c\x57\x51\x67\x66\x43\x42\x7a\x61\x41\x3d\x3d\x22\x20\x7c\x20\x62\x61\x73\x65\x36\x34\x20\x2d\x64\x69\x60"`

Read More

Zombie Process

Zombie thực chất là một phần còn sót lại của một tiến trình đã ngừng hoạt động nhưng chưa được xử lý sạch. Những chương trình sau khi thoát để lại tiến trình Zombie thì điều đó đồng nghĩa với việc chương trình đó được lập trình không tốt.

Vậy chính xác “zombie process” được tạo ra như thế nào?
Muốn hiểu chính xác quá trình này, bạn cần có một chút hiểu biết về cách hoạt động của các tiến trình trong HĐH Linux. Một khái niệm bạn gần biết nữa là tiến trình cha mẹ (parent process) là tiến trình khi thực thi tạo ra các tiến trình khác.
Trong Linux, khi một tiến trình kết thúc, HĐH sẽ không xóa nó khỏi bộ nhớ ngay lập tức. Thay vào đó, Linux vẫn giữ lại mô tả tiến trình (process discriptor) trong bộ nhớ (Mô tả tiến trình chỉ chiếm một lượng nhỏ bộ nhớ). Lúc này, trạng thái của tiến trình sẽ là EXIT_ZOMBIE và “cha mẹ” của tiến trình đó được thông báo rằng tiến trình con đã “chết” với tín hiệu tên là SIGCHLD. Tiến trình cha mẹ sau đó có nghĩa vụ thực thi chức năng wait() với nhiệm vụ đọc trạng thái và thông tin của tiến trình đã chết đó. Sau khi chức năng wait() được gọi, tiến trình Zombie lúc này sẽ được xóa hoàn toàn khỏi bộ nhớ.
Quá trình này thường diễn ra khá nhanh, vì thế bạn sẽ không thể nhìn thấy những zombie process. Tuy nhiên nếu tiến trình cha mẹ được lập trình cẩu thả và không bao giờ thực hiện chức năng wait(), tiến trình thây mà sẽ nằm lại trong bộ nhớ đến khi hệ thống được khởi động lại.
Để nhìn thấy những zombie process, bạn cần cài đặt Top command hoặc PS command.

Nguy hiểm từ “zombie process”
zombie process hầu như không sử dụng chút tài nguyên nào từ máy tính của bạn (hầu như bởi vì chúng chỉ chiếm một chút xíu dung lượng để lưu mô tả tiến trình). Tuy nhiên, mỗi tiến trình trong Linux đều được gán một mã số (PID). zombie process tuy là tiến trình chết nhưng vẫn đươc coi là một tiến trình và vẫn chiếm 1 PID. Linux có số lượng PID hữu hạn (ví dụ bản 32-bit có 32767 PID). Nếu zombie process bị ứ đọng lại bộ nhớ quá nhiều – ví dụ một phần mềm dành cho máy chủ được lập trình ẩu, toàn bộ PID có thể bị chiếm hết trong một thời gian rất ngắn và không một tiến trình nào có thể bắt đầu được nữa.
Tuy nhiên, nếu chỉ có vài zombie process sẽ không gây hại gì cho máy tính bạn.

Cách dọn dẹp zombie process.
Như đã nói ở trên, bạn không thể “giết” zombie process được vì bản chất chúng đã “chết” rồi. Cần nhớ rằng bạn không cần phải dọn dẹp zombie process trừ khi chúng tràn ngập bộ nhớ của bạn, một cài cái sẽ không gây hại.
Cách thứ nhất là gửi tín hiệu SIGCHLD đến tiến trình cha mẹ. Tín hiệu này sẽ ra lệnh cho tiến trình cha mẹ thực hiện chức năng wait() và dọn sạch những “đứa con” đó. Gửi tín hiệu với lệnh kill, thay thế pid bằng ID của tiến trình cha mẹ:
kill -s SIGCHLD pid
Tuy nhiên, nếu các tiến trình cha mẹ không được lập trình kỹ lưỡng, nó thậm chí sẽ lờ đi tín hiệu SIGCHLD và câu lệnh trên là vô ích, bạn sẽ phải tự mình “kill” tiến trình cha mẹ. Khi một tiến trình tạo ra zombie process bị giết, tiến trình với tên init sẽ thừa kế lại những zombie process và trở thành tiến trình cha mẹ mới (init là tiến trình đầu tiên khởi động khi Linux khởi động, có PID là 1), sau đó init sẽ thực hiện định kỳ chức năng wait() để dọn dẹp. Bạn có thể khởi động lại tiến trình cha mẹ sau khi tắt chúng đi.
Còn nếu tiến trình cha mẹ lại tiếp tục sinh ra zombie process, bạn sẽ cần biện pháp khác. Ví dụ thay vì gọi wait() định kỳ, bạn sẽ phải gọi Wait() theo nhu cầu. Nếu zombie process vẫn tiếp tục được tạo ra dù bạn đã thử nhiều phương pháp, lúc này bạn sẽ cần gửi báo cáo cho nhà sản xuất phần mềm.

Read More

Understanding the Load Average on Linux

Load và Load Average

Với hệ thống Unix(bao gồm cả Linux), system load đo lường công việc tính toán mà hệ thống đang thực hiện. Đo lường này được thể hiện dưới dạng số. Máy tính hoàn toàn không hoạt động thì có load average là 0. Mỗi process sử dụng hoặc đợi tài nguyên CPU load sẽ được cộng thêm 1. Nếu hệ thống có load là 5 nghĩa là có 5 process đang sử dụng hoặc đợi tài nguyên CPU.
Hệ thống Unix chỉ đếm các process đợi CPU, nhưng Linux đếm cả process đợi cả các tài nguyên khác - ví dụ như process đợi đọc hoặc ghi vào ổ đĩa.

Load của máy tính không có ý nghĩa nhiều lắm. Một máy tính có thể có load là 0, một giây sau có thể có load là 5. Chính vì thế hệ thống Unix không hiển thị thông số load hiện tại. Họ hiển thị load average - thông số trung bình của load trong một khoảng thời gian. Điều này cho phép bạn xem được hiệu năng làm việc của hệ thống đã thực hiện được bao nhiêu.

Finding the Load Average
Sử dụng lệnh 'top' hoặc 'uptime'. Với hệ thống linux hoặc BSD trên thiết bị với giao diện web - ví dụ như DD-WRT router thì có thể xem trên trang status.

Load Agerage Output
Ví dụ một load average :

load average: 1.05, 0.70, 5.09

Từ trái sang phải, các số hiển thị load trung bình trong khoảng thời gian 1 phút, 5 phút và 15 phút gần nhất. Với ví dụ trên:

load average over the last 1 minute: 1.05

load average over the last 5 minutes: 0.70

load average over the last 15 minutes: 5.09

Giả sử hệ thống trong ví dụ trên sử dụng 1 CPU, các con số trên chỉ ra rằng:

over the last 1 minute: The computer was overloaded by 5% on average. On average, .05 processes were waiting for the CPU. (1.05)

over the last 5 minutes: The CPU idled for 30% of the time. (0.70)

over the last 15 minutes: The computer was overloaded by 409% on average. On average, 4.09 processes were waiting for the CPU. (5.09)

==> Trong vòng 1 phút gần đây nhất máy tính bị quá tải 5% , trung bình .05 process phải đợi CPU.
Trong vòng 5 phút gần nhất: CPU idle 30%.
Trong vòng 15 phút gần nhất: Máy tính quá tải 409%. Trung bình 4.09 process phải đợi CPU (5.09)
Trong thực thế , hệ thống thường có nhiều CPU hoặc CPU có nhiều core.  Nếu load average là 2 với hệ thống có 1 CPU có nghĩa là hệ thống hoạt động quá tải 100% - trong khi 1 process sử dụng CPU thì một process phải đợi. Với hệ thống có 2 CPU, 2 process sẽ dùng 2 CPU, với hệ thống có 4 CPU, nó sẽ sử dụng một nửa, 2 process sử dụng 2 CPU trong khi 2CPU sẽ ở trạng thái idle.
Để hiểu được thông số load average, bạn cần phải biết được máy tính có bao nhiêu CPU. Load average bằng 6.03 với hệ thống 1CPU sẽ là quá tải , nhưng với hệ thống 8CPUs sẽ là bình thường
Để biết máy tính có bao nhiêu CPU:ta sử dụng 'lscpu' hoặc 'nproc'


Các yếu tố ảnh hưởng đến Load Average:

Loadavg là gì và được tính toán như nào?

Trước tiên bắt đầu với systemload hay còn gọi là load.
Systemload thể hiện số công việc hiện tại hệ thống đang thực thi.
Một server hoàn toàn nhàn rỗi có load là 0
Mỗi tiến trình đang chạy hoặc chờ đợi cpu xử lý sẽ add giá trị 1 vào load
Ví dụ với load = 5 => Có 5 process đang chạy hoặc chờ xử lý (Thread running, waiting)
Nhưng chúng ta thường nghe đến khái niệm loadavg

Tại sao không phải là load mà là loadavg???

Ví dụ thế này để các bạn dễ hình dung:

• Tại 1 phần trăm giây đầu tiên Load = 0 vì server đang rảnh rỗi
• Tại phần trăm giây tiếp theo Load = 5 vì thời điểm có 5 proces cần xử lý.
• Tại phần trăm giây sau đó Load = 99 rất lớn vì thời điểm có rất nhiều process chạy qua hệ thống.

Các con số Load cho mỗi một thời điểm này không có ý nghĩa nhiều trong việc đánh giá tải của hệ thống.
Loadavg thể hiện tải trung bình của hệ thống qua mỗi đoạn thời gian: cho thấy trung bình có bao nhiều process mà server phải thực hiện.
Hay nói cách khác: giá trị Loadavg cho ta thấy được trung bình khối lượng công việc hệ thống phải xử lý trong mỗi khoảng thời gian: 1 phút, 5 phút và 15 phút.

cat /proc/loadavg  
3.00 5.00 4.00  

Hiểu giá trị console này như sau:
Trong 1 phút gần đây trung bình có 3 process cần được xử lý (3 thread running, waiting)
Tương tự như vậy có trung bình 5 process xử lý trong vòng 5 phút và 4 process xử lý trong vòng 15 phút.

Loadavg ở ngưỡng ra sao thì hợp lý?

Loadavg có một ngưỡng chung?
Các server đều có một ngưỡng loadavg cố định?
Câu trả lời là Không
Điều này còn phụ thuộc vào server có bao nhiêu CPU. Có thể xem số CPU của sever bằng lệnh sau:

cat /sys/devices/system/cpu/online  
0-3  

Như vậy server hiện tại (bao gồm cả hyper-v threading) có 4 CPUs 

ới 4 CPUs chúng ta có 4 cây cầu và có thể xử lý với mức Loadavg <= 4.00 là mức lý tưởng.

Để thấy rõ hơn điều này ta thực hiện 1 vài thử nghiệm với server 4 CPUs. Chúng ta cùng xem nó xử lý process như nào khi loadavg lần lượt bằng: 1.00, 4.00 và 8.00

• Case 1: Server 4 CPUs với loadavg = 1.00

Process vừa tạo được hoàn toàn sử dụng CPU với tốc độ xử lý bình thường, performance đạt 100%. Loadavg lúc này tăng lên 1.00.

• Case 2: Server 4 CPUs với loadavg = 4.00

4 process chạy đồng thời đang phân chia sử dụng 4 CPUs mà server đang có. Tốc độ xử lý vẫn đạt 100%. Loadavg lúc này đã tăng lên 4.00

• Case 3: Server 4 CPUs với loadavg = 8.00

Loadavg thời điểm này lên tới 8.00 gấp đôi số CPU hiện có. Mỗi process chỉ còn sử dụng được 50% CPU => Tốc độ xử lý chậm đi tương ứng.
Qua hàng loạt case test, ta thấy loadavg nên duy trì nhỏ hơn hoặc bằng số CPU. Process càng vượt quá CPU hiện có bao nhiêu, tốc độ xử lý càng chậm đi tương ứng.

Những yếu tố nào ảnh hưởng đến loadavg?

Vậy điều gì làm tải của hệ thống tăng cao.
Như 1 vài case test ở mục 2 cho thấy mối quan hệ giữa CPU utilization và loadavg

Nhưng liệu loadavg có chỉ phụ thuộc vào CPU utilization?

Tải của hệ thống có thể được tính toán (count) dựa trên các tiến trình đang được xử lý (running on CPU) và các tiến trình runable (waiting for CPU)
Ngoài ra tải còn bao gồm các tiến trình uninterruptible sleep states (waiting disk I/O hoặc network). Những tiến trình này cũng góp phần làm tăng cao tải hệ thống mặc dù nó không thực sự sử dụng CPU.

--> Có 3 yếu tố góp phần làm tăng tải hệ thống:

• Cpu Utilazion
• Disk I/O
• Network Traffic

Việc phân tích sự ảnh hưởng của các yếu tố này sẽ khá dài và phức tạp, chúng ta sẽ cùng nhau tìm hiểu sâu thêm trong những phần sau. Giờ tôi sẽ hướng dẫn bạn cách phân tích và xử lý khi server gặp tải cao.

Phương án phân tích và xử lý khi server tải cao như nào?

Chúng ta đã thống nhất với nhau ba yếu tố:

• Cpu Utilazion
• Disk I/O
• Network Traffic

đều có thể gây ảnh hưởng đến tải của hệ thống.

Cần xử lý những gì khi loadavg lên quá cao?

Ta cần phải phân tích yếu tố nào gây tải cao hệ thống.
Trước hết cần phải theo dõi CPU utilization.

• Nếu lượng CPU utilization lớn hơn 100% và Loadavg vượt quá số CPU đang có.
  --> Có thể kết luận loadavg cao bởi lượng lớn các process đang running hoặc waiting cpu xử lý.
  Sử dụng top -i để theo dõi các process running phân tích các process và đưa phương án.
• Nếu lượng cpu sử dụng vẫn bình thường (tức không quá cao) nhưng loadavg vẫn cao hơn số cpu đang có.
  --> Vậy có thể kết luận có thể disk I/O hoặc network traffic hoặc cả hai là yếu tố chính gây ra tải cao cho hệ thống.
  Sử dụng 1 số tool linux cung cấp như iotop, atop, vmstat để có thể phân tích chính xác yếu tố nào và đưa ra phương án xử lý.

1. CPU utilization và load average

Trong trường hợp CPU của bạn được dùng cho những tính toán rất nhẹ nhàng có thể xong tức thì nhưng số lượng process cần CPU lại rất cao, các process cần xử lý tại một thời điểm vượt mức CPU core server hiện có. Điều này nói lên rằng CPU của bạn đang bị quá tải process. Có nhiều lý do dẫn đến trường hợp này và mỗi trường hợp có nhiều cách giải quyết khác nhau.

Một ví dụ hay thấy trường hợp này là máy chủ web. Việc render các trang web là không hề nặng, tuy vậy với các máy chủ web chịu trafic lớn (số lượng connection lớn), các process phục vụ request sẽ phải xếp hàng dẫn đến tình trạng trang web bị phục vụ với thời gian kéo dài hơn.

Tuy nhiên trong quá trình vận hành hệ thống, không ít lần tải hệ thống lên rất cao mặc dù các tiến trình không thực sự sử dụng nhiều CPU. Vậy là lúc chúng ta xem xét yếu tố tiếp theo gây ra tải cao hệ thống.

2. Disk I/O và load average

Trong phần này ta sẽ cùng nhau làm rõ một số vấn đề :

• I/O wait ảnh hưởng loadavg như nào?
• Khi nào I/O wait xảy ra?
• Mối quan hệ I/O wait và CPU?
• Khi nào thì high I/O wait?

I/O wait là giá trị thời gian mà một CPU (hoặc tất cả các CPU) idle bởi vì các tiến trình Runnable đang chờ đợi một hoạt động I/O disk được hoàn thành trong khoảng thời gian nhất định.

I/O wait = ((CPU waiting on disk time)/ periods) * 100%  

Một trường hợp hay gặp trong database server:
Máy chủ DB dành thời gian chủ yếu đợi thao tác vào ra (I/O) như khi truy vấn cơ sở dữ liệu. Số lượng query lớn, số lượng truy vấn cần sắp xếp lớn nhưng dữ liệu cần sắp xếp lại rất bé, thời gian đợi dữ liệu từ disk lại cao. Vì vậy phần lớn CPU sẽ idle, nhưng loadavg vẫn cao.

Rối tung lên phải không nào? Để tôi ví dụ cụ thể cho các bạn dễ hình dung:

Trong một truy vấn tốn thời gian là 1s để lấy 10.000 rows và thực hiện 1 số thao tác với các row đó:

Process đi vào CPU để xử lý. CPU sẽ truy cập vào disk để lấy thông tin các rows. Tại thời điểm này CPU sẽ idle và chờ disk phản hồi, đây chính là thời điểm waiting on disk.

Như ảnh trên waiting on disk sẽ tốn 700ms trong 1s. I/O wait tại thời điểm này đo được là 70%.

Đến đây chắc hản các bạn cũng giống tôi thắc mắc ngưỡng của I/O wait. Vậy như nào là high I/O wait?

High I/O wait phụ thuộc vào số lượng CPU server đang có. 50% iowait của server 2 cpu chỉ tươg đương với 12.5% iowait trên server có 8 cpu. Tỉ lệ nghịch với số lượng cpu của server.
Tổng quát lại : nếu phần trăm I/O wait lớn (1/số lượng cpu) * 100% thì đây là lúc bạn cần phải xem xét lại disk I/O hệ thống của mình.

3. Network traffic và load average

Đã khi nào bạn gặp trường hợp tải hệ thống vẫn rất cao mặc dù I/O wait và CPU utilization tương đối thấp chưa? Nếu rồi thì có lẽ (có lẽ thôi nhé) hệ thống của bạn đang gặp phải trường hợp thứ 3 process waiting for Network I/O

Tôi sẽ thử vài ví dụ để chứng minh network cũng gây ảnh hưởng đến loadavg:

Thực hiện traffic nhận 50 nghìn package với khoảng 1,5Gb data qua lo interface. Ta cùng theo dõi CPU utilization và run-queue utilization.

CPU sử dụng 21% ở user mode và 79% ở kernel mode. Bởi vì tại thời điểm này linux kernel đang phaỉ làm việc rất nhiều để xử lý lượng lớn traffic.

Bảng thống kê loadavg hiện đang show ta thấy trung bình có 13 process trong run-queue và loadavg-1 đang sắp đạt mốc 13. Đây chính là dấu hiệu cho thấy loavg bị ảnh hưởng bởi quá trình thực hiện network I/O. Các process network đã sử dụng 1 lượng lớn thời gian của CPU và buộc loadavg tăng lên. Ta sẽ xác nhận điều này bằng các giá trị show trong top util

Như đã thấy các process network stress đã không thực sự sử dụng quá nhiều CPU. Việc tiêu thụ cpu chủ yếu là si = 50% cho thấy cpu utilization chủ yếu cho việc xử lý software interrupts.

Chúng ta đã cùng phân tích một số các yếu tố ảnh hưởng loadavg, tuy nhiên điều này có thể vẫn còn chưa đủ. Bản chất Loadavg được tính toán dựa trên số lượng process chờ đợi trong run-queue. Do đó ngoài các process đang được xử lý, tải hệ thống vẫn tiếp tục tăng khi bạn có một hoặc một vài process trạng thái UNINTERRUPTIBLE_SLEEP đang chờ đợi thành phần khác như hardware hoặc software để tiếp tục xử lý.

Linux includes processes in uninterruptible sleep in its load calculation. Such processes show with State 'D' in the usual process inspection tools. This state is usually used by device drivers waiting for disk or network IO. That "usual explanation" is true for Linux, but not most other unixes

Chúng ta đã cùng tìm hiều Loadavg là gì? Các yếu tố nào ảnh hưởng tới Loadavg và ảnh hưởng như thế nào? Hy vọng loạt bài viết về Loadavg của tôi sẽ giúp bạn dễ dàng hơn trong công việc quản trị hệ thống.

Read More