Adakah Nginx menggunakan multi-threading secara dalaman?

Question

Nginx membahagikan pemprosesan permintaan kepada beberapa fasa. Adakah terdapat sekatan IO semasa peringkat ini? Sekiranya terdapat penyekatan, Nginx akan melaksanakan permintaan lain, tetapi adakah terdapat perbezaan keutamaan apabila melaksanakan permintaan lain (adakah permintaan yang telah berkembang ke peringkat seterusnya akan dilaksanakan terlebih dahulu?)? Juga, adakah Nginx mempunyai kumpulan benang untuk memprosesnya pada setiap peringkat, atau adakah ia akan mempunyai benang sendiri dari awal hingga akhir?

Answer 1

cat /proc/3776/status|grep Threads Dapat dilihat bahawa proses pekerja Nginx hanya mempunyai 1 utas, di mana 3776 adalah PID proses pekerja Nginx. Di samping itu, Nginx telah menambah sokongan kumpulan benang AIO daripada 1.7.11, dan boleh menggunakan berbilang benang AIO untuk membaca dan menghantar fail besar untuk menghalang proses pekerja daripada disekat (gunakan fail hantar untuk fail kecil, dan kumpulan benang AIO untuk fail besar ). Untuk mendayakan sokongan kumpulan benang, Anda perlu menambah pilihan --dengan-benang secara eksplisit semasa mengkonfigurasi.
https://www.nginx.com/blog/thread-pools-boost-performance-9x/
http://nginx.org/en/docs/ngx_core_module.html#thread_pool

Transfer:
Apabila listen_fd mempunyai permintaan accept() baharu, sistem pengendalian akan membangunkan semua proses anak, kerana proses ini semua epoll_wait() listen_fd yang sama, dan sistem pengendalian tidak mempunyai cara untuk menilai siapa yang bertanggungjawab untuk menerima, jadi ia hanya membangkitkan mereka semua, tetapi pada akhirnya hanya satu proses yang akan berjaya menerima, dan proses lain akan gagal untuk menerima Semua proses kanak-kanak "terjaga", jadi ia dipanggil Thundering Herd.

Soket pendengaran dimulakan pada permulaan Proses pekerja menerima, membaca permintaan dan mengeluarkan respons melalui soket ini Nginx tidak menggunakan proses induk untuk mengedarkan permintaan seperti PHP-FPM , jadi ia boleh menyebabkan fenomena panik, iaitu, apabila listen_fd mempunyai permintaan accept() baharu, sistem pengendalian akan membangunkan semua proses kanak-kanak.

Idea Nginx untuk menyelesaikan kumpulan gemuruh: elakkan kumpulan gemuruh
http://nginx.org/en/docs/ngx_core_module.html#accept_mutex
Langkah khusus termasuk menggunakan kunci mutex global (accept_mutex on) dan setiap satu. proses pekerja dalam epoll_wait () sebelum memohon kunci, teruskan pemprosesan jika permohonan diperoleh, dan tunggu jika ia tidak dapat diperoleh, dan sediakan algoritma pengimbangan beban (apabila volum tugas proses kerja tertentu mencapai 7/8 daripada jumlah volum yang ditetapkan, ia tidak akan Cuba memohon kunci sekali lagi) untuk mengimbangi beban kerja setiap proses.

Cara baharu Nginx untuk menyelesaikan masalah kumpulan bergemuruh: gunakan fungsi Socket ReusePort yang disediakan oleh kernel
NGINX 1.9.1 menyokong soket sharding:
http://nglua.com/docs/sharding.html
NGINX1.9.1 menyokong SO_REUSEPORT pilihan soket, Pilihan ini tersedia dalam versi yang lebih baru bagi banyak sistem pengendalian, termasuk DragonFly BSD dan Linux (3.9+ kernel Pilihan ini membenarkan berbilang soket untuk mendengar pada alamat IP dan kombinasi port yang sama ke soket ini. Pemecahan yang berkesan Apabila pilihan SO_REUSEPORT tidak dihidupkan, soket mendengar akan memberitahu proses secara lalai apabila sambungan masuk. Jika arahan accept_mutex off akan membangunkan semua proses pekerja pada masa ini, mereka akan bersaing. untuk mendapatkannya. Inilah yang dipanggil fenomena gerombolan Thundering Jika anda menggunakan epoll tanpa mengunci (accept_mutex off), apabila terdapat operasi baca pada port mendengar, fenomena gerombolan gemuruh akan berlaku selepas membolehkan pilihan SO_REUSEPORT mempunyai soket pendengaran bebasnya sendiri. Kernel menentukan mana-mana soket (proses) yang sah mendapat sambungan Ini mengurangkan kependaman dan meningkatkan prestasi proses pekerja, ini juga bermakna proses pekerja diberi sambungan baru sebelum mereka bersedia untuk mengendalikannya

nginx berfungsi dalam mod berbilang proses secara lalai, dengan satu proses induk dan berbilang proses pekerja. Proses induk digunakan terutamanya untuk menguruskan proses pekerja berbilang bersaing untuk permintaan daripada pelanggan. tetapi tidak boleh Memproses permintaan daripada proses pekerja lain Hanya terdapat satu utas utama dalam setiap proses pekerja Dengan sokongan epoll, ia menggunakan kaedah bukan penyekat tak segerak untuk memproses permintaan untuk mencapai sokongan epoll yang tinggi (socket polling ). Apabila acara belum siap, letakkannya dalam epoll Apabila acara sudah siap, baca dan tulis Berbanding dengan multi-threading, kaedah pemprosesan acara ini mempunyai kelebihan yang besar Terdapat juga sedikit memori, tiada penukaran konteks, dan pemprosesan acara sangat ringan Tidak kira berapa banyak mata wang yang ada, ia tidak akan membawa kepada pembaziran sumber yang tidak perlu (Penukaran konteks hanya akan mengambil lebih banyak memori Kaedah kerja biasa httpd ialah setiap permintaan akan menduduki benang yang berfungsi Apabila bilangan concurrency mencapai ribuan, akan terdapat beribu-ribu permintaan memproses pada masa yang sama Ini adalah satu cabaran besar untuk sistem pengendalian disebabkan oleh ini adalah sangat besar, dan overhed CPU yang disebabkan oleh penukaran konteks benang adalah sangat besar, prestasi httpd tidak boleh dipertingkatkan sebelum ini pada mesin dengan memori 24G, mengendalikan Nginx Bilangan permintaan serentak telah mencecah lebih daripada 2 juta (Secara purata, memori 1G boleh mengendalikan lebih daripada 80,000 permintaan.) Nginx menyokong pengikatan proses tertentu ke teras tertentu (pengikatan pertalian CPU), supaya tidak akan timbul masalah. untuk memproses pensuisan. Untuk mengelakkan kegagalan cache, adalah disyorkan untuk menyediakan beberapa proses pekerja mengikut bilangan teras dalam CPU Walau bagaimanapun, ambil perhatian bahawa terlalu banyak proses pekerja hanya akan menyebabkan proses bersaing untuk sumber CPU, sekali gus menyebabkan konteks yang tidak perlu pertukaran. Oleh itu, pekerja memproses Lebih banyak proses, lebih baik, lihat:
http://tengine.taobao.org/book/chapter_02.html

.