MariaDB Advance: thread pool

Word Image 99

Thread Pools có thể làm gì?

Theo truyền thống, MySQL đã gán một Thread cho mọi kết nối client và khi số lượng user đồng thời tăng lên, mô hình này cho thấy hiệu suất giảm. Nhiều luồng hoạt động sẽ giết hiệu năng, bởi vì việc tăng số lượng Thread dẫn đến chuyển đổi ngữ cảnh xấu cho bộ nhớ CPU và tăng sự tranh chấp đối với các khóa nóng. Một giải pháp lý tưởng sẽ giúp giảm chuyển đổi ngữ cảnh là duy trì số lượng Thread thấp hơn số lượng user. Nhưng con số này cũng không nên quá thấp, vì chúng ta cũng muốn sử dụng CPU hết mức, vì vậy lý tưởng nhất là phải có một Thread hoạt động duy nhất cho mỗi CPU trên máy.

Các tính năng của MariaDB Thread Pool

Bắt đầu từ  MariaDB 5.5 triển khai một nhóm dynamic/adaptive pool, tự nó sẽ đảm nhiệm việc tạo ra các Thread mới trong thời điểm có nhu cầu cao và giảm bớt Thread khi không có nhu cầu hoạt động.

Đây là cách hoạt động kết thừa từ thông số pool-of-threads, với các mục tiêu sau:

Khi nào sử dụng Thread Pool

Thread Pool hiệu quả nhất trong các tình huống trong đó các truy vấn tương đối ngắn và tải bị ràng buộc bởi CPU, chẳng hạn như trong khối lượng công việc OLTP(Online Transaction Processing). Nếu khối lượng công việc không bị ràng buộc bởi CPU, thì bạn vẫn có thể hưởng lợi từ việc giới hạn số lượng luồng để tiết kiệm bộ nhớ ram cho database memory buffers(bộ nhớ đệm trên ram)

Khi nào Thread Pool sẽ kém hiệu quả

Có những trường hợp đặc biệt, hiếm gặp trong đó Thread Pool  kém hiệu như sau

Cấu hình Thread Pool trên hệ thống Unix

Biến thread_handling  là biến hệ thống chính được sử dụng để cấu hình Thread Pool.

Bạn có thể thêm cấu hình sau vào file my.cnf  và khởi động lại MariaDB để kích hoạt.

[mariadb]
...
thread_handling = pool-of-thread

Các biến hệ thống sau đây cũng có thể được cấu hình trên Unix:

Cấu hình lập  lịch ưu tiên

Bắt đầu với MariaDB 10.2.2 , có thể định cấu hình mức độ ưu tiên kết nối. Hành vi ưu tiên được cấu hình bởi thread_pool_priority .

Theo mặc định, nếu thread_pool_priority được đặt thành auto, thì các query sẽ được ưu tiên cao hơn trong trường hợp kết nối hiện tại nằm trong một transaction. Điều này cho phép transaction đang chạy kết thúc nhanh hơn và có tác dụng hạ thấp số lượng transaction đang chạy song song. Cài đặt mặc định thường sẽ cải thiện thông lượng cho khối lượng công việc transaction. Nhưng cũng có thể đặt rõ ràng mức độ ưu tiên cho kết nối hiện tại thành ‘cao’ hoặc ‘thấp’.

Ngoài ra còn có một cơ chế để đảm bảo rằng các kết nối ưu tiên cao hơn sẽ không độc quyền các luồng công nhân trong nhóm (điều này sẽ gây ra sự chậm trễ vô thời hạn cho các kết nối ưu tiên thấp). Trên Unix, các kết nối ưu tiên thấp được đưa vào hàng ưu tiên cao sau khi hết thời gian được chỉ định bởi thread_pool_prio_kickup_timer .

Monitoring Thread Pool

Variable Description
Threadpool_threads Số lượng thread trong thread pool. Trong các trường hợp hiếm hoi, giá trị này có thể cao hơn một chút thread_pool_max_threads, bởi vì mỗi thread group cần ít nhất hai threads (tức là ít nhất một worker thread và ít nhất một  listener thread) để ngăn chặn tắt nghẽn.
Threadpool_idle_threads Số lượng thread không hoạt động trong thread pool. Thread trở nên không hoạt động vì nhiều lý do, chẳng hạn như bằng cách chờ đợi công việc mới. Tuy nhiên, một thread không hoạt động không nhất thiết là một thread chưa được phân công công việc. thread cũng được coi là không hoạt động nếu chúng bị chặn trong khi chờ vào I/O trên đĩa hoặc trong khi chờ khóa, v.v. Biến trạng thái này chỉ có ý nghĩa trên Unix .

Notes.

Các thread_cache_size không được sử dụng khi các thread pool được sử dụng và các Threads_cached  sẽ có một giá trị là 0.

Exit mobile version