Loadavg

Phần I : Tổng quan Loadavg

Ting ..ting.. không phải lương về đâu các bạn. Tiếng tin nhắn cảnh báo đã không còn xa lạ gì với một sysadmin. Login vào server để kiểm tra nguyên nhân. Quái! Sao lần này login lại lâu đến như vậy. Mọi command cũng chậm hơn rất nhiều so với bình thường. Bình tĩnh tìm hiểu kỹ hơn. Tôi giật mình: server của tôi đang có loadavg cao ngất ngưởng.

Điều này đồng nghĩa với việc server trở nên ì ạch. Việc xử lý process chậm đi đáng kể. Tại sao lại có sự bất thường này? Gãi râu tự hỏi. Vậy:

• Loadavg là gì và được tính toán như thế nào?
• Loadavg ở ngưỡng ra sao thì hợp lý?
• Những yếu tố nào ảnh hưởng đến loadavg?
• Phương án phân tích và xử lý khi server tải cao thế nào?

Tôi sẽ trả lời 4 câu hỏi kể trên trong phần I của bài viết về Loadavg này.

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 

Giả sử với mỗi CPU là 1 cây cầu. Process qua mỗi CPU thể hiện như sau:

Vớ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ý.

Phần II : Các yếu tố ảnh hưởng tới Loadavg

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

Link tham khảo

• www.teamquest.com/import/pdfs/whitepaper/ldavg1.pdf
• en.wikipedia.org/wiki/Load_(computing)
• blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
• www.softprayog.in/tutorials/load-average

How to Install Nginx on Ubuntu 14.04 LTS

Nginx is a free, open source, high-performance web server. Need HTTP and HTTPS but don’t want to run Apache? Then nginx may be your next go-to, at least for Linux.

Pre-Flight Check

• These instructions are intended specifically for installing nginx on Ubuntu 14.04 LTS.
• I’ll be working from a Liquid Web Self Managed Ubuntu 14.04 server, and I’ll be logged in as root.

Step #1: Install nginx

First, you’ll follow a simple best practice: ensuring the list of available packages is up to date before installing anything new.

sudo apt-get -y update

Then it’s a matter of just running one command for installation via apt-get:

sudo apt-get -y install nginx

Step #2: Find Your IP Address; Visit Your Site

Once the installation is complete the nginx service should automatically start and begin listening on port 80. 

Find your server’s IP address run the following command:

ip addr show eth0 | grep inet

In this case we are assuming that eth0 is configured with the primary public IP of your server. Your result may look similar to:

inet xxx.xxx.xxx.xxx/22 brd yyy.yyy.yyy.yyy scope global eth0

Where xxx.xxx.xxx.xxx is the IP address of your server.

Verify that nginx is running by visiting http://xxx.xxx.xxx.xxx. For example: http://1.2.3.4.

You should receive a page similar to:

Step #3: Manage the nginx Service

Start the nginx Service:

service nginx start

Stop the nginx Service:

service nginx stop

Restart the nginx Service:

service nginx restart

Check the Status of the nginx Service:

service nginx status

Assure that nginx starts at boot:

update-rc.d nginx defaults

When running the last command you may receive:

System start/stop links for /etc/init.d/nginx already exist.

The above error simply means that nginx is already configured to start when the server boots.

How to Install MongoDB on Ubuntu 14.04 LTS

MongoDB is a NoSQL database intended for storing large amounts of data in document-oriented storage with dynamic schemas. NoSQL refers to a database with a data model other than the tabular format used in relational databases such as MySQL, PostgreSQL, and Microsoft SQL. MongoDB features include: full index support, replication, high availability, and auto-sharding.

Pre-Flight Check

• These instructions are intended for installing MongoDB on a single Ubuntu 14.04 LTS node.
• I’ll be working from a Liquid Web Core Managed Ubuntu 14.04 LTS server, and I’ll be logged in as a non-root user, but with sudo access. For information on giving a user sudo access visit our page on How to Add a User and Grant Root Privileges on Ubuntu 14.04

Step #1: Setup a the Package Database

First we’ll import the MongoDB public key used by the package management system:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927

Create a list file for MongoDB.

Create the /etc/apt/sources.list.d/mongodb-org-3.2.list list file using the command appropriate for your version of Ubuntu:

Ubuntu 12.04

echo "deb http://repo.mongodb.org/apt/ubuntu precise/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

Ubuntu 14.04

echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

Now reload the package database:

sudo apt-get update

Step #2: Install Latest Stable Version MongoDB

At this point, installing MongoDB is as simple as running just one command:

sudo apt-get install -y mongodb-org

If you’d like MongoDB to auto-update with apt-get than you’re done with the installation. But, it’s possible to ‘pin’ the version of MongoDB you just installed to prevent apt-get from auto-updating.

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongodb-org-shell hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Step #3: Get MongoDB Running

Start-Up MongoDB:

sudo service mongod start

Check MongoDB Service Status:

sudo service mongod status

Summary List of Status Statistics (Continuous):

mongostat

Summary List of Status Statistics (5 Rows, Summarized Every 2 Seconds):

mongostat --rowcount 5 2

Enter the MongoDB Command Line:

mongo

By default, running this command will look for a MongoDB server listening on port 27017 on the localhost interface. 

If you’d like to connect to a MongoDB server running on a different port, then use the –port option. For example, if you wanted to connect to a local MongoDB server listening on port 22222, then you’d issue the following command:

mongo --port 22222

Shutdown MongoDB:

sudo service mongod stop

Restart MongoDB:

sudo service mongod restart

Thanks,

How to Remove (Delete) a User on Ubuntu 14.04 LTS

Pre-Flight Check

• These instructions are intended specifically for removing a user on Ubuntu 14.04 LTS.

• I’ll be working from a Liquid Web Core Managed Ubuntu 14.04 LTS server, and I’ll be logged in as root.

Step 1: Delete the User

It’s just one simple command to add a user. In this case, we’re adding a user called madman:

userdel madman

If you want to remove all of the files for the user, then use -r:

userdel -r madman

Step 2: Remove Root Privileges to the User

visudo

Find the following code:

## Allow root to run any commands anywhere
root ALL=(ALL:ALL) ALL
madman ALL=(ALL:ALL) ALL

In this case, we’re removing root privileges from the user madman. Remove the following:

madman ALL=(ALL:ALL) ALL

Then exit and save the file with the key commands Ctrl-x, Y, enter.

How to Add a User and Grant Root Privileges on Ubuntu 14.04

Pre-Flight Check

• These instructions are intended specifically for adding a user on Ubuntu 14.04 LTS.

• I’ll be working from a Liquid Web Core Managed Ubuntu 14.04 LTS server, and I’ll be logged in as root.

Step 1: Add the User

It’s just one simple command to add a user. In this case, we’re adding a user called madman:

adduser madman

First you will be prompted to enter the user’s password (twice); do this step. Next you’ll be prompted to enter in the user’s information. This step is not required, and pressing enter fills the field with the default information:

Adding user 'madman' ...
Adding new group 'madman' (1001) ...
Adding new user 'madman' (1001) with group 'madman' ...
Creating home directory '/home/madman' ...
Copying files from '/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for madman
Enter the new value, or press ENTER for the default
Full Name []: User
Room Number []:
Work Phone []:
Home Phone []:
Other []:

When prompted with the following question, enter Y then hit enter to continue.

Is the information correct? [Y/n] Y

Step 2: Grant Root Privileges to the Use

visudo

Find the following code:

# User privilege specification
root ALL=(ALL:ALL) ALL

In this case, we’re granting root privileges to the user madman. Add the following below that code:

madman ALL=(ALL:ALL) ALL

Then exit and save the file with the key commands Ctrl-x, Y, enter.

If you’ve followed the instruction above correctly, then you should now have a user setup by the name of madman which can use sudo to run commands as root!

Setting Up MUNIN on Ubuntu Server 14.04 with NGINX

This post explains how to configure munin on a single Ubuntu 14.04 server that uses nginx.

sudo apt-get update
sudo apt-get install nginx

Monitoring is supposed to save time by debugging and predicting / avoiding catastrophes. However, setting up munin on Ubuntu was a time-consuming trial-and-error process for me. The official instructions and various blog posts that cover this topic skip important steps, such as having monit's FastCGI processes start automatically at boot time. I have documented the setup that worked for me, hoping that others can reuse my work.

Ubuntu packages

Run the following command to install the packages needed for munin.

sudo apt-get install munin munin-node spawn-fcgi libcgi-fast-perl

The following sections configure the munin packages.

Munin configuration

Write the munin configuration below to /etc/munin/munin-conf.d/90-fcgi

graph_strategy cgi
html_strategy cgi
cgiurl_graph /munin/munin-cgi-graph

NGINX configuration

Write the nginx configuration below to /etc/nginx/sites-available/munin.conf

server {
  #listen 443 ssl;
  listen 7000;
  charset utf-8;
  #server_name munin.your-domain.com;
  location ~ ^/munin/munin-cgi-graph/ {
    fastcgi_split_path_info ^(/munin/munin-cgi-graph)(.*);
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass unix:/var/run/munin/fastcgi-graph.sock;
    include fastcgi_params;
  }
  location /munin/static/ {
    alias /etc/munin/static/;
    expires modified +1w;
  }
  location /munin/ {
    fastcgi_split_path_info ^(/munin)(.*);
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass unix:/var/run/munin/fastcgi-html.sock;
    include fastcgi_params;
  }
  location / {
    rewrite ^/$ munin/ redirect; break;
  }
}

This configuration assumes that you have a DNS entry set aside for reaching the monit pages. I have separate DNS entries for all my applications, and they're all CNAMEs for the (same) machine that they're running on.

Once you're done tweaking the script, reload nginx.

sudo /etc/init.d/nginx reload

FastCGI daemons

Write the script below to /etc/init.d/munin-fcgi

#!/bin/bash

### BEGIN INIT INFO
# Provides:          munin-fcgi
# Required-Start:    $remote_fs $syslog $network
# Required-Stop:     $remote_fs $syslog $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start munin FCGI processes at boot time
# Description:       Start the FCGI processes behind http://munin.*/
### END INIT INFO

graph_pidfile="/var/run/munin/fcgi_graph.pid"
# Ubuntu 12.10: /usr/lib/cgi-bin/munin-cgi-graph
graph_cgi="/usr/lib/munin/cgi/munin-cgi-graph"
html_pidfile="/var/run/munin/fcgi_html.pid"
# Ubuntu 12.10: /usr/lib/cgi-bin/munin-cgi-html
html_cgi="/usr/lib/munin/cgi/munin-cgi-html"

retval=0

. /lib/lsb/init-functions

start() {
  echo -n "Starting munin graph FastCGI: "
  start_daemon -p ${graph_pidfile} /usr/bin/spawn-fcgi -u munin -g munin \
      -s /var/run/munin/fastcgi-graph.sock -U www-data ${graph_cgi}
  echo
  echo -n "Starting munin html FastCGI: "
  start_daemon -p ${html_pidfile} /usr/bin/spawn-fcgi -u munin -g munin \
      -s /var/run/munin/fastcgi-html.sock -U www-data ${html_cgi}
  echo
  retval=$?
}
stop() {
  echo -n "Stopping munin graph FastCGI: "
  killproc -p ${graph_pidfile} ${graph_cgi} -QUIT
  echo
  echo -n "Stopping munin html FastCGI: "
  killproc -p ${html_pidfile} ${html_cgi} -QUIT
  echo
  retval=$?
}
case "$1" in
  start)
    start
  ;;
  stop)
    stop
  ;;
  restart)
    stop
    start
  ;;
  *)
    echo "Usage: munin-fcgi {start|stop|restart}"
    exit 1
  ;;
esac
exit $retval

Make the script executable, and fix some permissions while you're at it.

sudo chmod +x /etc/init.d/munin-fcgi
sudo chown munin /var/log/munin/munin-cgi-*

Now that the init.d script is in place, start it and have it run on every boot.

sudo /etc/init.d/munin-fcgi start
sudo update-rc.d munin-fcgi defaults

Debugging

You should be able to point your browser to http://[ip_address]:7000 and see many graphs. If that doesn't work out, the logs below should give you a clue as to what went wrong.

/var/log/nginx/error.log
/var/log/munin/munin-cgi-graph.log
/var/log/munin/munin-cgi-html.log

Conclusion

I hope that you have found my post useful, and I hope that it helped you get your munin monitoring setup up and running in a manner of minutes.