Làm cách nào để hiểu sự khác biệt của PostgreSQL giữa đề xuất nhóm kết nối ((2 * n_cores) + n_disks) và hỗ trợ cho 100 giây kết nối?

Từ các tài liệu PostgreSQL:

• Số lượng kết nối cơ sở dữ liệu -> Cách tìm kích thước nhóm kết nối cơ sở dữ liệu tối ưu

  để thông lượng tối ưu, số lượng kết nối hoạt động phải ở gần ((core_count * 2) + hiệu quả_spulum_count)

• Điều chỉnh máy chủ PostgreSQL của bạn -> max_connections

  Nói chung, PostgreSQL trên phần cứng tốt có thể hỗ trợ vài trăm kết nối.

Đối với tôi - không phải là một DBA có kinh nghiệm - có một sự khác biệt ở đâu đó ở đây, đặc biệt là xem xét các dịch vụ của một số nhà cung cấp DB-as-a-Service.

Ví dụ: tại thời điểm này, máy lớn nhất của Amazon RDS (db.r3.8xlarge) có 32 vCPU, theo công thức đầu tiên có lẽ sẽ quản lý để chạy tối ưu với 100 kết nối trong nhóm, được cung cấp nhiều đĩa. Mặc dù nó sẽ chạy rất tệ với "vài trăm kết nối" từ công thức thứ hai?

Thậm chí cực đoan hơn là sự khác biệt đối với một nhà cung cấp DBaaS khác, người đề xuất một máy chủ 2 lõi với 500 kết nối đồng thời. Làm thế nào điều này có thể làm việc tốt?

Nếu tôi hiểu nhầm điều gì đó, xin vui lòng cho tôi biết. Cảm ơn nhiều!

"Có thể hỗ trợ"! = "Thông lượng tối ưu".

Bạn có thể sử dụng nhiều kết nối, nhưng nó chậm hơn.

Nếu bạn sử dụng ít kết nối và công việc xếp hàng hơn, bạn sẽ nhận được cùng một lượng công việc được thực hiện trong thời gian nhỏ hơn.

Thậm chí cực đoan hơn là sự khác biệt đối với một nhà cung cấp DBaaS khác, người đề xuất một máy chủ 2 lõi với 500 kết nối đồng thời. Làm thế nào điều này có thể làm việc tốt?

Hoặc họ đang sử dụng một giao diện kết nối như PGBouncer trong chế độ tổng hợp giao dịch, hoặc nó sẽ không hoạt động tốt.

Mọi người thích số lớn, vì vậy họ sẽ cung cấp cho bạn số lớn.

Họ thực sự làm tổn thương hiệu suất bằng cách làm như vậy. PostgreSQL có một số chi phí theo tỷ lệ tuyến tính max_connections, vì vậy ngay cả khi các kết nối không được sử dụng, nó vẫn có tác động hiệu suất.

Ngoài ra, ngay cả các kết nối nhàn rỗi có thêm một số chi phí vệ sinh.

Nếu các kết nối đang hoạt động tích cực, thì bạn cũng có sự tranh chấp về tài nguyên hệ thống và về các khóa bên trong.

Tôi thường xuyên gặp những người gặp vấn đề về hiệu năng của PostgreSQL - và họ cố gắng giải quyết chúng bằng cách thêm nhiều kết nối hơn, nhiều nhân viên hơn trong ứng dụng của họ, v.v. Đặc biệt là những người chạy hệ thống xếp hàng. Thật khó để thuyết phục họ rằng việc giảm số lượng công nhân sẽ khiến hệ thống hoạt động nhanh hơn và vấn đề hiệu suất ban đầu của họ bắt nguồn từ việc có quá nhiều ở nơi đầu tiên.

Rất nhiều ứng dụng có kỷ luật kết nối kém, giữ kết nối mở ngay cả khi chúng không được sử dụng.

Đặt giới hạn kết nối cao là bảo hiểm giá rẻ đối với các ứng dụng này. Cho đến khi một cái gì đó thay đổi và các ứng dụng quyết định chủ động sử dụng tất cả các kết nối đó, thì bảo hiểm trở nên khá đắt đỏ.

Một sự khác biệt quan trọng để đưa ra giữa hai tuyên bố được so sánh trong câu hỏi là đầu tiên là một công thức sơ bộ cho số lượng kết nối hoạt động tại một thời điểm. Khiếu nại thứ hai dành cho cài đặt mà bạn đặt đúng mức tối đa cho phép mà Postgres sẽ chấp nhận. Đây là hai điều riêng biệt.

Khi bạn quay lại và đọc bài viết Kích thước nhóm kết nối cơ sở dữ liệu tối ưu , bạn sẽ thấy rằng nó gợi ý rằng bạn đặt nhóm kết nối hoạt động của mình ở phía máy khách, trái ngược với phía máy chủ. Họ cũng đề nghị bạn để lại đủ dung lượng trong giá trị max_connections của mình để phù hợp với các kết nối cố định, chẳng hạn như hoạt động khách hàng thực hành và hoạt động quản trị. Bạn không muốn đặt max_connections của mình thành giới hạn kết nối hoạt động của nhân viên của bạn hoặc bạn có thể không thể truy cập được khi bạn cần!