🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜 🎜🎜Konkurensi tinggi dan responsif Pantas sepadan dengan dua petunjuk teras pengoptimuman prestasi: 🎜Throughput🎜 dan 🎜Latensi🎜🎜Pictures dari: www.ctq6.cn
application loadangle: Secara langsung mempengaruhi pengalaman pengguna produk terminal
system produk: penggunaan sumber, ketepuan, dan lain -lain.
Intipati masalah prestasi
ialah sumber sistem telah mencapai kesesakan, tetapi pemprosesan permintaan tidak cukup pantas untuk menyokong lebih banyak permintaan. Analisis prestasi sebenarnya adalah untuk mencari kesesakan aplikasi atau sistem dan cuba mengelakkan atau mengurangkannya.
Pilih metrik untuk menilai prestasi aplikasi dan sistem
Tetapkan matlamat prestasi untuk aplikasi dan sistem
Lakukan penanda aras prestasi
Analisis prestasi
Analisis prestasi dan amaran untuk mencari
Pilih alat analisis prestasi yang berbeza untuk masalah prestasi yang berbeza. Berikut ialah Alat Prestasi Linux yang biasa digunakan dan jenis masalah prestasi yang sepadan dianalisis.
. ialah purata bilangan proses aktif. Ia tidak berkaitan secara langsung dengan penggunaan CPU seperti yang kita fahami secara tradisional. Proses tidak terganggu ialah proses yang berada dalam proses kritikal dalam keadaan kernel (seperti tindak balas I/O biasa menunggu peranti). Keadaan tidak terganggu sebenarnya adalah mekanisme perlindungan sistem untuk proses dan peranti perkakasan.
Apakah purata beban yang munasabah Dalam persekitaran pengeluaran sebenar, pantau purata beban sistem dan nilaikan aliran perubahan beban berdasarkan data sejarah. Apabila terdapat aliran menaik yang jelas dalam beban, jalankan analisis dan penyiasatan tepat pada masanya. Sudah tentu, anda juga boleh menetapkan ambang (seperti apabila beban purata lebih tinggi daripada 70% daripada bilangan CPU)
Dalam kerja sebenar, kami sering mengelirukan konsep beban purata dan penggunaan CPU Sebenarnya, kedua-duanya tidak setara sepenuhnya:
Sebilangan besar penggunaan CPU akan menyebabkan beban purata meningkat pada masa ini, kedua-duanya adalah proses intensif I/O I/O juga akan menyebabkan beban purata meningkat Pada masa ini, penggunaan CPU tidak semestinya tinggi
Sebilangan besar proses menunggu penjadualan CPU akan menyebabkan beban purata masa, penggunaan CPU juga akan menjadi agak tinggi
Apabila beban purata tinggi, ia mungkin disebabkan oleh proses intensif CPU, atau mungkin I Disebabkan oleh /O sibuk. Semasa analisis khusus, anda boleh menggabungkan alat mpstat/pidstat untuk membantu dalam menganalisis sumber beban
2 Konteks tugas baharu dipindahkan ke daftar ini dan kaunter program, dan akhirnya ia melompat ke lokasi yang ditunjukkan oleh kaunter program untuk menjalankan tugas baharu. Antaranya, konteks yang disimpan akan disimpan dalam kernel sistem dan dimuatkan semula apabila tugasan dijadualkan semula untuk memastikan status tugas asal tidak terjejas. Ikuti komuniti Cina LinuxMengikut jenis tugas, penukaran konteks CPU dibahagikan kepada:
Proses penukaran konteks
Penukaran konteks benang
Sampuk penukaran konteks
Proses penukaran konteks pengguna
ruang yang menjalankan proses
tahap kebenaran. Peralihan daripada mod pengguna kepada mod kernel perlu diselesaikan melalui panggilan sistem. Proses panggilan sistem sebenarnya melakukan dua suis konteks CPU: 🎜
Kedudukan arahan mod pengguna dalam daftar CPU disimpan dahulu, daftar CPU dikemas kini kepada kedudukan arahan mod kernel, dan melompat ke mod kernel untuk menjalankan tugas kernel
Selepas panggilan sistem selesai, daftar CPU memulihkan data status pengguna asal yang disimpan, dan kemudian beralih ke ruang pengguna untuk terus berjalan.
Proses panggilan sistem tidak melibatkan proses sumber mod pengguna seperti memori maya, dan juga tidak menukar proses. Ia berbeza daripada penukaran konteks proses dalam erti kata tradisional. Oleh itu panggilan sistem sering dipanggil suis mod istimewa .
Proses diurus dan dijadualkan oleh kernel, dan penukaran konteks proses hanya boleh berlaku dalam mod kernel. Oleh itu, berbanding dengan panggilan sistem, sebelum menyimpan keadaan kernel dan daftar CPU proses semasa, memori maya dan timbunan proses perlu disimpan terlebih dahulu. Selepas memuatkan keadaan kernel proses baharu, memori maya dan timbunan pengguna proses tersebut mesti dimuat semula.
Proses hanya perlu menukar konteks apabila ia dijadualkan untuk dijalankan pada CPU Terdapat senario berikut: Potongan masa CPU diperuntukkan secara bergilir-gilir, sumber sistem yang tidak mencukupi menyebabkan proses hang, proses aktif melalui fungsi tidur. , dan proses keutamaan tinggi mendahului masa Apabila gangguan perkakasan berlaku, proses pada CPU digantung dan sebaliknya melaksanakan perkhidmatan gangguan dalam kernel.
Penukaran konteks benang
Penukaran konteks benang dibahagikan kepada dua jenis:
Urut depan dan belakang tergolong dalam proses yang sama, dan sumber memori maya kekal tidak berubah semasa suis anda hanya perlu menukar data peribadi, daftar, dsb.
Urut depan dan belakang kepada proses yang berbeza, yang sama seperti penukaran konteks proses.
Penukaran benang dalam proses yang sama menggunakan lebih sedikit sumber, yang juga merupakan kelebihan multi-benang.
Penukaran konteks interrupt
Penukaran konteks interrupt tidak melibatkan mod pengguna proses, jadi konteks interrupt hanya termasuk keadaan yang diperlukan untuk pelaksanaan program perkhidmatan interrupt mod kernel (daftar CPU, tindanan kernel, gangguan perkakasan parameter, dsb.).
Keutamaan pemprosesan gangguan adalah lebih tinggi daripada proses, jadi penukaran konteks gangguan dan penukaran konteks proses tidak akan berlaku pada masa yang sama
Penukaran konteks CPU (Bahagian 2)
Anda boleh menyemak situasi penukaran konteks keseluruhan sistem melalui vmstat
Penggunaan CPU aplikasi mencapai 100%, apakah yang perlu saya lakukan?
Linux, sebagai sistem pengendalian berbilang tugas, membahagikan masa CPU kepada kepingan masa yang singkat dan memperuntukkannya kepada setiap tugas secara bergilir-gilir melalui penjadual. Untuk mengekalkan masa CPU, Linux mencetuskan gangguan masa melalui kadar denyutan yang telah ditetapkan dan menggunakan jiffies global untuk merekodkan bilangan rentak sejak but. Gangguan masa berlaku apabila nilai ini + 1.
Penggunaan CPU , peratusan jumlah masa CPU selain daripada masa melahu. Penggunaan CPU boleh dikira daripada data dalam /proc/stat. Kerana nilai terkumpul bilangan rentak sejak but dalam /proc/stat dikira sebagai purata penggunaan CPU sejak but, yang secara amnya tidak begitu penting. Anda boleh mengira purata penggunaan CPU dalam tempoh itu dengan mengambil perbezaan antara dua nilai yang diambil pada selang tempoh masa. Alat analisis prestasi memberikan purata penggunaan CPU dalam satu tempoh masa.
Penggunaan CPU boleh dilihat melalui atas atau ps. Anda boleh menganalisis masalah CPU proses melalui perf, yang berdasarkan persampelan acara prestasi Ia bukan sahaja boleh menganalisis pelbagai peristiwa sistem dan prestasi kernel, tetapi juga boleh digunakan untuk menganalisis masalah prestasi aplikasi tertentu.
perf top / perf record / perf report (-g menghidupkan pensampelan perhubungan panggilan)
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能
Ini masih sekadar tekaan. Langkah seterusnya ialah teruskan menganalisisnya melalui alat perf. Laporan prestasi menunjukkan bahawa tekanan sebenarnya mengambil banyak CPU, yang boleh diselesaikan dengan membetulkan masalah kebenaran.
Apakah yang perlu saya lakukan jika terdapat sejumlah besar proses tidak terganggu dan proses zombi dalam sistem?
Proses status
R Running/Runnable, menunjukkan bahawa proses berada dalam baris gilir sedia CPU, sedang berjalan atau menunggu untuk dijalankan
D Disk Sleep, keadaan secara amnya tidak terganggu; sedang berkomunikasi dengan perkakasan Interact, dan tidak dibenarkan untuk diganggu oleh proses lain semasa interaksi; ;
S Interruptible Sleep, yang boleh terganggu Keadaan tidur bermakna proses itu digantung oleh sistem kerana ia sedang menunggu acara menunggu, ia akan dikejutkan dan memasuki keadaan R ;
I Terbiar, keadaan terbiar, digunakan pada benang kernel yang tidak boleh mengganggu tidur. Keadaan ini tidak akan menyebabkan beban purata meningkat; tidak berada di atas / ps dilihat.
Selepas analisis lapisan demi lapisan, punca utama ialah cakera langsung I/O di dalam apl. Kemudian cari lokasi kod khusus untuk pengoptimuman.
Proses zombie
Selepas pengoptimuman di atas, iowait telah menurun dengan ketara, tetapi bilangan proses zombi masih meningkat. Mula-mula, cari proses induk proses zombi Gunakan pstree -aps XXX untuk mencetak pepohon panggilan proses zombi dan mendapati bahawa proses induk ialah proses aplikasi.
Semak kod apl untuk melihat sama ada penghujung proses anak dikendalikan dengan betul (sama ada wait()/waitpid() dipanggil, sama ada terdapat fungsi pemprosesan isyarat SIGCHILD didaftarkan, dsb.).
Apabila menghadapi peningkatan dalam iowait, mula-mula gunakan alat seperti dstat dan pidstat untuk mengesahkan sama ada terdapat masalah I/O cakera, dan kemudian ketahui proses yang menyebabkan I/O jika anda tidak boleh menggunakan strace secara langsung menganalisis panggilan proses, anda boleh menggunakan alat perf untuk menganalisisnya.
Untuk masalah zombi, gunakan pstree untuk mencari proses induk, dan kemudian lihat kod sumber untuk menyemak logik pemprosesan untuk akhir proses anak.
Penunjuk prestasi CPU
Penggunaan CPU
Penggunaan CPU pengguna, termasuk mod pengguna (pengguna) dan mod pengguna keutamaan rendah (bagus). bahawa aplikasi Agak sibuk.
Penggunaan CPU sistem, peratusan masa CPU berjalan dalam mod kernel (tidak termasuk gangguan Penunjuk tinggi menunjukkan bahawa kernel agak sibuk.
Penggunaan CPU menunggu I). /O, iowait, penunjuk A tinggi menunjukkan bahawa masa interaksi I/O antara sistem dan peranti perkakasan adalah agak lama
Penggunaan CPU gangguan lembut/keras, penunjuk yang tinggi menunjukkan bahawa sejumlah besar gangguan berlaku. dalam sistem.
curi CPU / CPU tetamu, menunjukkan mesin maya Peratusan CPU yang diduduki.
Purata beban
Sebaik-baiknya, beban purata adalah sama dengan bilangan CPU yang logik. CPU digunakan sepenuhnya. Jika lebih besar, ini bermakna beban sistem lebih berat.
Proses penukaran konteks
Termasuk pensuisan sukarela apabila sumber tidak dapat diperoleh dan pensuisan secara tidak sukarela apabila sistem memaksa penjadualan konteks itu sendiri adalah fungsi teras untuk memastikan operasi biasa Linux yang berlebihan akan memakan masa CPU proses berjalan asal dalam daftar dan kernel Dari segi menyimpan dan memulihkan data seperti memori maya,
CPU cache hit rate
CPU cache reuse, lebih tinggi kadar hit, lebih baik prestasi Antaranya, L1/L2 biasa digunakan secara single teras, dan L3 digunakan dalam Berbilang teras
Performance Tools
Average Load Case
First Gunakan uptime untuk menyemak purata sistem yang dimuatkan berdasarkan sama ada beban telah meningkat, gunakan mpstat dan pidstat untuk memeriksa masing -masing Penggunaan CPU dan CPU bagi setiap proses Ketahui proses yang menyebabkan purata beban yang lebih tinggi Selain itu, cari akaun awam Linux dan balas "buku git" di latar belakang untuk mendapatkan pakej hadiah kejutan.Kes penukaran konteks gunakan pidstat untuk memerhatikan situasi penukaran Konteks benang
Kes penggunaan CPU proses tinggi
Mula-mula gunakan bahagian atas untuk menyemak penggunaan CPU sistem dan proses, cari proses
atas untuk amati per rantaian panggilan proses, dan cari Fungsi proses tertentu
Kes penggunaan CPU sistem tinggi
Mula-mula gunakan bahagian atas untuk menyemak penggunaan CPU sistem dan proses tidak boleh didapati atas/pidstat penggunaan CPU yang tinggi
Periksa semula output teratas
Mulakan dengan proses yang mempunyai penggunaan CPU yang rendah tetapi berada dalam keadaan Running
rekod/laporan prestasi yang ditemui punca proses jangka pendek (execsnoop tool)
kes proses tanpa gangguan dan zombie
Mula-mula gunakan bahagian atas untuk memerhatikan peningkatan dalam iowait dan mendapati bahawa sebilangan besar proses tidak terganggu dan zombie
strace tidak dapat mengesan panggilan sistem
perf menganalisis rantai panggilan dan mendapati punca utama datang daripada I/O terus cakera
kes gangguan lembut
atas diperhatikan bahawa penggunaan CPU gangguan lembut sistem adalah tinggi /
proc/softirqs dan mendapati bahawa kadar perubahan adalah pantas Beberapa gangguan lembut
sar arahan didapati menjadi masalah paket rangkaian
tcpdump untuk mengetahui jenis dan sumber bingkai rangkaian, dan menentukan punca SYN Serangan BANJIR
Cari alat yang sesuai berdasarkan penunjuk prestasi yang berbeza :Gambar dari: www.ctq6.cnDalam persekitaran pengeluaran, pembangun selalunya tidak mempunyai kebenaran untuk memasang pakej alat baharu dan boleh hanya memaksimumkan penggunaan alatan yang telah dipasang dalam sistem Oleh itu, adalah perlu untuk memahami beberapa arus perdana Apakah analisis penunjuk yang boleh disediakan oleh alat?
Picture dari: www.ctq6.cn
first menjalankan beberapa alat yang menyokong lebih banyak petunjuk, seperti Top/Vmstat/Pidstat proses Kemudian gunakan strace/perf untuk menganalisis situasi panggilan untuk analisis lanjut Jika ia disebabkan oleh gangguan lembut, gunakan /proc/softirqs
Gambar daripada: www.ctq6.cn
CPU optimization
aplikasi Optimize
Pengoptimuman pengkompil: Dayakan pilihan pengoptimuman semasa fasa penyusunan, seperti gcc -O2
Pengoptimuman algoritma
Pemprosesan program yang tidak segerak daripada diproses secara serentak: elakkan proses penyewaan program tidak segerak. keupayaan. (Ganti pengundian dengan pemberitahuan acara)
Berbilang benang dan bukannya berbilang proses: Kurangkan kos penukaran konteks
Gunakan cache dengan baik: Percepatkan pemprosesan program
CPU Binding: Ikat proses kepada 1/berbilang CPU untuk meningkatkan kadar hit cache CPU dan mengurangkan penukaran konteks yang disebabkan oleh penjadualan CPU
CPU eksklusif: mekanisme pertalian CPU untuk memperuntukkan proses
. keutamaan Pelarasan tahap: gunakan bagus untuk merendahkan keutamaan aplikasi bukan teras dengan sewajarnya
Tetapkan paparan sumber untuk proses: cgroups menetapkan had penggunaan untuk mengelakkan sumber sistem daripada kehabisan oleh masalah aplikasi tertentu sendiri
Pengoptimuman NUMA: Akses CPU sebanyak mungkin Memori tempatan
Imbangan beban interrupt: irpbalance, memuatkan secara automatik mengimbangi proses pemprosesan interrupt ke setiap CPU
Perbezaan dan pemahaman TPS, QPS, dan throughput sistem
QPS (TPS )
.
Pemprosesan pelayan dalaman
Pelayan kembali kepada pelanggan
QPS serupa dengan TPS, tetapi lawatan ke halaman membentuk TPS, tetapi permintaan halaman mungkin termasuk berbilang permintaan kepada pelayan, yang mungkin dikira sebagai berbilang QPSQPS (Queries Per Second) Kadar pertanyaan sesaat, bilangan pertanyaan pelayan boleh membalas sesaat
TPS (Transaksi Sesaat) Bilangan transaksi sesaat, hasil daripada ujian perisian
Hasil sistem , termasuk beberapa parameter penting:
3Memori
Cara memori Linux berfungsi
Memori
digunakan memori Akses rawak dinamik (DRAM ), sahaja kernel boleh terus mengakses memori fizikal. Kernel Linux menyediakan ruang alamat maya bebas untuk setiap proses, dan ruang alamat ini berterusan. Dengan cara ini, proses tersebut boleh mengakses memori (memori maya) dengan mudah.
🎜 Bahagian dalam ruang alamat maya dibahagikan kepada dua bahagian: ruang kernel dan ruang pengguna Julat ruang alamat pemproses dengan panjang perkataan yang berbeza adalah berbeza. Ruang kernel sistem 32-bit menduduki 1G dan ruang pengguna menduduki 3G. Ruang kernel dan ruang pengguna sistem 64-bit adalah kedua-duanya 128T, masing-masing menduduki bahagian tertinggi dan terendah ruang ingatan, dan bahagian tengah tidak ditentukan. 🎜
Tidak semua memori maya akan diperuntukkan memori fizikal, hanya memori yang digunakan sebenar. Memori fizikal yang diperuntukkan diuruskan melalui pemetaan memori. Untuk melengkapkan pemetaan memori, kernel mengekalkan jadual halaman untuk setiap proses untuk merekodkan hubungan pemetaan antara alamat maya dan alamat fizikal. Jadual halaman sebenarnya disimpan dalam unit pengurusan memori CPU MMU, dan pemproses boleh terus mengetahui memori untuk diakses melalui perkakasan.
Apabila alamat maya yang diakses oleh proses tidak ditemui dalam jadual halaman, sistem akan menjana pengecualian kesalahan halaman, masukkan ruang kernel untuk memperuntukkan memori fizikal, mengemas kini jadual halaman proses, dan kemudian kembali ke ruang pengguna untuk menyambung semula operasi proses.
MMU menguruskan memori dalam unit halaman, dengan saiz halaman 4KB. Untuk menyelesaikan masalah terlalu banyak entri jadual halaman, Linux menyediakan mekanisme jadual halaman berbilang peringkat dan HugePage.
Pengagihan ruang memori maya
Memori ruang pengguna dibahagikan kepada lima segmen memori berbeza dari rendah ke tinggi:
Segmen baca sahaja Kod dan pemalar, dsb.
Segmen data Pembolehubah global, dsb.
Timbunan semua alamat rendahTimbunan semua alamat rendah
Dinamik
Pemetaan fail Mengemas kini Perpustakaan, memori dikongsi, dsb., bermula dari alamat tinggi dan berkembang ke bawah
Timbunan Termasuk pembolehubah setempat dan konteks panggilan fungsi, dsb. Saiz tindanan ditetapkan. Secara amnya, 8MB
peruntukan memori dan kitar semula
peruntukan
malloc sepadan dengan panggilan sistem dalam dua cara:
brk() Untuk blok memori kecil (<128K), peruntukkan dengan mengalihkan kedudukan teratas timbunan. Memori tidak dikembalikan serta-merta selepas ia dikeluarkan, tetapi dicache.
**mmap()** Untuk blok memori yang besar (>128K), peruntukkan terus menggunakan pemetaan memori, iaitu, cari peruntukan memori percuma dalam segmen pemetaan fail.
Cache bekas boleh mengurangkan berlakunya pengecualian halaman yang tiada dan meningkatkan kecekapan capaian memori. Walau bagaimanapun, kerana memori tidak dikembalikan kepada sistem, peruntukan/pelepasan memori yang kerap akan menyebabkan pemecahan memori apabila memori sibuk.
Yang terakhir dikembalikan terus ke sistem apabila dikeluarkan, jadi pengecualian kesalahan halaman akan berlaku setiap kali mmap berlaku. Apabila kerja memori sibuk, peruntukan memori yang kerap akan menyebabkan sejumlah besar pengecualian kesalahan halaman, meningkatkan beban pengurusan kernel.
Dua panggilan di atas sebenarnya tidak memperuntukkan memori ini hanya memasuki kernel melalui pengecualian kesalahan halaman apabila ia diakses buat kali pertama, dan diperuntukkan oleh kernel
Kitar semula
Apabila ingatan ketat. , sistem menuntutnya semula dengan cara berikut Memori:
RES Saiz memori pemastautin, iaitu saiz memori fizikal yang sebenarnya digunakan oleh proses, tidak termasuk swap dan memori dikongsi
SHR Saiz memori yang dikongsi, Memori yang dikongsi dengan proses lain, perpustakaan pautan dinamik yang dimuatkan dan segmen kod program
%MEM Peratusan memori fizikal yang digunakan oleh proses kepada jumlah memori sistem
Bagaimana untuk memahami Buffer dan Cache dalam ingatan?
buffer ialah cache data cakera, cache ialah cache data fail, ia akan digunakan dalam kedua-dua permintaan baca dan tulis
Cara menggunakan cache sistem untuk mengoptimumkan kecekapan operasi program
Kadar hit cache
Kadar hit cache merujuk kepada bilangan permintaan untuk mendapatkan data terus melalui cache, mengambil kira jumlah peratusan daripada semua permintaan. Lebih tinggi kadar hit, lebih tinggi faedah yang dibawa oleh cache dan lebih baik prestasi aplikasi.
Selepas memasang pakej bcc, anda boleh memantau cache baca dan tulis hits melalui cachestat dan cachetop.
Selepas memasang pcstat, anda boleh menyemak saiz cache dan nisbah cache fail dalam memori
#首先安装Go
export GOPATH=~/go
export PATH=~/go/bin:$PATH
go get golang.org/x/sys/unix
go ge github.com/tobert/pcstat/pcstat
Memori yang diperuntukkan tidak dituntut semula dengan betul, mengakibatkan kebocoran
Alamat yang diakses di luar sempadan memori yang diperuntukkan, menyebabkan atur cara keluar secara tidak normal
pengedaran ingatan semula
peruntukan memori kitar semula
rendah Dari atas ke bawah, terdapat lima bahagian: segmen baca sahaja, segmen data, timbunan, segmen pemetaan memori dan tindanan. Antaranya, yang boleh menyebabkan kebocoran memori ialah:
Timbunan: diperuntukkan dan diuruskan oleh aplikasi itu sendiri, ingatan timbunan ini tidak akan dikeluarkan secara automatik oleh sistem melainkan program itu keluar.
Segmen pemetaan memori: termasuk perpustakaan pautan dinamik dan memori dikongsi, di mana memori dikongsi secara automatik diperuntukkan dan diuruskan oleh program
Kemudaratan kebocoran memori adalah agak besar diakses oleh aplikasi itu sendiri, Sistem juga tidak boleh menetapkan semula mereka kepada aplikasi lain.
Kebocoran memori terkumpul malah boleh menghabiskan memori sistem ekzos.
Cache/buffer, sumber yang boleh dikitar semula, biasanya dipanggil halaman fail dalam pengurusan fail
Dalam aplikasi, halaman kotor disegerakkan ke cakera melalui fsync
Serahkan kepada sistem benang, dan pdflush bertanggungjawab Penyegaran semula halaman kotor ini
data (halaman kotor) yang telah diubah suai oleh aplikasi dan belum ditulis ke cakera buat masa ini mesti ditulis ke cakera terlebih dahulu dan kemudian ingatan boleh dikeluarkan
Halaman pemetaan fail yang diperolehi oleh pemetaan memori juga boleh dilepaskan dan dibaca semula daripada fail pada kali berikutnya ia diakses
Untuk memori timbunan yang diperuntukkan secara automatik oleh program, yang merupakan kami halaman tanpa nama dalam pengurusan memori, walaupun memori ini tidak boleh dikeluarkan secara langsung, Linux menyediakan mekanisme Swap kepada Memori yang tidak kerap diakses ditulis pada cakera untuk membebaskan memori, dan memori boleh dibaca dari cakera apabila diakses semula .
Prinsip pertukaran
Intipati Swap ialah menggunakan sekeping ruang cakera atau fail setempat sebagai ingatan, termasuk dua proses pertukaran masuk dan pertukaran keluar:
Tukar keluar: Simpan data memori yang proses tidak gunakan buat sementara waktu ke cakera dan lepaskan memori
Tukar masuk: Apabila proses mengakses memori semula, bacakannya dari cakera ke dalam memori
Bagaimanakah Linux mengukur Adakah sumber memori padat?
Tebus guna Memori Terus Peruntukan memori blok besar baharu diminta, tetapi baki memori tidak mencukupi. Pada masa ini, sistem akan menuntut semula sebahagian daripada memori; Untuk mengukur penggunaan memori, tiga ambang pages_min, pages_low dan pages_high ditakrifkan dan operasi kitar semula memori dilakukan berdasarkannya.
Remaining Memory & lt; melakukan kitar semula memori, sehingga baki memori > pages_high
Cara mencari masalah memori sistem dengan cepat dan tepat pelaksanaan) )
Memori tersedia: termasuk baki memori dan memori boleh tuntut semula
Cache: cache halaman fail baca cakera, bahagian boleh tuntut semula dalam pengagih papak
Penampan: penyimpanan sementara blok cakera asal , cache data yang akan ditulis ke cakera
Penunjuk memori proses
Memori maya: 5 paling
Memori residen: Memori fizikal yang sebenarnya digunakan oleh proses, tidak termasuk Swap dan memori dikongsi
Memori dikongsi: Memori yang dikongsi dengan proses lain, serta perpustakaan pautan dinamik dan program Coretan kod
Selain itu, cari latar belakang komuniti teknikal akaun rasmi untuk membalas "algoritma" untuk mendapatkan pakej hadiah kejutan. . Seperti Swap), halaman utama hilang secara tidak normal. Pada masa ini, akses memori akan menjadi lebih perlahan
Alat prestasi memori
Cari alat yang betul berdasarkan penunjuk prestasi yang berbeza:
Gambar dari: www.ctq6.cn
Penunjuk prestasi yang disertakan dalam alat analisis ingatan:
Gambar dari: www.ctq6.cn
Menganalisis prestasi memori dengan cepatMenganalisis prestasi biasa
pertama Jalankan beberapa alatan prestasi dengan liputan yang agak besar, seperti percuma, atas, vmstat, pidstat, dll.
Mula-mula gunakan percuma dan atas untuk menyemak keseluruhan penggunaan memori sistem
Kemudian gunakan vmstat dan pidstat untuk menyemak trend dalam satu tempoh masa untuk menentukan jenis masalah ingatan
Akhirnya, lakukan secara terperinci analisis, seperti analisis peruntukan memori, analisis Cache/buffer, analisis penggunaan memori bagi proses tertentu, dsb.
Atas ialah kandungan terperinci Ringkasan mata pengetahuan pengoptimuman prestasi Linux · Amalan + Edisi Koleksi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Proses tidak terganggu ialah proses yang berada dalam proses kritikal dalam keadaan kernel (seperti tindak balas I/O biasa menunggu peranti). 
Gambar dari: www.ctq6.cn
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
