PostgreSQL - Nếu tôi chạy đồng thời nhiều truy vấn, trong trường hợp nào tôi sẽ thấy tăng tốc? Trong hoàn cảnh nào tôi sẽ thấy một sự chậm lại?


10

Tôi tiếp cận tất cả các bạn một cách khiêm tốn như một người KHÔNG phải là một DBA, và tôi chắc chắn rằng câu hỏi của tôi có nhiều thiếu sót về khái niệm và "nó phụ thuộc vào" mỏ đất. Tôi cũng khá chắc chắn rằng tất cả các bạn chọn trả lời sẽ muốn nhiều hơn theo cách cụ thể hơn tôi hiện có thể cung cấp.

Điều đó nói rằng, tôi tò mò về kịch bản sau đây nói chung:

  • Nói rằng tôi có hai truy vấn không tầm thường.
  • Truy vấn 1 cần 2 phút để hoàn thành trung bình.
  • Truy vấn 2 cần 5 phút để hoàn thành trung bình.

Nếu tôi chạy chúng một cách thanh thản, hết lần này đến lần khác, tôi hy vọng sẽ cần trung bình 7 phút để hoàn thành. Điều này có hợp lý không?

Tuy nhiên, nhiều hơn thế, nếu tôi chạy đồng thời hai truy vấn thì sao? Hai kết nối riêng biệt cùng một lúc.

  • Trong những điều kiện tôi sẽ mong đợi để thấy một sự tăng tốc? (Tổng thời gian <7 phút)
  • Trong những điều kiện tôi sẽ mong đợi để thấy một sự chậm lại? (Tổng thời gian> 7 phút)

Bây giờ, nếu tôi có 1.000 truy vấn không tầm thường chạy đồng thời, tôi có linh cảm rằng nó sẽ dẫn đến sự chậm lại tổng thể. Trong trường hợp đó, nút cổ chai có thể ở đâu? Bộ xử lý? RAM? Ổ đĩa?

Một lần nữa, tôi biết có lẽ không thể trả lời chính xác câu hỏi mà không biết chi tiết cụ thể (mà tôi không có.) Tôi đang tìm một số hướng dẫn chung để suy nghĩ khi đặt câu hỏi sau:

  • Trong những trường hợp nào các truy vấn đồng thời dẫn đến tăng tốc tổng thể?
  • Trong những trường hợp nào các truy vấn đồng thời dẫn đến chậm lại tổng thể?

Câu trả lời:


14

Nếu tôi chạy chúng một cách thanh thản, hết lần này đến lần khác, tôi hy vọng sẽ cần trung bình 7 phút để hoàn thành. Điều này có hợp lý không?

Nếu họ sử dụng các bộ dữ liệu không liên quan, thì có.

Nếu họ chia sẻ một tập dữ liệu và bộ đệm lạnh cho truy vấn đầu tiên và truy vấn chủ yếu là ràng buộc I / O, thì truy vấn thứ hai có thể hoàn thành trong giây lát. Bạn cần xem xét các hiệu ứng bộ đệm khi xử lý phân tích hiệu suất và thời gian truy vấn.

Tuy nhiên, nhiều hơn thế, nếu tôi chạy đồng thời hai truy vấn thì sao? Hai kết nối riêng biệt cùng một lúc.

"Nó phụ thuộc".

Nếu cả hai đều sử dụng quét tuần tự của cùng một bảng thì trong PostgreSQL, đó sẽ là một chiến thắng hiệu suất lớn vì hỗ trợ cho các lần quét tuần tự được đồng bộ hóa.

Nếu họ chia sẻ cùng một chỉ mục thì có khả năng họ sẽ được lợi từ việc đọc của nhau vào bộ đệm.

Nếu chúng độc lập và chạm vào các dữ liệu khác nhau thì chúng có thể cạnh tranh về băng thông I / O, trong trường hợp đó chúng có thể mất cùng thời gian như chạy liên tục. Nếu hệ thống con I / O được hưởng lợi từ sự tương tranh (thông lượng ròng cao hơn với nhiều khách hàng hơn) thì tổng thời gian có thể ít hơn. Nếu hệ thống con I / O xử lý đồng thời kém thì chúng có thể mất nhiều thời gian hơn là chạy chúng tuần tự. Hoặc chúng có thể không bị ràng buộc I / O, trong trường hợp đó nếu có CPU miễn phí cho mỗi cái thì chúng có thể thực thi tốt như thể cái kia không chạy.

Nó phụ thuộc rất nhiều vào cấu hình phần cứng và hệ thống, tập dữ liệu và vào chính các truy vấn.

Bây giờ, nếu tôi có 1.000 truy vấn không tầm thường chạy đồng thời, tôi có linh cảm rằng nó sẽ dẫn đến sự chậm lại tổng thể. Trong trường hợp đó, nút cổ chai có thể ở đâu? Bộ xử lý? RAM? Ổ đĩa?

Vâng, điều đó rất có thể sẽ làm mọi thứ chậm lại vì một số lý do.

  • Các chi phí riêng của PostgreQuery trong việc phối hợp giữa các quá trình, quản lý giao dịch và khóa, quản lý bộ đệm, v.v ... Đây có thể là một chi phí khá lớn và PostgreQuery không thực sự được thiết kế cho số lượng khách hàng cao - nó hoạt động tốt hơn nếu bạn xếp hàng làm việc .

  • Cạnh tranh cho bộ nhớ làm việc, bộ nhớ cache, vv

  • Hệ điều hành lập lịch trình trên đầu vì nó xử lý 1000 quy trình cạnh tranh tất cả các lát cắt thời gian. Khá nhỏ những ngày này, hệ điều hành hiện đại có lịch trình nhanh chóng.

  • Tôi / O đập. Hầu hết các hệ thống I / O có số lượng khách hàng hiệu suất cao nhất. Đôi khi nó là 1, tức là tốt nhất chỉ với một khách hàng, nhưng nó thường cao hơn. Đôi khi hiệu suất giảm một lần nữa trên ngưỡng. Đôi khi nó chỉ đạt đến một cao nguyên.


Đây chính xác là loại giải thích tôi đang tìm kiếm. Rõ ràng, cô đọng, nhiều thông tin. Cảm ơn!
Aaron Johnson

Xin chào @Craig Ringer, Điều gì sẽ xảy ra nếu tôi sẽ chạy đồng thời 1000 truy vấn trên một bảng (200 triệu hàng). Postgres sẽ xử lý chúng độc đáo chứ? Do quét tuần tự đồng bộ giúp?
Rahul Gautam

@RahulGautam Câu hỏi mới với chi tiết xin vui lòng, với một liên kết quay lại câu hỏi này.
Craig Ringer

@CraigRinger đã thêm. Vui lòng kiểm tra dba.stackexchange.com/questions/188649/ từ
Rahul Gautam

@RahulGautam Liên kết của bạn đã chết. Tôi tự hỏi nếu bạn có thể cung cấp một bản cập nhật về những gì đã xảy ra? Đó là một chủ đề rất thú vị.
Zeruno
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.