Giới thiệu các phương pháp và chiến lược đối ứng tải trong Web Application Server. - WEB Server Scaleout - Chiến lược Caching - Tách DB (Horizontal Sharding / Vertical Sharding) - Linux Kernel Parameters

1. 高負荷に耐えうる WebApplication Server
の作り方
Phương Pháp Và Chiến Lược Đối Ứng Tải
Trong Web App Server
GMOインターネット株式会社GMO Internet Inc.
次世代システム研究室
Phòng nghiên cứu và phát triển công nghệ mới
石山 雄太 Mr Ishiyama Yuta
1/71

2. Xin chào！
Tôi tên là Ishiyama Yuta.
GMO Internet inc.
次世代システム研究室
(Innovation and Technology System Office)
アシスタントマネージャー(Asistant Manager)
シニアアーキテクト(Senior Architect)
Engineer歴 20年 Kỹ sư với 20 năm kinh nghiệm
好き DB / Elixir-lang Yêu thích DB/ Elixir-lang
自己紹介
2

3. Goal
Câu hỏi khi thiết kế kiến trúc Web App để đáp ứng tải
lớn:
 Giải quyết ở điểm nào trên hệ thống?
 Giải quyết như thế nào?
Không nặng về code mà tập trung vào thiết kế kiến trúc hệ
thống server.
Chỉ cần các bạn nhớ được ví dụ hôm nay là buổi nói chuyện
đạt mục tiêu.
3

4. Section 0
対象とするWebApplicationの説明（前提）
Giới thiệu dự án Web Application đã thực hiện (tiền đề)
Section 1
どういった案があるか説明（抽象的）
Phương án giải quyết (Trừu tượng)
Section 2
設定の説明（具体的）
Chi tiết cài đặt (chi tiết)
71 pages
Agenda
4

5. Section 0
対象とするWebApplicationの説明（前提）
Giới thiệu dự án Web Application đã thực hiện (tiền đề)
5

6. PJ code「C2」:
Là hệ thống của 1 dự án game lớn dành cho smartphone
・[OS] CentOS7
・[WEB server] NGINX
・[API server] NGINX + PHP-FPM
・[CACHE] Memcached, Redis
・[DB] MySQL(MariaDB)
Yêu cầu đáp ứng 1 lượng lớn request theo JSON API hoặc
HTML, ảnh, video từ game clients
対象とするWebApplication
6

7. 全体構成図 Sơ đồ cấu hình tổng thể
7
LB
API
CACHE
memcached
DB
WEB・・・
master
・・
CACHE
Redis
slave
s/m
slave backup
s/m
slave backup
s/m
slave backup
s/m
slave backup
UserDB01 UserDB02 LogDB02LogDB01
MasterDB01

8. Sơ đồ cấu hình tổng thể – Những điểm giải quyết
8
LB
API
CACHE
memcached
DB
WEB・・・
master
・・
CACHE
Redis
slave
s/m
slave backup
s/m
slave backup
s/m
slave backup
s/m
slave backup
UserDB01 UserDB02 LogDB02LogDB01
MasterDB01
Thiết lập điều hướng
Scaleout
Replication
Tách dọc
Tách ngang
Giảm access DB
bằng Cache
Scaleout
Replication
Ranking

9. Section 1
どういった案があるか説明（抽象的）
Phương án giải quyết?
9

10. ◆ Scaleup (Nâng cao tính năng server)
Dùng server cấu hình cao để nâng cao tốc độ xử lý
◆ Scaleout (Tăng số lượng server)
Tăng số lượng server để tăng khả năng xử lý song song
◆ Ngoài ra
Tối ưu hoá code
Tối ưu hoá config của OS / Middleware
基本 ~~ Cơ bản
10

11. WEB SERVER
Scaleup
Scaleout
キャッシュ付きreverse proxy (reverse proxy với cache)
CDN
11

12.  Dùng server cấu hình cao
 Khi scaleup server để đáp ứng nhanh các request dạng
HTML, ảnh, video cần chú trọng
CPU clock/Số core
 Memory đủ không cần dùng tới swap là được.
 Khi số lượng CPU core nhiều thì có thể đáp ứng đồng thời
nhiều request
WEB Server~scaleup~
12

13.  Chuẩn bị nhiều server để phân tán tải
 Dùng LoadBalancer để phân bổ kết nối tới WEB SERVER
 Khi số lượng server tăng, số lượng CPU/Memory/Ephemeral
Port,… tăng nên số lượng request có thể đáp ứng cùng lúc
cũng tăng
WEB SERVER ~scaleout~
13

14.  Trả về Contents đã được cache tại Reverse proxy (của Nginx)
 Trả lại content response đã được cached sẵn để rút ngắn thời
gian đáp ứng
 Response trả về bằng cache thường nhanh hơn khi phải xử lý
chi tiết
※Project C2 sử dụng CDN nên không tiến hành cache tại Nginx
WEB SERVER~Contents Cached Reverse Proxy~
14

15. C2 sử dụng dịch vụ CDN(Contents Delivery Network) có trả
phí của bên thứ 3
・CDN: dịch vụ cache nội dung tĩnh
・CDN có server bố trí khắp thế giới, request sẽ đến server
gần client nhất
・Có thể chống tấn công DDoS
・Akamai、AWS CloudFront: nổi tiếng
C2 nhờ dịch vụ CDN nên đạt được hiệu quả khá cao, giảm
tải khá tốt
WEB SERVER~CDN~
15

16. API SERVER
scaleup
scaleout
16

17.  Sử dụng server tính năng cao
 Cơ bản giống WEB SERVER, nhưng đề cao khả năng xử lý
 Vì API server chạy code của ứng dụng (API)
 Nên khi chọn server cần chú trọng đến CPU và Memory
 Khi WebApplication nhận lượng request lớn, chỉ Scaleup thôi không đủ
API ~Scaleup~
17
API
server
API
1
API 1
cpu/mem
up!

18. Chuẩn bị nhiều server để phân tán tải
大量のrequestを受けつつprogramからCacheサーバーやDBへアクセスす
るので、port枯渇が起きやすいので APIサーバーのScaleoutは重要です
C2ではAPIサーバーを27台使っています
Code chạy trên API server sẽ kết nối đến Cache server và DB server,
dễ gây cạn kiệt cổng trên API server -> Dùng Scaleout cho API server
để giải quyết
Dự án C2 đang sử dụng 27 API server.
API ~Scaleout~
18
API
servers
API
1
API
2
API
3
API
...
API
27

19. ◆Cạn kiệt Ephemeral port (cổng tạm)
Linux có 65535 cổng, trong đó 28232 port (32768 ~ 61000) có thể
sử dụng tự do để truyền thông tin
Khi tất cả Ephemeral port đang bị sử dụng thì không thể thực hiện
việc truyền tín hiệu mới
Giải pháp: Chỉnh kernel parameter để tăng số lượng Ephemeral
port
API ~Scaleout/気をつける事~ Cần lưu ý
19

20. Không đảm bảo được request từ user/session giống nhau đi
vào API server giống nhau
=>Cần thiết kế để dù có đi vào server nào cũng xử lý được
Ngoài ra
Dùng Sticky Session thì LoadBalancer có thể điều hướng vào đúng server theo cookie.
Tuy nhiên, trên cloud thời gian Cookie Expire của Sticky Session thường ngắn, nên cần
thiết kế để dù có bị phân vào API server nào thì request cũng được xử lý bình thường
API ~Scaleout/気をつける事~ Điểm lưu ý
20

21.  Số lượng của API server vượt số lượng kết nối đồng thời
của DB
 Khi API server nhận nhiều request có thể phát sinh đợi kết nối tới DB khi vượt quá
số lượng kết nối đồng thời của DB
 Dù có nhiều API server nhưng nếu vượt quá giới hạn xử lý của DB server thì vẫn
vô ích vì không xử lý được
=>Việc nâng throughput của DB là quan trọng
=>Query chậm dễ gây nghẽn trên DB
 Việc tối ưu hóa Query cũng quan trọng
API ~scaleout/気をつける事~ Cần lưu ý
21

22. Cache server
22

23. Cache kết quả Query
Giúp giảm truy cập đến DB, nâng cao tốc độ xử lý bằng việc lấy
thông tin cache từ bộ nhớ
Phương pháp cache
・memcached
・redis
・file cache
・etc
Cache ~~
23

24. Dễ dùng
 Thông tin được cache trong memory nên thao tác đọc sẽ rất nhanh
 Không thể lưu thông tin lâu dài, bị mất data nếu memory reset
 Dịch vụ vẫn chạy ổn ngay cả khi server lỗi vì thông tin lấy ra từ cache
 Thực hiện scaleout trên Memcached khá đơn giản
 Memcached library trên client sẽ tự động kết nối đến server tương ứng
Cache ~memcached~
24

25.  Thiếu memory
memcached lưu data trên memory nên không thể lưu nếu kích
thước data vượt quá memory
 Cạn kiệt Ephemeral port
Khi lượng truy cập đến Memcached lớn dễ xảy ra cạn kiệt port
Chuẩn bị nhiều Memcached server
C2 phát sinh lỗi kết nối khi dùng 3 server nên đã tăng lên 9 server
Cache ~memcached/気をつける事~ Cần lưu ý
25

26. Tính năng cao
 Thông tin cache trên Memory nên xử lý đọc khá nhanh
 Có thể lưu thông tin trên đĩa cứng
 Khá mạnh trong việc tính Ranking (SortedSet)
 Có thể tạo cụm server master/slave và cluster
 Có thể pub/sub
 Là mô hình đơn luồng nên không cần quan tâm đến xung đột
=> Dùng cho chức năng ranking trên C2
Cache ~Redis~
26

27. Không thể cache quá memory của server
Có thể lưu data lâu dài trên Storage nhưng vì không
thể cache quá memory nên cần quản lý Memory
Cache ~Redis/気をつける事~ Cần lưu ý
27

28. DB SERVER
28

29.  Phân chia DB server（scaleout）
・Replication
Tăng số lượng DB chuyên read data và phân chia tải
・Vertical Sharding
Phân chia DB theo chức năng
・Horizontal Sharding
Phân chia DB theo data
 Phân chia khu vực lưu data
・table partitioning
 Setting
Tối ưu hóa Thiết lập DB
Tối ưu hóa Thiết lập OS
DB ~Phương pháp đối ứng chịu tải~
29

30. MasterDB đảm nhận ghi và SlaveDB đảm nhận đọc dữ liệu,
thực hiện chia tải cho ghi và đọc dữ liệu
Việc ghi đến MasterDB và sao chép vào SlaveDB gần như
realtime (Không phải hoàn toàn đồng thời)
MySQL(MariaDB), PostgreSQL có hỗ trợ Replication
DB ~Replication~
30

31.  Ví dụ Replication
1 masterDB và 1 slaveDB
Cấu hình đơn giản với số lượng server ít nhất
DB ~Replication~
master
slave
31
Replication向き
Dùng cho
Replication

32.  Ví dụ Replication
Kiến trúc Replication 3 layer
masterDB > slave & masterDB > slave
DB ~Replication~
master
slaveslave/
master
slave backup
32
Dùng cho
Replication
SlaveDB có thể kiêm
chức năng của
MasterDB

33. Phân loại DB theo chức năng (Chia DB theo chiều dọc)
Lưu thông tin user vào A-DB, lưu thông tin log vào B-DB,…
Cần code chi tiết
Nếu muốn tham chiếu thông tin user thì viết program code để kết nối đến A-
DB
Vì phân tách theo chức năng nên đơn giản
Nhược điểm: Không thể phân chia trong trường hợp có nhiều truy cập đến 1
chức năng.
DB ~Vertical sharding~
33

34. Chia kết nối đến DB bằng program code
・Những table Liên quan đến User thì kết
nối đến UserDB
・Những table liên quan đến log thì kết nối
đến LogDB
 Ví dụ Vertical sharding - tách theo chiều dọc
Phân chia DB theo chức năng
・DB liên quan đến User
・DB liên quan đến Log
DB ~Vertical sharding~
slave/
master
slave backup
34
DB related
User slave/
master
slave backup
DB related
Log
API PHP-FPM

35. Phân chia DB theo data để sử dụng (Chia theo chiều ngang)
Phân chia DB Server mà user đăng ký vào dựa theo số dư userID (mod) hay
ngày tháng vv.
Tính toán bằng chương trình rồi sử dụng kết nối tới DB tương ứng
Việc Code và vận hành sẽ rất khó khăn
Nhất là đối với những data được lưu trên DB dựa trên rule nào đó
Ưu điểm: Có thể chia DB một cách hợp lý với số lượng tuỳ ý.
DB ~Horizontal sharding~
35

36.  Ví dụ chia theo chiều ngang
Nguyên tắc: Chia theo tính chẵn – lẽ của user_id
DB ~Horizontal sharding~
slave/
master
slave backup
36
user_id even
slave/
master
slave backup
user_id odd
API PHP-FPM
Kết nối đến đích(DB) phù
hợp bằng program

37.  Ví dụ tách DB theo chiều ngang ở project C2
 Ở project C2: phân chia DB Server thành 2 set, 8 DB schema.
Rule: Tách 8 schema bằng cách thực hiện user_id % 8 (mod)
Khi tải lên DB tăng, có thể tách đến 8 DB Server
※Tuy nhiên, nếu mod 128 thì có thể tách đến 128 server, như vậy việc quản lý rất khó khăn
nên cần cân nhắc.
DB ~Horizontal sharding/c2~
slave/
master
slave backup
37
Lưu db
00,02,04,06
slave/
master
slave backup
Lưu db
01,03,05,07
API PHP-FPM
Kết nối đến đích(DB) phù hợp bằng
program
Nếu mod = 0,2,4,6 => [db server1m]
Nếu mod = 1,3,5,7 => [db server2m
00 02
04 06
00 02
04 06
01 03
05 07
01 03
05 07
[db server1m]
[db server1s] [db server2s]
[db server2m]

38. Lưu theo từng table và chia File
Bằng việc quyết định nguyên tắc rồi phân chia khu vực lưu trong 1 Table thành
nhiều phần: Khi tham chiếu sẽ tìm kiếm được data trên 1 khu vực, giúp rút
ngắn thời gian tìm kiếm
Table A
100,000,000(1 hundred million) records
↓
Table A[partition]
1,000,000(1 million) × 100[partition]
=>Tìm kiếm theo nguyên tắc thì chỉ tham chiếu đến 1partition.
MySQL yêu cầu bao gồm cả partition rule column vào Primary Key
DB ~table partitioning~
38

39. CREATE TABLE文
CREATE TABLE `log_training`(
`id` bigint unsigned auto_increment NOT NULL COMMENT '管理用ID'
,`user_id` int unsigned NOT NULL COMMENT 'ユーザーID'
,`mst_training_id` int unsigned NOT NULL COMMENT '特訓ID'
,`type` int unsigned NOT NULL COMMENT '種別(0:消費、1:付与、2:売却)'
,`amount` int NOT NULL COMMENT '増減量'
,`count` int unsigned NOT NULL COMMENT '個数'
,`created` datetime NOT NULL COMMENT '登録日時'
,PRIMARY KEY(`id`, `user_id`)
,KEY log_training_idx1(`user_id`)
,KEY log_training_idx2(`mst_training_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='特訓ログ'
PARTITION BY HASH(MOD(`user_id`, 100)) PARTITIONS 100;
※ user_idを100で割った余りでpartition100個を入れ分けている
※ 主キーにpartition ルールで使っているuser_idカラムを含めている
DB ~table partitioning~
39

40.  Sơ đồ Table partitioning
Table log_training
DB ~table partitioning~
40
Khu vực lưu 1
Table đang
được phân chia
Khi chỉ định user_id trong câu lệnh WHERE rồi tìm
kiếm: Chỉ tìm kiếm trên khu vực tương ứng
[Quy định] user_id % 100
・mod 0 -> 00 Lưu vào Khu vực 00
・mod 1 -> 01 Lưu vào Khu vực 01
・mod 99-> 99 Lưu vào Khu vực 99
00
X
[Table log_training]
01 03 04 05 06 99
Khu vực lưu

41. DB server có nhiều parameter để thay đổi. Cần thay đổi thiết
lập phù hợp với yêu cầu của hệ thống
（Cụ thể trình bày ở Section 2 ）
DB ~Setting~
41

42. Một số thiết lập parameter trên Linux Kernel
・Memory
・Tăng số lượng File có thể Open
・Tăng số lượng Process có thể khởi động
・Thiết lập Disk
・Thiết lập Network
・Tăng Ephemeral port ,…
（Cụ thể trình bày ở Section 2）
Linux Setting
42

43. Section 2
設定の説明（具体的）
Giải thích cài đặt (Chi tiết)
43

44. WEB/API SERVER
LoadBalancer
Nginx
php-fpm
44

45. LoadBalancer
Điều hướng access đến server bằng LoadBalancer
Global IP/port と振り分け先のサーバーIP/portを登録するGlobalIPへのrequestが振り
分け先サーバーどれか1台に渡される
Đăng ký Global IP/port và IP/port của server đích để thực hiện điều hướng đến 1
server đích
（例）Phương pháp thiết lập bằng GMO App Cloud
45

46. LoadBalancer
（VD）Cách thiết lập bằng GMO App Cloud/ điều hướng về 2 server đích
46

47. Nginx ~Giải thích~
Nginx là http daemon, có khả năng đối ứng lượng access lớn
bằng Non blocking I/O và async I/O
Có khả năng L7 Load balancing bằng URL
Có nhiều chức năng độc đáo bằng Lua script và ngôn
ngữ C, có thể giải quyết các xử lý phức tạp
47

48. Nginx ~conf~
/etc/nginx.conf の重要パラメータ
Parameter quan trọng
worker_processes
Khởi động bao nhiêu worker process
worker_connections
Số lượng kết nối tối đa trên 1 worker
multi_accept on
Bật chế độ nhận đồng thời nhiều request
use epoll
Dùng kernel đối ứng thay đổi trạng thái request, tiến hành xử lý tiếp theo (Linux
System call)
48

49. FPM (FastCGI Process Manager)
Daemon để thực hiện PHP script trên Web server
Một trong những chức năng FastCGI của PHP
FastCGI là gì
requet毎に生成破棄されるCGIプロセスを保持するようにし
て高速に再利用できるようにした仕組み
Là cơ chế để duy trì hủy/ tạo process CGI với từng request
để có thể sử dụng lại ở tốc độ cao
php-fpm ~Giải thích~
49

50. Setting quan trọng
pm.max_children
Số lượng worker lớn nhất của php-fmp, giá trị này là quan trọng
nhất
Nên thiết lập giá trị lớn đến mức server memory cho phép
Đo memory sử dụng bằng lệnh bên dưới
ps aux | grep php-fpm | awk '{sum += $6} END {print sum}'
pm.start_servers
Số lượng worker tạo ra khi khởi động
pm.min_spare_servers
Số lượng worker tối thiểu duy trì
pm.process_idle_timeout
workerを停止するまでのidle時間min_spare_servers数
php-fpm ~php-fpm.conf~
50

51. Kiểm tra log khi test tải
Khi tiến hành test chịu tải:các trường hợp các thông tin như
max_children bị thiếu,… sẽ được xuất ra error logs
Nhớ kiểm tra log khi test!
php-fpm ~php-fpm.conf~
51

52. Cache Server
memcached
Redis
52

53. Cache ~memcached~
Các Parameter quan trọng trong
/etc/sysconfig/memcached
MAXCONN = 65535
Số lượng kết nối tối đa, cần lớn hơn số cổng tạm
CACHESIZE = 3000 (MB)
Thiết lập trong phạm vi Memory vật lý có thể sử dụng
53

54. Cache ~memcached~
Cần lưu ý
・Memcached server: Khi test tải, dễ phát sinh lỗi kết nối do cạn kiệt port
=>nên chuẩn bị nhiều server.
・Việc có quá nhiều kết nối TCP đến Memcached server là nguyên nhân làm
giảm throughput
=>Việc cache các giá trị cố định thì nên tiến hành trên memcached đã xây
dựng tại chính API server
※Tại dự án C2, các giá trị biến đổi thì cache trên Memcached Server, còn
thông tin table meta và thông tin master thường không đổi thì cache trên
localhost
54

55. Các parameter quan trọng
maxclients 50000
Số lượng kết nối tối đa
maxmemory 14gb
Size Memory tối đa
Mặc dù có nhiều parameter nhưng các thiết lập trên cần điều
chỉnh phù hợp với Server Resource ở mức thấp nhất
Cache ~Redis~
55

56.  Khi dùng Replication: nếu có thể nên thiết lập với 3 server trở lên
Khi thừa 1 server SlaveDB
・Có thể đọc DB realtime
・Có thể thực hiện query nặng mà không ảnh hưởng đến end-user
・Có thể dừng ghi vào DB và thực hiện Backup
・Có tính dự phòng trong trường hợp MasterDB gặp sự cố
・ vv
(1)masterDB（Dành cho end-user）
(2)slaveDB（Dành cho end-user ）
(3)slaveDB（Cho nội bộ công ty /đọc KPI/ Backup/ Server dự phòng）
Cần lưu ý DB 1/2
56

57.  Nên backup bằng cách copy từng mysql dir
・Back up mỗi thư mục /var/lib/mysql bằng tar command.
・Trong file /var/lib/mysql/master.info có các thiết lập replication và binlog
position. Nếu file binlog vẫn còn lưu trong masterDB thì có thể khôi phục từ
backup đến trạng thái gần nhất.
Cần lưu ý DB 2/2
57

58. Parameter đã có hiệu quả cao trong C2
※Vì parameter có hiệu quả khác nhau tùy theo yêu cầu của hệ thống nên cần điều
tra theo từng hệ thống
Giá trị đã thiết lập trong test chịu tải
max_connections: 10000
Lỗi giới hạn trên số lượng connection phát sinh.
Sau khi tăng số lượng trong phạm vi bộ nhớ cho phép -> đã giảm được lỗi này
transaction-isolation: READ-COMMITTED
Thay đổi này giúp giảm việc chờ lock
※Thiết lập theo điều kiện của dự án C2
innodb_buffer_pool_instances: 16
->Đã cải thiện được một chút qps
DB ~my.cnf /Có hiệu quả 1/2
58

59. innodb_lock_wait_timeout: 5
Thời gian đợi lock quá dài sẽ dễ phát sinh lỗi vượt giới hạn connection
-> lockwait trên 5 sec thì được cho là thất bại và ép kết thúc, giúp giảm tắc nghẽn toàn bộ
innodb_io_capacity_max: 30000
innodb_io_capacity: 20000
Thiết lập cho Fusion ioMemory
※Set io_capacity tới giá trị cao hơn 100000,… thì từ lần thứ 2 trở đi, qps đã giảm xuống đến
50% khi chịu tải cao
innodb_buffer_pool_size: 64G
Thiết lập với 80% memory để các ứng dụng khác vẫn còn bộ nhớ để hoạt động
->Không được để xảy ra swap trên DB server, gây chậm
innodb_flush_method: O_DIRECT
Write trực tiếp không sử dụng page cache của os
DB ~my.cnf /Có hiệu quả 2/2
59

60. Setting my.cnf tại C2（Ansible template）
character_set_server: utf8mb4
max_connections: 10000
max_connect_errors: 50
transaction-isolation: READ-COMMITTED
# innodb
innodb_buffer_pool_size: 64G
innodb_buffer_pool_instances: 16
innodb_flush_method: O_DIRECT
innodb_flush_log_at_trx_commit: 1
innodb_file_per_table: 1
innodb_data_file_path: ibdata1:10M:autoextend
innodb_file_format: Barracuda
open_files_limit: 163840
innodb_open_files: 128000
DB ~my.cnf 1/3~
60

61. # Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size: 2G
innodb_log_buffer_size: 64M
innodb_support_xa: 1
innodb_lock_wait_timeout: 5
# io threads : nếu là trạng thái có thể xử lý song song: set tối đa 64
innodb_write_io_threads: 16
innodb_read_io_threads: 16
innodb_thread_concurrency: 0
# fusion-io/SSD
innodb_io_capacity_max: 30000
innodb_io_capacity: 20000
# memory
sort_buffer_size: 2M
join_buffer_size: 2M
read_buffer_size: 1M
max_allowed_packet: 4M
DB ~my.cnf 2/3~
61

62. # replication
server_id: "{{ ansible_all_ipv4_addresses[0].split('.')[3] }}"
log_slave_updates: ON
# binlog
log_bin: mysql-bin
binlog_format: MIXED
expire_logs_days: 180
max_binlog_size: 500MB
DB ~my.cnf 3/3~
62

63. Linux Kernel
Parameter
63

64. Bằng việc thay đổi thiết lập Kernel, khả năng xử lý
của Server sẽ mạnh hơn
Cần điều chỉnh setting DB Server, API Server phù
hợp với yêu cầu của hệ thống
※Cụ thể: giới thiệu ở các trang sau
Kernel Setting ~~
64

65. Các thiết lập Linux kernel quan trọng
net.core.somaxconn=65535
Số lượng kết nối TCP: nên cài đặt số lượng Port tối đa
net.ipv4.ip_local_port_range=10000 65535
Thiết lập Ephemeral port, tăng số lượng cổng default từ 28000 lên 55000
net.ipv4.tcp_fin_timeout=5
Thời gian TCP Session đổi trạng thái từ FIN-WAIT2 sang TIME_WAIT
net.ipv4.tcp_tw_reuse=1
Tái sử dụng port ở trạng thái TIME_WAIT (có thể tái sử dụng khi IP/port kết nối
cùng server)
Với thiết lập như phía trên, có thể tối đa hóa số lượng kết nối đồng thời và giải
quyết vấn đề cạn kiệt port
Kernel Setting ~/etc/sysctl.conf 1/3~
65

66. fs.file-max=10000000
Số lượng file có thể Open (trên toàn OS)
kernel.threads-max=1000000
Số lượng thread có thể khởi động trên OS
vm.swappiness=0
Thiết lập trạng thái tích cực dùng Swap
0: Không swap đến khi hết memory vật lý
Thiết lập Common Memory
kernel.shmmax=68719476736
kernel.shmall=4294967296
Kernel Setting ~/etc/sysctl.conf 2/3~
66

67. net.core.netdev_max_backlog=10240
Số lượng packet tối đa có thể đưa vào hàng đợi khi nhận packet
net.ipv4.tcp_max_syn_backlog=4096
Số lượng connection có thể duy trì của trạng thái không tiếp nhận ACK mà đang nhận
SYN trên từng socket
net.ipv4.tcp_keepalive_time=65
net.ipv4.tcp_keepalive_probes=4
net.ipv4.tcp_keepalive_intvl=5
Thiết lập duy trì kết nối TCP: Sau khi đã duy trì 65 giây, xác nhận 4 lần cứ mỗi 5 giây
sau đó. Nếu không có câu trả lời, tiến hành ngắt kết nối TCP
Kernel Setting ~/etc/sysctl.conf 3/3~
67

68. Thiết lập /etc/security/limits.conf : Thiết lập file descripter có thể open và
số lượng process có thể khởi động
File descriptor là 1 số integer unique để phân biệt giữa các file
Khi tăng giá trị, lỗi Too many open files sẽ khó xảy ra hơn
VD:
Thay đổi giới hạn trên của file descripter và số lượng process của os user
C2
c2 soft nofile 65535
c2 hard nofile 65535
c2 soft nproc 1006500
c2 hard nproc 1006500
Kernel Setting ~limits.conf~
68

69. Systemd có thể khởi động process khá linh hoạt
Có thể thay đổi số lượng File có thể Open và số lượng process có thể khởi
động
VD
/etc/systemd/system/mariadb.service.d/XXXX.conf
[Service]
LimitNOFILE=1006500
LimitNPROC=1006500
※Suggest nên chỉ định giới hạn trên đến 1006500
Kernel Setting ~systemd~
69

70. Tuned là Daemon điều chỉnh system setting tĩnh và động
theo profile đã được lựa chọn trên Centos 7
Có thể thay đổi setting bằng lệnh tuned-adm
tuned-adm profile c2
Có thể tuỳ biến tuned profile
/usr/lib/tuned/c2/tuned.conf
tuned
[main]
include= throughput-performance
[vm]
transparent_hugepages=never
vm.swappiness=0
C2 thiết lập kế thừa throughput-performance profile, thực hiện cancel
transparent_hupage và không dùng swap trong khả năng có thể
Kernel Setting ~tuned~
70

71. 以上になります
ご清聴ありがとうございました
「Cảm ơn các bạn đã lắng nghe」
質問があればどうぞ
（Any Question?）
終わり
71