Có bao nhiêu chủ đề là quá nhiều?

Tôi đang viết một máy chủ và tôi gửi từng hành động vào một luồng riêng khi nhận được yêu cầu. Tôi làm điều này bởi vì hầu hết mọi yêu cầu tạo ra một truy vấn cơ sở dữ liệu. Tôi đang sử dụng một thư viện threadpool để cắt giảm việc xây dựng / phá hủy các chủ đề.

Câu hỏi của tôi là: điểm cắt tốt cho các luồng I / O như thế này là gì? Tôi biết đó chỉ là một ước tính sơ bộ, nhưng chúng ta đang nói chuyện hàng trăm? Hàng ngàn?

Làm thế nào tôi có thể tìm ra điểm cắt này sẽ là gì?

BIÊN TẬP:

Cảm ơn tất cả các câu trả lời của bạn, có vẻ như tôi sẽ phải kiểm tra nó để tìm ra trần nhà của tôi. Câu hỏi là: làm sao tôi biết tôi đã chạm trần? Chính xác những gì tôi nên đo?

Một số người sẽ nói rằng hai chủ đề là quá nhiều - Tôi không hoàn toàn ở trong trại đó :-)

Đây là lời khuyên của tôi: đo lường, đừng đoán. Một đề xuất là làm cho nó có thể cấu hình được và ban đầu đặt nó thành 100, sau đó phát hành phần mềm của bạn ra ngoài và theo dõi những gì xảy ra.

Nếu mức sử dụng luồng của bạn đạt cực đại ở mức 3, thì 100 là quá nhiều. Nếu nó vẫn ở mức 100 trong hầu hết thời gian trong ngày, hãy nâng nó lên tới 200 và xem điều gì sẽ xảy ra.

Bạn thực sự có thể có mã của mình theo dõi việc sử dụng và điều chỉnh cấu hình cho lần khởi động tiếp theo nhưng điều đó có thể là quá mức cần thiết.

Để làm rõ và xây dựng:

Tôi không ủng hộ việc lăn hệ thống con tổng hợp luồng của riêng bạn, bằng mọi cách sử dụng cái bạn có. Nhưng, vì bạn đã hỏi về một điểm giới hạn tốt cho các luồng, tôi cho rằng việc triển khai nhóm luồng của bạn có khả năng giới hạn số lượng luồng tối đa được tạo (đó là một điều tốt).

Tôi đã viết mã tổng hợp kết nối cơ sở dữ liệu và kết nối cơ sở dữ liệu và chúng có các tính năng sau (mà tôi tin là cần thiết cho hiệu suất):

• một số lượng tối thiểu của các chủ đề hoạt động.
• số lượng chủ đề tối đa.
• tắt các chủ đề đã không được sử dụng trong một thời gian.

Cái đầu tiên đặt đường cơ sở cho hiệu suất tối thiểu về mặt máy khách nhóm luồng (số lượng luồng này luôn có sẵn để sử dụng). Thứ hai đặt ra một hạn chế về việc sử dụng tài nguyên bởi các luồng hoạt động. Thứ ba đưa bạn trở lại đường cơ sở trong thời gian yên tĩnh để giảm thiểu việc sử dụng tài nguyên.

Bạn cần cân bằng việc sử dụng tài nguyên khi có các luồng không sử dụng (A) so với việc sử dụng tài nguyên không có đủ luồng để thực hiện công việc (B).

(A) nói chung là sử dụng bộ nhớ (ngăn xếp, v.v.) vì một luồng không hoạt động sẽ không sử dụng nhiều CPU. (B) nói chung sẽ là một sự chậm trễ trong việc xử lý các yêu cầu khi chúng đến khi bạn cần đợi một chuỗi có sẵn.

Đó là lý do tại sao bạn đo lường. Như bạn nêu, phần lớn các chủ đề của bạn sẽ chờ phản hồi từ cơ sở dữ liệu để chúng không chạy. Có hai yếu tố ảnh hưởng đến số lượng chủ đề bạn nên cho phép.

Đầu tiên là số lượng kết nối DB có sẵn. Đây có thể là một giới hạn cứng trừ khi bạn có thể tăng nó tại DBMS - Tôi sẽ giả định rằng DBMS của bạn có thể có số lượng kết nối không giới hạn trong trường hợp này (mặc dù bạn cũng nên đo lường điều đó).

Sau đó, số lượng chủ đề bạn nên có phụ thuộc vào sử dụng lịch sử của bạn. Mức tối thiểu bạn nên chạy là số lượng tối thiểu bạn từng chạy + A%, với mức tối thiểu tuyệt đối (ví dụ: và làm cho nó có thể định cấu hình giống như A) 5.

Số lượng chủ đề tối đa phải là tối đa lịch sử của bạn + B%.

Bạn cũng nên theo dõi để thay đổi hành vi. Nếu, vì một số lý do, việc sử dụng của bạn đạt 100% khả dụng trong một thời gian đáng kể (để nó ảnh hưởng đến hiệu suất của khách hàng), bạn nên tăng tối đa cho phép cho đến khi cao hơn B% một lần nữa.

Để đáp lại "chính xác những gì tôi nên đo?" câu hỏi:

Những gì bạn nên đo cụ thể là số lượng luồng tối đa được sử dụng đồng thời (ví dụ, chờ đợi khi trả về từ cuộc gọi DB) trong khi tải. Sau đó, thêm hệ số an toàn 10% chẳng hạn (nhấn mạnh, vì các áp phích khác dường như lấy ví dụ của tôi làm đề xuất cố định).

Ngoài ra, điều này nên được thực hiện trong môi trường sản xuất để điều chỉnh. Bạn có thể ước tính trước được nhưng bạn không bao giờ biết sản xuất nào sẽ theo cách của bạn (đó là lý do tại sao tất cả những thứ này nên được cấu hình trong thời gian chạy). Điều này là để nắm bắt một tình huống như nhân đôi các cuộc gọi của khách hàng đến bất ngờ.

Câu hỏi này đã được thảo luận khá kỹ lưỡng và tôi không có cơ hội đọc tất cả các câu trả lời. Nhưng đây là một vài điều cần xem xét trong khi xem xét giới hạn trên về số lượng các luồng đồng thời có thể cùng tồn tại trong một hệ thống nhất định.

1. Kích thước ngăn xếp luồng: Trong Linux, kích thước ngăn xếp luồng mặc định là 8 MB (bạn có thể sử dụng ulimit -a để tìm ra nó).
2. Bộ nhớ ảo tối đa mà một biến thể HĐH đã cho hỗ trợ. Linux Kernel 2.4 hỗ trợ không gian địa chỉ bộ nhớ là 2 GB. với Kernel 2.6, tôi lớn hơn một chút (3GB)
3. [1] hiển thị các tính toán cho số lượng luồng tối đa trên mỗi VM tối đa được hỗ trợ. Đối với 2.4, hóa ra là khoảng 255 chủ đề. cho 2,6 số lượng lớn hơn một chút.
4. Bạn có lịch trình kernel kindda nào. So sánh bộ lập lịch kernel Linux 2.4 với 2.6, cái sau cung cấp cho bạn một lịch trình O (1) mà không phụ thuộc vào số lượng tác vụ hiện có trong một hệ thống trong khi cái đầu tiên là nhiều hơn O (n). Do đó, Khả năng SMP của lịch trình kernel cũng đóng một vai trò tốt trong số lượng tối đa các luồng bền vững trong một hệ thống.

Bây giờ bạn có thể điều chỉnh kích thước ngăn xếp của mình để kết hợp nhiều luồng hơn nhưng sau đó bạn phải tính đến các chi phí quản lý luồng (tạo / hủy và lập lịch). Bạn có thể thực thi ái lực của CPU đối với một quy trình nhất định cũng như với một luồng đã cho để buộc chúng xuống các CPU cụ thể để tránh các chi phí di chuyển luồng giữa các CPU và tránh các vấn đề về tiền mặt lạnh.

Lưu ý rằng người ta có thể tạo ra hàng ngàn luồng theo ý muốn của mình, nhưng khi Linux hết VM, nó chỉ ngẫu nhiên bắt đầu giết các tiến trình (do đó là các luồng). Điều này là để giữ cho hồ sơ tiện ích không bị tối đa. (Hàm tiện ích cho biết về tiện ích toàn hệ thống đối với một lượng tài nguyên nhất định. Với tài nguyên không đổi trong trường hợp này là CPU Chu kỳ và Bộ nhớ, đường cong tiện ích sẽ làm phẳng với số lượng tác vụ ngày càng nhiều).

Tôi chắc chắn trình lập lịch trình kernel kernel cũng làm một cái gì đó thuộc loại này để xử lý việc sử dụng quá mức các tài nguyên

[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/

Nếu các luồng của bạn đang thực hiện bất kỳ loại công việc đòi hỏi nhiều tài nguyên (CPU / Đĩa) thì bạn sẽ hiếm khi thấy lợi ích vượt quá một hoặc hai và quá nhiều sẽ giết chết hiệu suất rất nhanh.

'Trường hợp tốt nhất' là các chủ đề sau này của bạn sẽ bị đình trệ trong khi các chủ đề đầu tiên hoàn thành hoặc một số sẽ có các khối chi phí thấp trên các tài nguyên với sự tranh chấp thấp. Trường hợp xấu nhất là bạn bắt đầu đập bộ đệm / đĩa / mạng và thông lượng tổng thể của bạn giảm xuống sàn.

Một giải pháp tốt là đặt các yêu cầu trong một nhóm sau đó được gửi đến các luồng công nhân từ một nhóm luồng (và vâng, tránh việc tạo / hủy luồng liên tục là bước đầu tiên tuyệt vời).

Số lượng luồng hoạt động trong nhóm này sau đó có thể được điều chỉnh và thu nhỏ dựa trên những phát hiện về hồ sơ của bạn, phần cứng bạn đang chạy và những thứ khác có thể xảy ra trên máy.

Một điều bạn nên nhớ là python (ít nhất là phiên bản dựa trên C) sử dụng cái được gọi là khóa phiên dịch toàn cầu có thể ảnh hưởng rất lớn đến hiệu suất trên các máy đa lõi.

Nếu bạn thực sự cần nhiều nhất về con trăn đa luồng, bạn có thể muốn xem xét sử dụng Jython hoặc một cái gì đó.

Như Pax đã nói đúng, đo lường, đừng đoán . Đó là những gì tôi đã làm cho DNSwitness và kết quả thật đáng kinh ngạc: số lượng chủ đề lý tưởng cao hơn nhiều so với tôi nghĩ, khoảng 15.000 chủ đề để có kết quả nhanh nhất.

Tất nhiên, nó phụ thuộc vào nhiều thứ, đó là lý do tại sao bạn phải tự đo lường.

Các biện pháp hoàn chỉnh (chỉ bằng tiếng Pháp) trong Combien de fils d'exécutions? .

Tôi đã viết một số ứng dụng đa luồng. Tôi thường cho phép số lượng chủ đề tiềm năng được chỉ định bởi một tệp cấu hình. Khi tôi điều chỉnh cho các khách hàng cụ thể, tôi đã đặt số lượng đủ cao để mức độ sử dụng tất cả các lõi CPU của tôi khá cao, nhưng không cao đến mức tôi gặp phải các vấn đề về bộ nhớ (đây là các hệ điều hành 32 bit tại thời gian).

Nói cách khác, một khi bạn gặp phải một số tắc nghẽn có thể là CPU, thông lượng cơ sở dữ liệu, thông lượng đĩa, v.v., việc thêm nhiều luồng sẽ không làm tăng hiệu suất tổng thể. Nhưng cho đến khi bạn đạt được điểm đó, thêm chủ đề!

Lưu ý rằng điều này giả định (các) hệ thống được đề cập là dành riêng cho ứng dụng của bạn và bạn không phải chơi độc đáo (tránh bỏ đói) các ứng dụng khác.

Câu trả lời "cục sắt lớn" nói chung là một luồng cho mỗi tài nguyên giới hạn - bộ xử lý (bị ràng buộc CPU), nhánh (ràng buộc I / O), v.v. - nhưng chỉ hoạt động nếu bạn có thể định tuyến công việc đến đúng luồng cho tài nguyên được truy cập.

Nếu điều đó là không thể, hãy xem xét rằng bạn có tài nguyên có thể bị nhiễm (CPU) và tài nguyên không bị nhiễm nấm (vũ khí). Đối với CPU, việc gán từng luồng cho một CPU cụ thể là không quan trọng (mặc dù nó giúp quản lý bộ đệm), nhưng đối với vũ khí, nếu bạn không thể gán một luồng cho cánh tay, bạn sẽ vào lý thuyết xếp hàng và số tối ưu để giữ vũ khí bận. Nói chung, tôi nghĩ rằng nếu bạn không thể định tuyến các yêu cầu dựa trên cánh tay được sử dụng, thì có 2-3 luồng trên mỗi cánh tay sẽ là điều đúng đắn.

Một sự phức tạp xảy ra khi đơn vị công việc được chuyển đến luồng không thực hiện một đơn vị công việc nguyên tử hợp lý. Ví dụ, bạn có thể có luồng tại một điểm truy cập vào đĩa, tại một điểm khác chờ trên mạng. Điều này làm tăng số lượng "vết nứt" nơi các luồng bổ sung có thể xâm nhập và thực hiện công việc hữu ích, nhưng nó cũng làm tăng cơ hội cho các luồng bổ sung gây ô nhiễm cho bộ nhớ cache của nhau, v.v. và làm hỏng hệ thống.

Tất nhiên, bạn phải cân nhắc tất cả điều này với "trọng lượng" của một sợi. Thật không may, hầu hết các hệ thống đều có các luồng rất nặng (và cái mà chúng gọi là "các luồng nhẹ" thường không phải là các luồng), vì vậy tốt hơn là nên sai ở phía thấp.

Những gì tôi đã thấy trong thực tế là sự khác biệt rất tinh tế có thể tạo ra sự khác biệt to lớn trong việc có bao nhiêu chủ đề là tối ưu. Cụ thể, các vấn đề về bộ đệm và xung đột khóa có thể hạn chế rất nhiều lượng đồng thời thực tế.

Một điều cần xem xét là có bao nhiêu lõi tồn tại trên máy sẽ thực thi mã. Điều đó thể hiện giới hạn cứng về số lượng luồng có thể được tiến hành tại bất kỳ thời điểm nào. Tuy nhiên, nếu trong trường hợp của bạn, các luồng được dự kiến ​​sẽ thường xuyên chờ cơ sở dữ liệu thực hiện truy vấn, bạn có thể muốn điều chỉnh các luồng của mình dựa trên số lượng truy vấn đồng thời mà cơ sở dữ liệu có thể xử lý.

Tôi nghĩ rằng đây là một chút né tránh câu hỏi của bạn, nhưng tại sao không chia chúng thành các quy trình? Sự hiểu biết của tôi về kết nối mạng (từ những ngày mờ ám, tôi hoàn toàn không mã mạng) là mỗi kết nối đến có thể được xử lý như một quy trình riêng biệt, bởi vì nếu ai đó làm điều gì đó khó chịu trong quy trình của bạn, thì không nuke toàn bộ chương trình.

ryeguy, tôi hiện đang phát triển một ứng dụng tương tự và số chủ đề của tôi được đặt thành 15. Thật không may nếu tôi tăng nó ở mức 20 thì nó bị hỏng. Vì vậy, vâng, tôi nghĩ cách tốt nhất để xử lý việc này là đo xem cấu hình hiện tại của bạn có cho phép nhiều hay ít hơn một số X của các luồng hay không.

Trong hầu hết các trường hợp, bạn nên cho phép nhóm luồng xử lý việc này. Nếu bạn đăng một số mã hoặc cung cấp thêm chi tiết, có thể dễ dàng hơn để xem liệu có lý do nào đó hành vi mặc định của nhóm luồng sẽ không tốt nhất.

Bạn có thể tìm thêm thông tin về cách thức hoạt động của nó ở đây: http://en.wikipedia.org/wiki/Thread_pool_potype

Nhiều luồng như lõi CPU là những gì tôi đã nghe rất thường xuyên.