Điều chỉnh tham số max_connections và shared_buffers cho OLTP
Bước đầu tiên là tinh chỉnh số lượng kết nối đồng thời và bộ nhớ chia sẻ để phục vụ các giao dịch OLTP cần tốc độ phản hồi cao.
Tham số max_connections trong Greenplum được áp dụng cho mỗi segment. Nếu đặt quá cao, hệ thống sẽ bị quá tải do tạo quá nhiều tiến trình. Đối với mô hình Hybrid, ta cần cân bằng giữa số lượng client OLTP và tài nguyên segment.
Tham số shared_buffers là bộ nhớ dùng để cache dữ liệu trong RAM. OLTP hưởng lợi lớn từ việc cache các bảng nóng (hot tables). Khuyến nghị là 25-33% tổng RAM của máy chủ, nhưng không vượt quá giới hạn vật lý.
Chỉnh sửa file cấu hình chính của Greenplum Database.
sudo nano /opt/greenplum-db-7x/bin/gp_config
Thêm hoặc cập nhật các dòng sau vào file (giả sử RAM 64GB, muốn dành 16GB cho shared_buffers và giới hạn 50 kết nối mỗi segment):
max_connections=50
shared_buffers=16GB
Lưu lại file và thoát. Sau đó, cần khởi động lại toàn bộ cluster để áp dụng các thay đổi về bộ nhớ và kết nối.
source /opt/greenplum-db-7x/greenplum_path.sh
gpstop -u -m restart -R master -v 3
Kết quả mong đợi: Cluster khởi động lại thành công, thông báo "Master is up" và các segment đang chạy với cấu hình mới.
Verify kết quả
Kiểm tra các tham số đã áp dụng thông qua lệnh SQL sau:
psql -U gpadmin -d postgres -c "SHOW max_connections; SHOW shared_buffers;"
Đầu ra phải hiển thị giá trị 50 và 16GB tương ứng.
Cấu hình memory_spill_threshold và work_mem cho query OLAP
Chuyển sang tối ưu hóa cho các truy vấn OLAP phức tạp, nơi cần xử lý tập dữ liệu lớn và các thao tác Sort/Hash.
Tham số work_mem xác định lượng bộ nhớ tối đa dùng cho các thao tác như sort hoặc hash join trong một câu lệnh. Với OLAP, ta cần tăng giá trị này để giảm việc spill ra đĩa (disk I/O).
Tham số memory_spill_threshold xác định điểm mà Greenplum bắt đầu spill dữ liệu ra file tạm trên đĩa thay vì giữ trong RAM. Để tối ưu, ta nên đặt giá trị này cao để khuyến khích xử lý hoàn toàn trong RAM nếu có thể.
Chỉnh sửa file cấu hình để thiết lập các giá trị mặc định cho toàn cluster hoặc theo session.
sudo nano /opt/greenplum-db-7x/bin/gp_config
Thêm các dòng cấu hình sau (giả sử muốn work_mem = 2GB và threshold = 2GB):
work_mem=2GB
memory_spill_threshold=2GB
Khởi động lại cluster để áp dụng:
gpstop -u -m restart -R master -v 3
Đối với các query OLAP đặc thù, ta có thể thiết lập tạm thời trong session để kiểm tra hiệu năng trước khi áp dụng toàn cầu.
psql -U gpadmin -d postgres -c "SET work_mem TO '4GB'; SET memory_spill_threshold TO '4GB';"
Kết quả mong đợi: Query chạy nhanh hơn đáng kể khi xử lý các bảng lớn, giảm thiểu thời gian I/O do spill.
Verify kết quả
Thực hiện một query phức tạp (ví dụ: ORDER BY trên bảng lớn) và kiểm tra EXPLAIN ANALYZE để xem có dòng nào chứa "Disk" hay không.
psql -U gpadmin -d postgres -c "EXPLAIN ANALYZE SELECT * FROM large_table ORDER BY id LIMIT 100000;"
Đầu ra mong muốn: Không xuất hiện dòng "Disk" trong phần execution plan, hoặc thời gian execution giảm đáng kể.
Thiết lập checkpoint và vacuum settings để cân bằng hiệu năng
Bước tiếp theo là quản lý quá trình ghi log (WAL) và dọn dẹp dữ liệu (Vacuum) để cân bằng giữa tốc độ ghi (OLTP) và hiệu năng đọc (OLAP).
Tham số checkpoint_completion_target xác định thời gian phân bổ cho quá trình checkpoint. Đặt cao (ví dụ 0.9) giúp trải đều I/O, tránh nghẽn cổ chai đột ngột khi ghi WAL, rất quan trọng cho OLTP.
Tham số autovacuum_vacuum_scale_factor và autovacuum_analyze_scale_factor điều chỉnh tần suất tự động vacuum. Đối với Hybrid, cần giảm giá trị này xuống để đảm bảo dữ liệu luôn được làm sạch, tránh bloat gây chậm query OLAP.
Chỉnh sửa file cấu hình:
sudo nano /opt/greenplum-db-7x/bin/gp_config
Thêm các dòng sau:
checkpoint_completion_target=0.9
autovacuum_vacuum_scale_factor=0.05
autovacuum_analyze_scale_factor=0.05
vacuum_cost_limit=200
Giải thích: Scale factor 0.05 nghĩa là vacuum sẽ chạy sau mỗi 5% thay đổi trong bảng, giúp giữ bảng "sạch" hơn so với mặc định (thường là 0.2). Vacuum_cost_limit=200 giúp vacuum chạy mượt mà hơn, ít ảnh hưởng đến query đang chạy.
Khởi động lại cluster:
gpstop -u -m restart -R master -v 3
Kết quả mong đợi: Quá trình checkpoint diễn ra mượt mà, ít gây spike I/O. Autovacuum chạy thường xuyên hơn để giữ hiệu năng đọc ổn định.
Verify kết quả
Kiểm tra trạng thái autovacuum và các tham số:
psql -U gpadmin -d postgres -c "SHOW autovacuum_vacuum_scale_factor; SHOW checkpoint_completion_target;"
Đầu ra phải hiển thị 0.05 và 0.9. Kiểm tra log Greenplum để đảm bảo không có cảnh báo về checkpoint delay.
Cấu hình parallel query execution cho các bảng lớn
Bước cuối cùng là tối ưu hóa việc sử dụng đa luồng (parallelism) cho các query OLAP quét toàn bộ bảng lớn.
Tham số gp_parallel_query_threshold xác định ngưỡng kích thước bảng (số dòng) mà Greenplum sẽ tự động kích hoạt parallel scan. Đối với OLAP, ta cần giảm ngưỡng này xuống để kích hoạt song song sớm hơn.
Tham số gp_parallel_query_scan_threshold (trong các phiên bản mới hơn) hoặc max_parallel_workers_per_gather (PostgreSQL backend) cũng cần được xem xét để giới hạn số worker trên mỗi segment, tránh quá tải CPU.
Chỉnh sửa file cấu hình:
sudo nano /opt/greenplum-db-7x/bin/gp_config
Thêm các dòng sau (giả sử kích hoạt parallel scan khi bảng có > 1000 dòng):
gp_parallel_query_threshold=1000
max_parallel_workers_per_gather=4
Giải thích: Ngưỡng 1000 dòng giúp các bảng vừa và lớn đều được xử lý song song. Giới hạn 4 worker mỗi gather đảm bảo không chiếm hết CPU của segment cho một query duy nhất.
Khởi động lại cluster:
gpstop -u -m restart -R master -v 3
Kết quả mong đợi: Các query quét bảng lớn sẽ sử dụng nhiều segment và CPU cores hơn, giảm thời gian thực thi tổng thể.
Verify kết quả
Thực hiện một query quét toàn bảng và xem Execution Plan:
psql -U gpadmin -d postgres -c "EXPLAIN SELECT count(*) FROM large_hybrid_table;"
Đầu ra mong muốn: Trong phần "Distribution" hoặc "Nodes", bạn thấy nhiều worker đang chạy song song (ví dụ: "Gather Motion: Scatter/Gather" với nhiều worker). Nếu không thấy parallel, kiểm tra lại ngưỡng threshold.
Điều hướng series:
Mục lục: Series: Triển khai Database Hybrid OLTP/OLAP với Greenplum trên Ubuntu 24.04
« Phần 4: Cấu hình kiến trúc Cluster và khởi tạo Greenplum Database
Phần 6: Thiết lập dữ liệu và chỉ mục cho xử lý lai OLTP/OLAP »