Berapa banyak utas yang terlalu banyak?


312

Saya menulis server, dan saya mengirim setiap tindakan ke utas terpisah ketika permintaan diterima. Saya melakukan ini karena hampir setiap permintaan membuat kueri basis data. Saya menggunakan perpustakaan threadpool untuk mengurangi pembangunan / penghancuran utas.

Pertanyaan saya adalah: apa titik cutoff yang bagus untuk utas I / O seperti ini? Saya tahu ini hanya perkiraan kasar, tetapi apakah kita berbicara ratusan? Ribuan?

Bagaimana saya mencari tahu apa yang akan terjadi dengan cutoff ini?


EDIT:

Terima kasih atas tanggapan Anda, sepertinya saya hanya perlu mengujinya untuk mengetahui batas jumlah utas saya. Pertanyaannya adalah: bagaimana saya tahu saya telah mencapai langit-langit itu? Apa tepatnya yang harus saya ukur?


1
@ryeguy: Seluruh poin di sini adalah Anda tidak boleh mengatur maksimal di threadpool jika tidak ada masalah kinerja untuk memulai. Sebagian besar saran untuk membatasi threadpool hingga ~ 100 thread adalah konyol, sebagian besar thread thread memiliki / cara / lebih banyak thread dari itu dan tidak pernah memiliki masalah.
GEOCHET

ryeguy, lihat tambahan untuk jawaban saya di bawah ini apa yang harus diukur.
paxdiablo

Jangan lupa bahwa Python pada dasarnya, tidak benar-benar multi-thread friendly. Kapan saja, opcode bytecode tunggal sedang dijalankan. Ini karena Python mempekerjakan Global Interpreter Lock.
ASK

1
@ Jay D: Saya akan mengatakan saat Anda mencapai puncaknya adalah ketika kinerja Anda mulai menurun.
ninjalj

6
@GEOCHET "Seluruh poin di sini adalah Anda seharusnya tidak mengatur maksimum di threadpool" Ummm ... katakan apa? Kolam ulir ukuran tetap memiliki manfaat degradasi dan skalabilitas yang anggun. Misalnya dalam pengaturan jaringan, jika Anda memunculkan utas baru berdasarkan koneksi klien, tanpa ukuran kumpulan tetap Anda menjalankan bahaya pembelajaran yang sebenarnya ( cara yang sulit ) berapa banyak utas yang dapat ditangani server Anda, dan setiap klien yang terhubung akan menderita. Kolam berukuran tetap berfungsi seperti katup pipa dengan melarang server Anda mencoba menggigit lebih banyak daripada yang bisa dikunyah.
b1nary.atr0phy

Jawaban:


206

Beberapa orang akan mengatakan bahwa dua utas terlalu banyak - saya tidak cukup di kamp itu :-)

Ini saran saya: ukur, jangan menebak. Satu saran adalah membuatnya dapat dikonfigurasi dan pada awalnya set ke 100, kemudian lepaskan perangkat lunak Anda ke alam liar dan pantau apa yang terjadi.

Jika penggunaan utas Anda mencapai 3, maka 100 terlalu banyak. Jika tetap di 100 untuk sebagian besar hari, menabraknya hingga 200 dan melihat apa yang terjadi.

Anda sebenarnya dapat memiliki kode Anda sendiri memantau penggunaan dan menyesuaikan konfigurasi untuk kali berikutnya dimulai tetapi itu mungkin berlebihan.


Untuk klarifikasi dan elaborasi:

Saya tidak menganjurkan menggulirkan subsistem penggabungan thread Anda sendiri, dengan cara apa pun gunakan yang Anda miliki. Tapi, karena Anda bertanya tentang titik cut-off yang baik untuk utas, saya menganggap implementasi kumpulan utas Anda memiliki kemampuan untuk membatasi jumlah maksimum utas yang dibuat (yang merupakan hal yang baik).

Saya telah menulis utas dan kode penyatuan koneksi basis data dan mereka memiliki fitur-fitur berikut (yang saya percaya sangat penting untuk kinerja):

  • jumlah minimum utas aktif.
  • jumlah maksimum utas.
  • mematikan utas yang belum digunakan untuk sementara waktu.

Yang pertama menetapkan dasar untuk kinerja minimum dalam hal klien kumpulan thread (jumlah utas ini selalu tersedia untuk digunakan). Yang kedua menetapkan batasan pada penggunaan sumber daya oleh utas aktif. Yang ketiga mengembalikan Anda ke baseline dalam waktu tenang sehingga meminimalkan penggunaan sumber daya.

Anda perlu menyeimbangkan penggunaan sumber daya memiliki utas yang tidak terpakai (A) terhadap penggunaan sumber daya karena tidak memiliki cukup utas untuk melakukan pekerjaan (B).

(A) umumnya penggunaan memori (tumpukan dan sebagainya) karena utas yang tidak bekerja tidak akan menggunakan banyak CPU. (B) umumnya akan menunda pemrosesan permintaan saat mereka tiba karena Anda perlu menunggu utas tersedia.

Itu sebabnya Anda mengukur. Saat Anda menyatakan, sebagian besar utas Anda akan menunggu tanggapan dari database sehingga tidak akan berjalan. Ada dua faktor yang memengaruhi berapa banyak utas yang harus Anda izinkan.

Yang pertama adalah jumlah koneksi DB yang tersedia. Ini mungkin merupakan batas yang sulit kecuali Anda dapat meningkatkannya di DBMS - Saya akan menganggap DBMS Anda dapat mengambil jumlah koneksi yang tidak terbatas dalam hal ini (walaupun Anda idealnya juga harus mengukurnya).

Kemudian, jumlah utas yang Anda miliki tergantung pada penggunaan historis Anda. Minimum yang harus Anda jalankan adalah angka minimum yang pernah Anda jalankan + A%, dengan minimum absolut (misalnya, dan membuatnya dapat dikonfigurasi seperti A) 5.

Jumlah utas maksimum adalah histori maksimum + B% Anda.

Anda juga harus memantau perubahan perilaku. Jika, karena alasan tertentu, penggunaan Anda mencapai 100% dari yang tersedia untuk waktu yang signifikan (sehingga akan mempengaruhi kinerja klien), Anda harus meningkatkan maksimum yang diizinkan sampai sekali lagi B% lebih tinggi.


Menanggapi "apa tepatnya yang harus saya ukur?" pertanyaan:

Apa yang harus Anda ukur secara spesifik adalah jumlah maksimum utas yang digunakan secara bersamaan (mis., Menunggu pengembalian dari panggilan DB) yang sedang dimuat. Kemudian tambahkan faktor keamanan 10% misalnya (ditekankan, karena poster lain tampaknya mengambil contoh saya sebagai rekomendasi tetap).

Selain itu, ini harus dilakukan di lingkungan produksi untuk penyetelan. Tidak apa-apa untuk mendapatkan perkiraan sebelumnya, tetapi Anda tidak pernah tahu produksi apa yang akan terjadi (itulah sebabnya semua hal ini harus dapat dikonfigurasi saat runtime). Ini untuk menangkap situasi seperti pengganda tak terduga dari panggilan klien yang masuk.


Jika utas muncul pada permintaan yang masuk maka penggunaan utas akan mencerminkan jumlah permintaan yang tidak dilayani. Tidak ada cara untuk menentukan angka "optimal" dari ini. Memang Anda akan menemukan lebih banyak utas menyebabkan lebih banyak pertentangan sumber daya dan karenanya jumlah utas aktif akan meningkat.
Andrew Grant

@Andrew, pembuatan utas membutuhkan waktu, dan Anda dapat menentukan angka optimal berdasarkan data historis [+ N%] (karenanya ukur, jangan menebak). Selain itu, lebih banyak utas hanya menyebabkan pertentangan sumber daya saat mereka sedang bekerja, tidak menunggu sinyal / semafor.
paxdiablo

Di mana data tentang 'pembuatan utas' ini menyebabkan masalah kinerja saat menggunakan kumpulan utas? Kumpulan utas yang baik tidak akan membuat dan menghancurkan utas di antara tugas.
GEOCHET

@ Max Jika semua utas Anda menunggu pada semaphores yang sama untuk menjalankan permintaan DB maka itulah definisi pertikaian. Juga tidak benar untuk mengatakan utas tidak memerlukan biaya apa pun jika mereka menunggu di semaphore.
Andrew Grant

1
@Andrew, saya tidak bisa melihat mengapa Anda semaphore-blok permintaan DB, DB yang layak akan memungkinkan akses bersamaan, dengan banyak utas menunggu tanggapan. Dan utas tidak semestinya menghabiskan waktu eksekusi saat diblokir semaphore, mereka harus duduk dalam antrian diblokir sampai semaphore dilepaskan.
paxdiablo

36

Pertanyaan ini telah dibahas dengan cukup menyeluruh dan saya tidak mendapatkan kesempatan untuk membaca semua tanggapan. Tapi di sini ada beberapa hal yang perlu dipertimbangkan sambil melihat batas atas jumlah utas simultan yang dapat hidup berdampingan secara damai dalam sistem yang diberikan.

  1. Thread Stack Size: Di Linux ukuran stack thread default adalah 8MB (Anda dapat menggunakan ulimit -a untuk menemukannya).
  2. Max Memori virtual yang didukung varian OS tertentu. Linux Kernel 2.4 mendukung ruang alamat memori 2 GB. dengan Kernel 2.6, saya sedikit lebih besar (3GB)
  3. [1] menunjukkan perhitungan untuk jumlah utas maksimum per Maks yang Didukung Maks. Untuk 2,4 ternyata sekitar 255 utas. untuk 2.6 jumlahnya sedikit lebih besar.
  4. Penjadwal kernel kindda apa yang Anda miliki. Membandingkan penjadwal kernel Linux 2.4 dengan 2.6, yang selanjutnya memberi Anda penjadwalan O (1) tanpa ketergantungan pada jumlah tugas yang ada dalam sistem sementara yang pertama lebih dari O (n). Demikian juga Kemampuan SMP dari jadwal kernel juga memainkan peran yang baik dalam jumlah maksimum utas berkelanjutan dalam suatu sistem.

Sekarang Anda dapat mengatur ukuran tumpukan Anda untuk memasukkan lebih banyak utas tetapi kemudian Anda harus memperhitungkan overhead manajemen ulir (pembuatan / penghancuran dan penjadwalan). Anda dapat menerapkan Affinity CPU ke proses yang diberikan serta ke utas yang diberikan untuk mengikatnya ke CPU tertentu untuk menghindari overhead migrasi utas antara CPU dan menghindari masalah uang tunai.

Perhatikan bahwa seseorang dapat membuat ribuan utas sesuai keinginannya, tetapi ketika Linux kehabisan VM, ia hanya secara acak mulai mematikan proses (dengan demikian utas). Ini untuk menjaga agar profil utilitas tidak dimaksimalkan. (Fungsi utilitas memberi tahu tentang utilitas sistem untuk jumlah sumber daya tertentu. Dengan sumber daya konstan dalam hal ini CPU Cycles and Memory, kurva utilitas semakin rata dengan semakin banyak tugas).

Saya yakin windows kernel scheduler juga melakukan hal semacam ini untuk mengatasi pemanfaatan sumber daya yang berlebihan

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


17

Jika utas Anda melakukan segala jenis pekerjaan intensif sumber daya (CPU / Disk) maka Anda jarang akan melihat manfaat di luar satu atau dua, dan terlalu banyak akan mematikan kinerja dengan sangat cepat.

'Kasus terbaik' adalah utas Anda nanti akan macet sementara yang pertama selesai, atau beberapa akan memiliki blok overhead rendah pada sumber daya dengan pertentangan rendah. Kasus terburuk adalah Anda mulai meronta-ronta cache / disk / jaringan dan throughput keseluruhan Anda turun melalui lantai.

Solusi yang baik adalah dengan menempatkan permintaan di kumpulan yang kemudian dikirim ke utas pekerja dari utas-utas (dan ya, menghindari terus-menerus membuat / merusak thread adalah langkah pertama yang bagus).

Jumlah utas aktif dalam kumpulan ini kemudian dapat diubah dan diskalakan berdasarkan temuan profil Anda, perangkat keras yang Anda jalankan, dan hal-hal lain yang mungkin terjadi pada mesin.


Ya, dan itu harus digunakan bersama dengan antrian atau kumpulan permintaan.
Andrew Grant

2
@Andrew: Kenapa? Itu harus menambahkan tugas ke kumpulan utas setiap kali menerima permintaan. Terserah pada kumpulan utas untuk mengalokasikan utas untuk tugas saat ada satu yang tersedia.
GEOCHET

Jadi apa yang Anda lakukan ketika ada ratusan permintaan masuk dan keluar dari utas? Buat lebih banyak? Blok? Kembalikan kesalahan? Tempatkan permintaan Anda di kumpulan yang bisa sebesar yang dibutuhkan, dan kemudian masukkan permintaan yang antri ini ke kumpulan utas Anda saat utas menjadi gratis.
Andrew Grant

"sejumlah utas dibuat untuk melakukan sejumlah tugas, yang biasanya diatur dalam antrian. Biasanya, ada lebih banyak tugas daripada utas. Begitu utas menyelesaikan tugasnya, ia akan meminta tugas berikutnya dari antrian sampai semua tugas telah selesai. "
GEOCHET

@Andrew: Saya tidak yakin apa kolam ulir python OP menggunakan, tetapi jika Anda ingin contoh dunia nyata dari fungsi ini saya jelaskan: msdn.microsoft.com/en-us/library/…
GEOCHET

10

Satu hal yang harus Anda ingat adalah bahwa python (setidaknya versi berbasis C) menggunakan apa yang disebut kunci juru bahasa global yang dapat memiliki dampak besar pada kinerja pada mesin multi-core.

Jika Anda benar-benar membutuhkan python multithreaded maksimal, Anda mungkin ingin mempertimbangkan untuk menggunakan Jython atau sesuatu.


4
Setelah membaca ini, saya mencoba menjalankan tugas saringan Eratosthenes pada tiga utas. Benar saja, itu sebenarnya 50% lebih lambat daripada menjalankan tugas yang sama dalam satu utas. Terimakasih atas peringatannya. Saya menjalankan Eclipse Pydev pada mesin virtual yang dialokasikan dua CPU. Selanjutnya, saya akan mencoba skenario yang melibatkan beberapa panggilan basis data.
Don Kirkby

3
Ada dua (setidaknya) jenis tugas: Ikatan CPU (mis. Pemrosesan gambar) dan I / O terikat (misalnya mengunduh dari jaringan). Jelas, "masalah" GIL tidak akan terlalu mempengaruhi tugas terikat I / O. Jika tugas Anda terikat dengan CPU maka Anda harus mempertimbangkan multiprosesing daripada multithreading.
iutinvg

1
ya, python thread telah meningkat jika Anda memiliki banyak jaringan io.I mengubahnya menjadi thread dan mendapat 10 * lebih cepat dari kode biasa ...
tyan

8

Seperti yang dikatakan Pax dengan benar, ukurlah, jangan menebak . Apa yang saya lakukan untuk DNSwitness dan hasilnya mengejutkan: jumlah utas yang ideal jauh lebih tinggi dari yang saya kira, kira-kira 15.000 utas untuk mendapatkan hasil tercepat.

Tentu saja, itu tergantung pada banyak hal, itu sebabnya Anda harus mengukur diri sendiri.

Tindakan lengkap (hanya dalam bahasa Prancis) di Combien de fils d'exécution? .


1
15.000? Itu sedikit lebih tinggi dari yang saya harapkan juga. Namun, jika itu yang Anda dapatkan, maka itulah yang Anda dapatkan, saya tidak bisa membantahnya.
paxdiablo

2
Untuk aplikasi spesifik ini, sebagian utas hanya menunggu respons dari server DNS. Jadi, semakin paralelisme, semakin baik, dalam waktu jam dinding.
bortzmeyer

18
Saya berpikir bahwa jika Anda memiliki 15.000 utas yang memblokir pada beberapa I / O eksternal maka solusi yang lebih baik akan menjadi untaian yang jauh lebih sedikit tetapi dengan model asinkron. Saya berbicara dari pengalaman di sini.
Steve

5

Saya telah menulis sejumlah aplikasi multi-utas. Saya biasanya mengizinkan jumlah utas potensial untuk ditentukan oleh file konfigurasi. Ketika saya telah mencari pelanggan tertentu, saya telah menetapkan angka yang cukup tinggi sehingga pemanfaatan semua core CPU saya cukup tinggi, tetapi tidak terlalu tinggi sehingga saya mengalami masalah memori (ini adalah sistem operasi 32-bit di waktu).

Dengan kata lain, sekali Anda mencapai beberapa hambatan baik itu CPU, throughput database, disk throughput, dll, menambahkan lebih banyak utas tidak akan meningkatkan kinerja keseluruhan. Tetapi sampai Anda mencapai titik itu, tambahkan lebih banyak utas!

Perhatikan bahwa ini mengasumsikan sistem yang dipermasalahkan didedikasikan untuk aplikasi Anda, dan Anda tidak harus bermain dengan baik (menghindari kelaparan) aplikasi lain.


1
Bisakah Anda menyebutkan beberapa angka yang Anda lihat untuk hitungan utas? Akan sangat membantu jika bisa merasakannya. Terima kasih.
kovac

3

Jawaban "big iron" umumnya adalah satu utas per sumber daya terbatas - prosesor (terikat CPU), lengan (terikat I / O), dll - tetapi itu hanya berfungsi jika Anda bisa merutekan pekerjaan ke utas yang benar untuk sumber daya. diakses.

Di mana itu tidak mungkin, pertimbangkan bahwa Anda memiliki sumber daya yang dapat dipertukarkan (CPU) dan sumber daya yang tidak dapat dipertukarkan (senjata). Untuk CPU itu tidak penting untuk menetapkan setiap utas ke CPU tertentu (meskipun itu membantu dengan manajemen cache), tetapi untuk lengan, jika Anda tidak dapat menetapkan utas ke lengan, Anda masuk ke teori antrian dan berapa jumlah optimal untuk menyimpan senjata sibuk. Secara umum saya berpikir bahwa jika Anda tidak dapat merutekan permintaan berdasarkan lengan yang digunakan, maka memiliki 2-3 benang per lengan akan menjadi benar.

Komplikasi muncul ketika unit kerja yang diteruskan ke thread tidak mengeksekusi unit kerja yang cukup atom. Misalnya, Anda mungkin memiliki utas di satu titik mengakses disk, di titik lain menunggu di jaringan. Ini meningkatkan jumlah "celah" di mana utas tambahan dapat masuk dan melakukan pekerjaan yang bermanfaat, tetapi juga meningkatkan peluang utas tambahan untuk mencemari cache masing-masing, dll, dan meredam sistem.

Tentu saja, Anda harus menimbang semua ini terhadap "bobot" utas. Sayangnya, sebagian besar sistem memiliki utas kelas berat (dan apa yang mereka sebut "utas ringan" seringkali bukan utas sama sekali), jadi lebih baik untuk melakukan kesalahan pada sisi yang rendah.

Apa yang saya lihat dalam praktik adalah bahwa perbedaan yang sangat halus dapat membuat perbedaan besar dalam berapa banyak utas yang optimal. Secara khusus, masalah cache dan konflik kunci dapat sangat membatasi jumlah konkurensi praktis.


2

Satu hal yang perlu dipertimbangkan adalah berapa banyak core yang ada pada mesin yang akan mengeksekusi kode. Itu merupakan batasan keras tentang berapa banyak utas yang dapat diproses pada waktu tertentu. Namun, jika, seperti dalam kasus Anda, utas diharapkan sering menunggu basis data untuk mengeksekusi kueri, Anda mungkin ingin menyetel utas Anda berdasarkan pada berapa banyak kueri bersamaan yang bisa diproses oleh basis data.


2
um, tidak. Inti dari semua thread adalah (sebelum multicore dan banyak prosesor menjadi lazim) adalah untuk dapat meniru memiliki banyak prosesor pada mesin yang hanya memiliki satu. Itulah cara Anda mendapatkan antarmuka pengguna yang responsif - utas utama dan utas tambahan.
mmr

1
@ mmr: Um no. Ide utas adalah memungkinkan pemblokiran I / O dan tugas lainnya.
GEOCHET

4
Pernyataan yang saya buat adalah bahwa jumlah inti pada mesin mewakili batas keras pada jumlah utas yang dapat melakukan pekerjaan pada waktu tertentu, yang merupakan fakta. Tentu saja utas lainnya dapat menunggu pada operasi I / O untuk menyelesaikan, dan untuk pertanyaan ini yang merupakan pertimbangan penting.
newdayrising

1
Pokoknya - Anda memiliki GIL dalam Python, yang membuat utas hanya sejajar secara teoritis. Tidak lebih dari 1 utas yang dapat berjalan secara bersamaan, jadi hanya responsif dan pemblokiran operasi yang penting.
Abgan

2
+1 Untuk benar-benar memahami cara kerja komputer. @ mmr: Anda perlu memahami perbedaan antara tampaknya memiliki beberapa prosesor, dan memang memiliki banyak prosesor. @ Rich B: Kumpulan utas hanyalah salah satu dari banyak cara untuk menangani koleksi utas. Ini bagus, tapi tentu saja bukan satu-satunya.
berduka

2

Saya pikir ini sedikit menghindar dari pertanyaan Anda, tetapi mengapa tidak memasukkannya ke dalam proses? Pemahaman saya tentang jaringan (dari masa lalu yang kabur, saya tidak benar-benar membuat kode jaringan sama sekali) adalah bahwa setiap koneksi yang masuk dapat ditangani sebagai proses yang terpisah, karena jika seseorang melakukan sesuatu yang buruk dalam proses Anda, itu tidak nuke seluruh program.


1
Untuk Python itu terutama benar, karena beberapa proses dapat berjalan secara paralel, sementara banyak utas - tidak. Namun biayanya cukup tinggi. Anda harus memulai juru bahasa Python baru setiap kali, dan terhubung ke DB dengan setiap proses (atau menggunakan beberapa pengalihan pipa, tetapi juga ada harganya).
Abgan

Beralih di antara proses - sebagian besar waktu - lebih mahal daripada beralih di antara utas (seluruh konteks alih-alih beberapa register). Pada akhirnya itu sangat tergantung pada lib threading Anda. Ketika pertanyaan berputar di sekitar threading, saya berasumsi bahwa proses sudah keluar dari pertanyaan.
Leonidas

Cukup adil. Saya tidak yakin mengapa itu sebabnya saya mendapatkan skor -2 untuk skor, kecuali jika orang benar-benar ingin melihat jawaban hanya utas, daripada memasukkan jawaban lain yang berfungsi.
mmr

@ mmr: Mengingat pertanyaannya adalah tentang / utas / kumpulan, ya, saya pikir orang-orang harus mengharapkan jawaban tentang utas.
GEOCHET

Pembuatan proses dapat dilakukan sekali saat startup (yaitu, kumpulan proses alih-alih kumpulan utas). Amortisasi selama durasi aplikasi, ini mungkin kecil. Mereka tidak dapat berbagi informasi dengan mudah tetapi TIDAK MEMBELI mereka kemungkinan menjalankan multi-CPU jadi jawaban ini berguna. +1.
paxdiablo

1

ryeguy, saat ini saya sedang mengembangkan aplikasi yang serupa dan nomor utas saya diatur ke 15. Sayangnya jika saya menambahnya pada 20, itu crash. Jadi, ya, saya pikir cara terbaik untuk menangani ini adalah mengukur apakah konfigurasi Anda saat ini memungkinkan lebih atau kurang dari sejumlah X utas.


5
Menambahkan ke jumlah utas Anda seharusnya tidak membuat crash aplikasi Anda secara acak. Ada beberapa alasan. Anda sebaiknya mengetahui penyebabnya karena hal itu dapat mempengaruhi Anda bahkan dengan sedikit utas dalam beberapa keadaan, siapa tahu.
Matthew Lund

-6

Dalam kebanyakan kasus, Anda harus mengizinkan kumpulan utas untuk menangani ini. Jika Anda memposting beberapa kode atau memberikan rincian lebih lanjut, mungkin lebih mudah untuk melihat apakah ada beberapa alasan perilaku default dari kumpulan thread tidak akan menjadi yang terbaik.

Anda dapat menemukan informasi lebih lanjut tentang bagaimana ini seharusnya bekerja di sini: http://en.wikipedia.org/wiki/Thread_pool_pattern


1
@ Max: Ini bukan pertama kalinya mayoritas orang tidak mau menjawab pertanyaan yang ada (atau memahaminya). Saya tidak khawatir.
GEOCHET

-10

Sebanyak thread sebagai inti CPU adalah apa yang saya dengar sangat sering.


5
@ Rich, setidaknya jelaskan alasannya :-). Aturan praktis ini hanya berlaku ketika semua utas terikat CPU; mereka mendapatkan satu 'CPU' masing-masing. Ketika banyak utas terikat I / O, biasanya lebih baik memiliki lebih banyak utas daripada 'CPU' (CPU dikutip karena ini berlaku pada utas fisik eksekusi, mis. Inti).
paxdiablo

1
@Abgan, saya tidak yakin tentang itu, berpikir mungkin Python akan membuat utas OS "nyata" (dijalankan pada banyak CPU). Jika apa yang Anda katakan itu benar (saya tidak punya alasan untuk meragukan), maka kuantitas CPU tidak memiliki kaitan - threading berguna maka hanya ketika sebagian besar thread sedang menunggu sesuatu (mis. DB I / O).
paxdiablo

1
@ Kaya: ketika (nyata) threading, jumlah CPU TIDAK berpengaruh karena Anda dapat menjalankan beberapa utas yang tidak menunggu secara bersamaan. Dengan satu CPU, hanya satu yang berjalan dan manfaatnya bertambah karena memiliki banyak utas lain yang menunggu sumber daya non-CPU.
paxdiablo

1
@ Max: Anda tidak mengerti konsep thread pools maka saya kira.
GEOCHET

1
@ Rich, saya mengerti kolam thread baik-baik saja; tampaknya saya (dan yang lainnya di sini) juga memahami perangkat keras lebih baik daripada Anda. Dengan satu CPU, hanya satu utas eksekusi yang dapat berjalan, bahkan jika ada yang lain menunggu CPU. Dua CPU, dua bisa dijalankan. IFF semua thread sedang menunggu CPU, ideal thread count sama dengan ...
paxdiablo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.