Trong quá trình triển khai hệ thống Odoo trên Centos 8, việc cấu hình nginx, PostgresSQL và pgBouncer là rất quan trọng để đảm bảo hệ thống hoạt động ổn định và hiệu quả. IZISolution sẽ hướng dẫn các bước cấu hình chi tiết để giúp bạn triển khai Odoo trên hệ thống Centos 8 một cách nhanh chóng và dễ dàng trong nội dung bài viết dưới đây.
I. Hướng dẫn cấu hình Nginx
Cài đặt
Cài đặt EPEL repository
$ sudo yum install epel-release
Update the repository
$ sudo yum update
Install NGINX Open Source
$ sudo yum install nginx
Verify the installation
$ sudo nginx -v
Cấu hình
Cấu hinh proxy_mode = True nếu Odoo đứng sau 1 reverse proxy(nginx)
Trong file odoo.conf
proxy_mode = True
nginx.conf
#odoo server
upstream odoo {
server 127.0.0.1:8069;
}
upstream odoochat {
server 127.0.0.1:8072;
}
# http -> https
server {
listen 80;
server_name odoo.mycompany.com;
rewrite ^(.*) https://$host$1 permanent;
}
server {
listen 443;
server_name odoo.mycompany.com;
proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;
# Add Headers for odoo proxy mode
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
# SSL parameters
ssl on;
ssl_certificate /etc/ssl/nginx/server.crt;
ssl_certificate_key /etc/ssl/nginx/server.key;
ssl_session_timeout 30m;
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
# log
access_log /var/log/nginx/odoo.access.log;
error_log /var/log/nginx/odoo.error.log;
# Redirect longpoll requests to odoo longpolling port
location /longpolling {
proxy_pass http://odoochat;
}
# Redirect requests to odoo backend server
location / {
proxy_redirect off;
proxy_pass http://odoo;
}
# common gzip
gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
gzip on;
}
II. Hướng dẫn cấu hình PostgresSQL
Cách tham số cấu hình để tối ưu PostgresSQL đều được cấu hình trong file /postgresql.conf
max_connections: #Số lượng connection tối data được connect tới database, số lượng connnect nên trong khoảng vài trăm connection để hệ thống PostgresSQL hoạt động được hiệu quả nhất(tầm 500 connect)
shared_buffers: #Bao nhiêu RAM được PostgresSQL sử dụng để cache data.
- 25% of RAM của hệ thống vật lý
- Lớn hơn 55% VM RAM đối với hệ thống ảo hoá
effective_cache_size: #Thiết lập để hệ thống dự tính kích kích thước ổ cứng khả dụng để caching data.
- Nên là 50% RAM
- 75% RAM hơi quá nhưng có thể chấp nhận được
work_mem: #Nếu bạn thực hiện nhiều xắp sếp phức tạp và có nhiều RAM thì nên cấu hình lại tham số này để tăng hiệu năng cho PostgresQL server. Tham số này có giá trị trên mỗi connnection
Trong phần các công thức để cấu hình Odoo ta có 1 công thức như sau:
(1 + #workers + #max_cron_threads) * #db_maxconn < #max_connections
Mặc định trong odoo đã cấu hình các thông số sau:
#max_cron_threads = 2
#db_maxconn = 64
Nếu #workers ta để là 6 vậy giá trị max_connections sẽ phải cấu hình
#max_connections > 64 * (1 + 6 + 2) = 576
=> #max_connections > 576
=> Ta cần thiết lập lại max_connections trong postgres.conf lên tầm 600 là hợp lý
Nhưng như trên ta cũng đã nói rằng để postgres hoạt động tốt ta cần cấu hình max_connections tầm 500, như vậy vậy số lượng worker tăng hơn nữa thì vấn đề sẽ xảy ra và để giải quyết vấn đề này ta sẽ sử dụng pgBouncer để khắc phục.
Lý do max_connections nên được thiết lập tầm trên dưới 500 là do cơ chế thiết lập các connection của postgres tương đối phức tạp và tốn tài nguyên vì để cô lập các connection nhằm đem lại sự ổn định kết nối. Điều đó dẫn đến khi sử lý các kết nối đơn giản, ngắn hạn nó lại trở thành nhược điểm.
III. Hướng dẫn cấu hình pgBouncer
Như đã nói ở bên trên, để khắc phục tình trạng số lượng connection đến postgres có thể lên đến quá lớn, cũng như hạn chế việc sinh ra các connection ngắn tốn tài nguyên, ta sẽ áp dụng thêm pgBouncer để sử lý vấn đề này.
Bạn có thể đặt pgBouncer tại 3 nơi:
- Trên cùng Postgres server
- Trên cùng Odoo server
- Trên 1 server thứ 3
* Để cài đặt ta sử dụng câu lệnh sau
$ sudo yum install pgbouncer
* Tạo file pgbouncer.init để cấu hình pgBouncer với nội dung sau ở bất kỳ đâu
[databases]
#{db_name} = host={postgres_server} port={postgres_port} dbname={postgress_db_name}
template1 = host=localhost port=5432 dbname=template1
[pgbouncer]
listen_port = 6432
listen_addr = localhost
auth_type = md5
auth_file = userlist.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
* Tạo thêm 1 file userlist.txt để lưu trữ user_name, password người dùng có thể truy cập thông qua pgBouncer, nội dung như sau: “user” “password”
"user1" "md5638b81c77071ea624d1ad4adb1433540"
Trong ví dụ trên password đang được mã hoá md5
=> password = “md5” + md5_hash(password + user1)
* Khởi chạy pgBouncer
$ pgbouncer -d pgbouncer.ini
Như vậy bây giờ ta có thể kết nối đến postgres thông qua pgBouncer mà không cần kết nối trực tiếp như trước
* Tạo connection
$ psql -p 6432 -U user1 template1
* Quản lý pgBouncer bằng cách connect đến server với user pgbouncer và sử dụng sql SHOW HELP;
$ psql -p 6432 -U someuser pgbouncer
pgbouncer=# SHOW HELP;
NOTICE: Console usage
DETAIL:
SHOW [HELP|CONFIG|DATABASES|FDS|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION|...]
SET key = arg
RELOAD
PAUSE
SUSPEND
RESUME
SHUTDOWN
[...]
* Nếu bạn có bất cứ thay đổi nào trong file pgbouncer.ini bạn cần reload lại bằng cách.
$ psql -p 6432 -U someuser pgbouncer
pgbouncer=# RELOAD;
=> Một số cấu hình cần lưu ý(https://www.pgbouncer.org/config.html)
pool_mode = session #Cấu hình để khi nào 1 connection được tái sử dụng để đưa vào pool
session: Các connect được đưa bào pool khi client disconnect. Default.
transaction: Các connect được đưa vào pool khi transaction kết thúc
statement: Các connect được đưa vào poll khi query kết thúc. Transaction có nhiều statement sẽ không được đưa cho phép trong cấu hình này.
max_client_conn = 100 #Số lượng connection tối đa
default_pool_size = 20 #Số lượng connection cho phép trên mỗi user/database
III. Một số lưu ý khi cấu hình
Log
Loging: Mặc định, Odoo hiển thị toàn bộ logging info ngoại trừ logging từ workflow(chỉ cảnh báo) và đưa output vào trong file qua stdout.
$ sudo chown odoo /var/log/odoo
$ sudo chgrp odoo /var/log/odoo
[options]
addons_path = /opt/odoo10/enterprise,/opt/odoo10/odoo/addons
proxy_mode = True
logfile = /var/log/odoo/odoo.log
syslog = False
log_db = False
Log Rotation: Trong một vài trường hợp, việc để log như vậy không phải là ý tưởng tốt để thực hiện, vì có thể có nhiều worker cùng thực hiện ghi log tại 1 thời điểm và dẫn đến hệ thống bị treo. Để giải quyết vấn đề này chúng ta có một cách khác để ghi log đó là logrotate daemon. Khi đó mình sẽ cần thêm pidfile cho Odoo.
[options]
...
logrotate = False
pidfile = /var/run/odoo.pid
$ sudo apt install logrotate
$ sudo vi /etc/logrotate.d/odoo
/var/log/odoo/odoo.log {
rotate 10
daily
# Do not rotate the log if it is empty
notifempty
# if the log file is missing, go on to the next one without
# issuing an error message.
missingok
compress
delaycompress
postrotate
if [ -f /var/run/odoo.pid ]; then
kill -HUP `cat /var/run/odoo.pid`
fi
endscript
}
Check logs: Cách để hiển thị dữ liệu log trong file trên màn hình console
Hiển thị log theo thời gian thực
$ tail -f /var/log/odoo/odoo.log
Tìm trong file log bằng regex và hiển thị số dòng, 2 dòng sau và 5 dòng trước kế quả tìm.
$ grep -n Worker.*unregistered /var/log/odoo/odoo.log -A2 -B5
Log handler: Là sự kết hợp giữa logger vs log level. Nếu logger bị bỏ qua thì root logger được sử dụng. Level sẽ là 1 trong: INFO, WARNING, CRITICAL, DEBUG
[options]
...
log_handler=openerp.sql_db:DEBUG,werkzeug:DEBUG,openerp.fields:WARNING,openerp.http.rpc.request:DEBUG,:WARNING
Handler trên sẽ làm việc sau:
Debug sql queries
Debug werkzeug queries
Warn openerp.fields module
Debug RPC queries
Warn on others
Log level: là dạng ngắn gọn hơn của log handler, để dễ dàng cấu hình cho các handler thông dụng: critical, error, warn, debug, debug_sql, debug_rpc, debug_rpc_answer.
[options]
...
log_level = debug_rpc
Odoo Workers:
− Only on unix
− Python GIL: Trong CPython, Global Interpreter Lock(GIL) là một chức năng ngăn chặn nhiều luồng native thực thi mã Python cùng lúc.
Việc kích hoạt worker sẽ giúp tận dụng phần cứng tốt hơn:
− Giới hạn tài nguyên
− Tái sử dụng tiến trình sử lý
− Hiệu năng tốt hơn
− Đồng bộ các thay đổi
Add workers: Mỗi một cpu core sẽ được tính bằng 2 tiến trình sử lý vậy nên:
1 worker ~= 6 users
=> # workers = (#cpus * 2 ) + 1
[options]
...
workers = 4
max_cron_threads = 1
Mặc định odoo đang cấu hinh 0 woker tường ứng việc không sử dụng multiple-worker, nếu lên để sử dụng được ta chỉ cần tăng số lượng worker lên > 0.
* Kiểm tra log worker
openerp.service.server: Evented Service (longpolling) running on 0.0.0.0:8072
Exception: bus.Bus unavailable
* Nginx with workers
Longpolling sử dụng 1 tcp port khác vậy nên ta cần phải chuyển hướng request có chứa /longpoll/ đến đúng port.
Đừng điều hướng toàn bộ request về port đó hoặc bạn sẽ không bao giờ sử dụng workers process
[...]
upstream odoo_longpoll {
server 127.0.0.1:8072;
}
[...]
location /longpoll {
proxy_redirect off;
proxy_pass http://odoo_longpoll;
}
[...]
Workers limits: Các tham số cấu hình để quản lý process trong Odoo.
* CPU
limit_time_cpu = 60 #Thời gian tối đa cpu cho phép trên mỗi request
limit_time_real = 120 #Thời gian tối đã thực tế cho phép trên mỗi request
limit_time_real_cron = limit_time_real #Thời gian tối đã thực tế cho phép trên mỗi cron job, Bằng 0 nếu không giới hạn và mặc định bằng giá trị của limit_time_real
Nếu 1 worker đạt đến giới hạn thì tiến trình đó sẽ bị huỷ mà không cần trả về phản hổi cho client. Nếu chuyện đó xảy ra cần phải đặt lại giá trị cho các tham số trên.
* Memory: Là giá trị tối đa cho bộ nhớ ảo của mỗi worker sử dụng(bytes)
limit_memory_soft = 2 * 1024 * 1024 * 1024 #Nếu 1 worker đạt đến giá trị này thì sẽ được reset lại sau khi trả lại kết quả cho client(2 GB)
limit_memory_hard = 2.5 * 1024 * 1024 * 1024 #Nếu 1 worker đạt đến giá trị này thì sẽ được reset lại ngay mà không cần trả lại kết quả cho client(2.5 GB)
* Requests count:
limit_request = 8192 #Số lượng request tối đa được sử lý trên mỗi worker. Khi đạt đến số lượng tối data worker sẽ được reset sau khi trả lại kết quả.
* Một số công thức tính các tham số trên:
Tính worker dự trên số lượng CPU core
#worker = (#cpus * 2 ) + 1
Tính Worker dựa trên số lượng RAM:
#worker = = = 16 worker
Tính tổng số RAM cần hệ thống
* Trung bình mỗi worker thực hiện được 6-7 request/s
Bản sau là tỉ lệ RAM ước đoán sử dụng trên tổng số request
|
Type |
Ratio | Ram Estimate |
| light_worker | 80 | 150 MB |
| heavy_worker | 20 | 1024 MB |
=> Công thức tính số RAM cần dùng cho mỗi worker:
#Ram = #requests * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )
VD: Server bạn có 6 workers => #request/s = ~39request/s
=> # Ram = 39 * ((0.8 * 150) + (0.2 * 1024) = ~12GB(12667.2MB)
=> soft_memory_limit = #RAM / #workers = 12667.2 / 6 = ~2.1GB(2111.2MB)
=> soft_memory_hard = #soft_memory_limit + 500MB = 2111.2 = 500 = ~2.6GB(2611.2MB)
Wizard limits: Là dạng dữ liệu mà sau 1 khoảng thời gian sẽ bị xoá đi bằng cron
osv_memory_count_limit = 0 #Số lượng bản ghi tối đa được lưu trữ trong vitual osv_memory, mặc định là 0 là không tính.
osv_memory_age_limit = 1 #Thời gian lưu trữ tối đa sau khi bản ghi được tạo ra mặc định là 1h
Database Connection:
db_maxconn: 64 #Số lượng connection tối data được tạo từ Odoo tới PostgresSQL trên 1 Odoo process, mặc định 64.
Có 1 công thức để xác định số lượng db_maxconn an toàn để sử dụng như sau (giá trị db_maxconn có thể lớn hơn cách tính của công thức):
(1 + #workers + #max_cron_threads) * #db_maxconn < #max_connections
=> #db_maxconn < #max_connections / (1 + #workers + #max_cron_threads)
Trong đó:
max_connections là giá trị được cấu hình trong file postgres.conf trên PosgrtesSQL Server.
max_cron_threads là số thread được dùng để khởi chạy cron job được cấu hình trong file conf của Odoo app cùng mới giá trị workers
=> VD:
#max_connections = 100(default của PostgresSQL)
#workers = 6
#max_cron_threads = 2
=> #db_maxconn < 100 / (1 + 6 + 2) = ~11
=> #db_maxconn < 11
=> Số lượng db_maxconn nên thiết lập cho mỗi process < 11 để đảm bảo an toàn cho hệ thống.
![[IZISOLUTION x VNUIS] - HỘI THẢO INDUSTRY INSIGHTS SERIES](thumb/hoaithu/xdaidienizisolutionchupanhcungthaycovasinhvienvnuis_480_300.jpg.pagespeed.ic.GRNvvmUfZo.jpg)
