Ringkasan pengalaman penalaan menyeluruh prestasi Linux

Bahagian1Pengoptimuman Prestasi Linux

1Pengoptimuman Prestasi

Selaras Tinggi dan Tindak balas pantas sepadan dengan dua petunjuk teras pengoptimuman prestasi: Throughput dan Latensi

🎜🎜

Gambar dari: www.ctq6.cn

• Beban aplikasiSudut: secara langsung mempengaruhi pengalaman pengguna terminal produk

le: penggunaan sumber, ketepuan 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
cate bottlenecks
Pemantauan dan amaran prestasi
Untuk masalah prestasi yang berbeza, alat analisis prestasi yang berbeza harus dipilih. Berikut ialah Alat Prestasi Linux yang biasa digunakan dan jenis masalah prestasi yang sepadan dianalisis.

. nombor masa unit, iaitu 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 yang 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, kita sering mengelirukan konsep beban purata dan penggunaan CPU. kedua-duanya tidak setara sepenuhnya:

• Proses intensif CPU, penggunaan CPU yang banyak akan menyebabkan beban purata meningkat, pada masa ini kedua-duanya konsisten
• Proses intensif I/O, menunggu I/O juga akan menyebabkan beban purata meningkat, ini Penggunaan CPU tidak semestinya tinggi
• Sebilangan besar proses menunggu penjadualan CPU akan menyebabkan beban purata meningkat pada masa ini, penggunaan CPU juga agak tinggi

Apabila purata beban CPU tinggi, mungkin CPU Disebabkan oleh proses intensif atau I/O yang sibuk. Semasa analisis khusus, anda boleh menggabungkan alat mpstat/pidstat untuk membantu dalam menganalisis sumber beban

2CPU

Pensuisan konteks CPU (Bahagian 1)

Pensuisan konteks CPU adalah untuk menyimpan konteks CPU (daftar CPU dan PC yang baru) konteks ke daftar ini dan pembilang program, dan akhirnya melompat ke lokasi yang ditunjukkan oleh pembilang 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.

Mengikut jenis tugas, penukaran konteks CPU dibahagikan kepada:

• Proses suis konteks Proses Linux mengikut Keizinan Tahap membahagikan ruang proses sesuatu proses ke dalam ruang kernel dan ruang pengguna. Peralihan daripada mod pengguna kepada mod kernel perlu diselesaikan melalui panggilan sistem.
• Proses panggilan sistem sebenarnya melaksanakan dua suis konteks CPU:
  • Lokasi arahan mod pengguna dalam daftar CPU disimpan dahulu, daftar CPU dikemas kini ke lokasi arahan mod kernel, dan melompat ke keadaan kernel untuk menjalankan tugas kernel; Selepas panggilan sistem tamat, daftar CPU kembali ke keadaan asalnya Simpan data mod pengguna 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 keadaan 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 secara aktif melepasi. fungsi tidur, dan proses keutamaan tinggi Potongan masa preemption, apabila perkakasan terganggu, proses pada CPU digantung dan sebaliknya melaksanakan perkhidmatan gangguan dalam kernel.

  Penukaran konteks benang

  Penukaran konteks benang terbahagi kepada dua jenis:

  • Benang depan dan belakang tergolong dalam proses yang sama, sumber memori maya kekal tidak berubah semasa suis data, daftar, dsb. perlu ditukar;
  • Penukaran benang dalam proses yang sama menggunakan lebih sedikit sumber, yang juga merupakan kelebihan multi-benang.

    Pensuisan konteks interrupt

    Penukaran konteks interrupt tidak melibatkan keadaan pengguna proses, jadi konteks interrupt hanya termasuk keadaan yang diperlukan untuk pelaksanaan program perkhidmatan interrupt state 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

    Maklumat video komprehensif teknologi arus perdana Docker+K8s+Jenkins

    Penukaran konteks CPU (Bahagian 2)

    Anda boleh menyemak situasi penukaran konteks keseluruhan sistem melalui vmstat

    vmstat 5         #每隔5s输出一组数据
    procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
     1  0      0 103388 145412 511056    0    0    18    60    1    1  2  1 96  0  0
     0  0      0 103388 145412 511076    0    0     0     2  450 1176  1  1 99  0  0
     0  0      0 103388 145412 511076    0    0     0     8  429 1135  1  1 98  0  0
     0  0      0 103388 145412 511076    0    0     0     0  431 1132  1  1 98  0  0
     0  0      0 103388 145412 511076    0    0     0    10  467 1195  1  1 98  0  0
     1  0      0 103388 145412 511076    0    0     0     2  426 1139  1  0 99  0  0
     4  0      0  95184 145412 511108    0    0     0    74  500 1228  4  1 94  0  0
     0  0      0 103512 145416 511076    0    0     0   455  723 1573 12  3 83  2  0

    • cs (suis konteks) Bilangan suis konteks sesaat
    • dalam (gangguan) Bilangan sampukan sesaat
    • panjang siap atau larian berjalan dan menunggu Bilangan proses dalam CPU

    b (Disekat) Bilangan proses dalam keadaan tidur tidak terganggu

    🎜🎜🎜🎜Untuk melihat butiran setiap proses, anda perlu menggunakan pidstat untuk melihat penukaran konteks setiap proses🎜🎜

    pidstat -w 5
    14时51分16秒   UID       PID   cswch/s nvcswch/s  Command
    14时51分21秒     0         1      0.80      0.00  systemd
    14时51分21秒     0         6      1.40      0.00  ksoftirqd/0
    14时51分21秒     0         9     32.67      0.00  rcu_sched
    14时51分21秒     0        11      0.40      0.00  watchdog/0
    14时51分21秒     0        32      0.20      0.00  khugepaged
    14时51分21秒     0       271      0.20      0.00  jbd2/vda1-8
    14时51分21秒     0      1332      0.20      0.00  argusagent
    14时51分21秒     0      5265     10.02      0.00  AliSecGuard
    14时51分21秒     0      7439      7.82      0.00  kworker/0:2
    14时51分21秒     0      7906      0.20      0.00  pidstat
    14时51分21秒     0      8346      0.20      0.00  sshd
    14时51分21秒     0     20654      9.82      0.00  AliYunDun
    14时51分21秒     0     25766      0.20      0.00  kworker/u2:1
    14时51分21秒     0     28603      1.00      0.00  python3

    • cswch 每秒自愿上下文切换次数 （进程无法获取所需资源导致的上下文切换）
    • nvcswch 每秒非自愿上下文切换次数 （时间片轮流等系统强制调度）

    vmstat 1 1    #首先获取空闲系统的上下文切换次数
    sysbench --threads=10 --max-time=300 threads run #模拟多线程切换问题
    
    vmstat 1 1    #新终端观察上下文切换情况
    此时发现cs数据明显升高，同时观察其他指标：
    r列： 远超系统CPU个数，说明存在大量CPU竞争
    us和sy列：sy列占比80%，说明CPU主要被内核占用
    in列： 中断次数明显上升，说明中断处理也是潜在问题

    说明运行/等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高

    pidstat -w -u 1  #查看到底哪个进程导致的问题

    从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。

    另外对于中断次数过多，我们可以通过/proc/interrupts文件读取

    watch -d cat /proc/interrupts

    发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。

    某个应用的CPU使用率达到100%，怎么办？

    Linux作为多任务操作系统，将CPU时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护CPU时间，Linux通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以来的节拍数。时间中断发生一次该值+1.

    CPU使用率，除了空闲时间以外的其他时间占总CPU时间的百分比。可以通过/proc/stat中的数据来计算出CPU使用率。因为/proc/stat时开机以来的节拍数累加值，计算出来的是开机以来的平均CPU使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均CPU使用率。性能分析工具给出的都是间隔一段时间的平均CPU使用率，要注意间隔时间的设置。

    CPU使用率可以通过top 或 ps来查看。分析进程的CPU问题可以通过perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

    perf top / perf record / perf report （-g 开启调用关系的采样）

    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服务性能

    发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个CPU的使用率。发现系统中几个php-fpm进程导致CPU使用率骤升。

    接着用perf来分析具体是php-fpm中哪个函数导致该问题。

    perf top -g -p XXXX #对某一个php-fpm进程进行分析

    发现其中sqrt和add_function占用CPU过多， 此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升

    系统的CPU使用率很高，为什么找不到高CPU的应用？

    sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:sp
    sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp
    ab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试

    实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，nginx负载能力依旧很低。

    此时用top和pidstat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。

    出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5. 再仔细查看进程运行数据，发现nginx和php-fpm都处于sleep状态，真正处于运行的却是几个stress进程。

    下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用ps aux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现stress进程的进程号变化了，此时有可能时以下两种原因导致：

    • 进程不停的崩溃重启（如段错误/配置错误等），此时进程退出后可能又被监控系统重启；
    • 短时进程导致，即其他应用内部通过exec调用的外面命令，这些命令一般只运行很短时间就结束，很难用top这种间隔较长的工具来发现

    可以通过pstree来查找 stress的父进程，找出调用关系。

    pstree | grep stress

    发现是php-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟I/O压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。

    此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的CPU，通过修复权限问题来优化解决即可.

    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 itu berada dalam baris gilir sedia CPU, berjalan atau menunggu untuk dijalankan
    • Dalam keadaan tidur, tidak terganggu secara amnya; proses Ia berinteraksi dengan perkakasan dan tidak dibenarkan diganggu oleh proses lain semasa interaksi
    • Z Zombie, proses zombi, bermakna proses itu sebenarnya telah tamat, tetapi proses induk belum dituntut semula; sumbernya;
    • S Interruptible Sleep, yang boleh mengganggu keadaan tidur, bermakna proses itu ditangguhkan oleh sistem kerana ia sedang menunggu untuk acara menunggu, ia akan dikejutkan dan memasuki Keadaan R;
    • I Melahu, keadaan melahu, digunakan dalam Pada benang inti tidur yang tidak terganggu.该状态不会导致平均负载升高；
• T Stop/Traced，表示进程处于暂停或跟踪状态（SIGSTOP/SIGCONT， GDB调试）；
• X Dead，进程已经消亡，不会在top/ps中看到。

对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了I/O性能问题。

僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。

磁盘O_DIRECT问题

sudo docker run --privileged --name=app -itd feisky/app:iowait
ps aux | grep '/app'

可以看到此时有多个app进程运行，状态分别时Ss+和D+。其中后面s表示进程是一个会话的领导进程，+号表示前台进程组。

其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。

用top查看系统资源发现：1）平均负载在逐渐增加，且1分钟内平均负载达到了CPU个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us和sys CPU使用率都不高，iowait却比较高；4）每个进程CPU使用率也不高，但有两个进程处于D状态，可能在等待IO。

分析目前数据可知：iowait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。

用dstat来分析，因为它可以同时查看CPU和I/O两种资源的使用情况，便于对比分析。

dstat 1 10    #间隔1秒输出10组数据

可以看到当wai（iowait）升高时磁盘请求read都会很大，说明iowait的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。

之前top查看的处于D状态的进程号，用pidstat -d -p XXX 展示进程的I/O统计数据。发现处于D状态的进程都没有任何读写操作。在用pidstat -d 查看所有进程的I/O统计数据，看到app进程在进行磁盘读操作，每秒读取32MB的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到app进程的系统调用。

sudo strace -p XXX #对app进程调用进行跟踪

报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。ps命令查找该进程已经处于Z状态，即僵尸进程。

这种情况下top pidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perf record -d和perf report进行分析，查看app进程调用栈。

看到app确实在通过系统调用sys_read()读取数据，并且从new_sync_read和blkdev_direct_IO看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。

通过层层分析后，root cause是app内部进行了磁盘的直接I/O。然后定位到具体代码位置进行优化即可。

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 untuk menganalisis secara langsung 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.

Metrik Prestasi CPU

• Penggunaan CPU

  . , CPU ialah Peratusan masa mod kernel sedang berjalan (tidak termasuk gangguan Penunjuk tinggi menunjukkan bahawa kernel agak sibuk
• Penggunaan CPU menunggu I/O, iowait, penunjuk tinggi menunjukkan I. Masa interaksi /O antara sistem dan peranti perkakasan Agak panjang.
• Penggunaan CPU gangguan lembut/keras, penunjuk yang tinggi menunjukkan bilangan gangguan yang besar dalam sistem.
• mencuri CPU / tetamu CPU, menunjukkan peratusan CPU yang diduduki oleh mesin maya.
• Purata beban
• Sebaik-baiknya, beban purata adalah sama dengan bilangan CPU logik yang digunakan sepenuhnya. Jika lebih besar, bermakna beban sistem lebih berat.

• Proses Suis Konteks

  Termasuk pensuisan sukarela apabila sumber tidak dapat diperoleh dan pensuisan secara sukarela apabila sistem memaksa pensuisan konteks itu sendiri adalah fungsi teras untuk memastikan operasi normal Linux Pensuisan yang berlebihan akan memakan masa CPU proses berjalan asal dalam daftar. Inti dan memori maya dan penjimatan dan pemulihan data lain. Di samping itu, cari pengaturcara akaun awam Xiaole di belakang pentas untuk membalas "soalan temu bual" dan dapatkan pakej hadiah kejutan.

• CPU Cache Hit Rate

  cpu Cache digunakan semula, semakin tinggi kadar hit, lebih baik prestasi. -teras

  Alat prestasi dan pid selepas menilai beban masing-masing CPU dan penggunaan CPU bagi setiap proses.
  Gunakan pidstat untuk memerhatikan penukaran konteks proses secara sukarela dan tidak sukarela

Akhir sekali, perhatikan penukaran konteks utas melalui pidstat

Kes penggunaan CPU proses tinggi

• penggunaan pertama dan proses sistem untuk melihat penggunaan CPU dan proses pertama proses

Kemudian gunakan perf top untuk memerhati rantaian panggilan proses dan cari fungsi tertentu

kes penggunaan CPU sistem tinggi
• penggunaan sistem dan proses, atas/ Malah pidstat tidak dapat mencari proses dengan penggunaan CPU yang tinggi
• Periksa semula output teratas
🎜🎜🎜🎜Mulakan dengan proses yang mempunyai penggunaan CPU yang rendah tetapi dalam keadaan Berjalan 🎜🎜🎜
• rekod/laporan perf menemui proses jangka pendek (alat execsnoop)

Kes proses tanpa gangguan dan zombi

yang ditemui untuk meningkatkan jumlah yang besar, memerhatikan dan memerhatikan bahagian atas proses tidak terganggu dan zombie Proses
strace tidak dapat mengesan panggilan sistem proses
rantai panggilan analisis perf mendapati punca punca datang dari cakera langsung I/O

• pemerhatian atas Penggunaan CPU gangguan lembut sistem adalah tinggi
• Semak /proc/softirqs untuk mencari beberapa gangguan lembut dengan kadar perubahan pantas yang ditemui
🎜🎜🎜🎜🎜🎜 masalah paket rangkaian🎜🎜🎜
• tcpdump mengetahui jenis dan sumber bingkai rangkaian, dan menentukan punca serangan SYN FLOOD

Cari alat yang betul berdasarkan penunjuk prestasi berbeza:

dari www. ctq6.cn

Dalam persekitaran pengeluaran, pembangun selalunya tidak mempunyai kebenaran untuk memasang pakej alat baharu dan hanya boleh memaksimumkan penggunaan alatan yang telah dipasang dalam sistem Oleh itu, adalah perlu untuk memahami analisis penunjuk beberapa arus perdana alatan boleh sediakan.

🎜

Gambar daripada: www.ctq6.cn

Mula-mula jalankan beberapa alatan yang menyokong lebih banyak penunjuk, seperti atas/vmstat/pidstat Berdasarkan outputnya, anda boleh menentukan jenis masalah prestasi itu. Selepas mengesan proses, 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 pengoptimuman

• Pengoptimuman aplikasi

  .
• Gunakan cache dengan baik: Percepatkan pemprosesan program
• Pengoptimuman sistem
• • CPU mengikat: Ikat proses kepada 1/berbilang CPU, tingkatkan kadar hit cache CPU dan kurangkan pensuisan konteks yang disebabkan oleh penjadualan CPU
  • CPU eksklusif: kepada CPU allocate Mekanisme
  • Pelarasan keutamaan: gunakan yang bagus untuk mengurangkan keutamaan aplikasi bukan teras dengan sewajarnya
  • Tetapkan paparan sumber untuk proses: cgroups menetapkan had atas penggunaan untuk mengelakkan keletihan akibat masalah aplikasi itu sendiri
  • numa Pengoptimuman: CPU mengakses memori tempatan sebanyak mungkin
  • imbalan beban pengimbangan: irpbalance, beban secara automatik mengimbangi proses pemprosesan interupsi untuk setiap cpu
• tps, perbezaan dan pemahaman tentang QPS dan throughput sistem

• QPS(TPS)

  .

  Pelayan permintaan pengguna

• Pemprosesan dalaman pelayan

• Pelayan mengembalikannya kepada klien

  QPS serupa dengan TPS, tetapi lawatan ke halaman membentuk TPS, tetapi permintaan halaman mungkin termasuk permintaan berbilang ke pelayan, yang mungkin dikira Masukkan berbilang QPS

• QPS (Queries Per Second) kadar pertanyaan sesaat, bilangan pertanyaan pelayan boleh membalas sesaat.

• TPS (Transaksi Sesaat), hasil ujian perisian

• Hasil sistem, termasuk beberapa parameter penting:

  .

3memory

how Linux Memory Works Works

Memory

Memori utama yang digunakan oleh kebanyakan komputer adalah memori akses rawak dinamik (DRAM). akses terus 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 meneruskan 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.
terhimpit memori , bermula dari alamat rendah dan berkembang ke atas
• Pemetaan fail
Perpustakaan dinamik, memori dikongsi, dsb., bermula dari alamat tinggi dan berkembang ke bawah
• memasukkan saiz panggilan dan lain-lain. daripada timbunan telah ditetapkan.Secara umumnya 8MB

Peruntukan memori dan kitar semula

peruntukan

malloc sepadan dengan panggilan sistem. Terdapat dua kaedah pelaksanaan:

• brk() Untuk blok kecil ingatan (
• **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 kesalahan halaman 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 sempit, sistem menuntut semula memori dengan cara berikut:

• Cache kitar semula: Algoritma LRU menuntut semula halaman memori yang paling kurang digunakan baru-baru ini; Kitar semula adalah jarang Memori capaian: tulis memori yang jarang digunakan pada cakera melalui partition swap ia menduduki, lebih kecil oom_score anda boleh lulus /proc secara manual melaraskan oom_adj)

  echo -16 > /proc/$(pidof XXX)/oom_adj

如何查看内存使用情况

free来查看整个系统的内存使用情况

top/ps来查看某个进程的内存使用情况

• VIRT Saiz memori maya proses
• RESSaiz memori pemastautin, iaitu saiz memori fizikal yang sebenarnya digunakan oleh proses, tidak termasuk memori swap dan kongsi
• SHR Saiz memori dikongsi, memori dikongsi dengan proses lain, perpustakaan pautan dinamik yang dimuatkan dan segmen kod program
• %MEM Peratusan kepada jumlah memori fizikal yang digunakan oleh sistem memori
Bagaimana untuk memahami Penimbal dan Cache dalam memori?

Buffer ialah cache data cakera, cache ialah cache data fail, ia 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 peratusan 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.

安装pcstat后可以查看文件在内存中的缓存大小以及缓存比例

#首先安装Go
export GOPATH=~/go
export PATH=~/go/bin:$PATH
go get golang.org/x/sys/unix
go ge github.com/tobert/pcstat/pcstat

dd缓存加速

dd if=/dev/sda1 of=file bs=1M count=512 #生产一个512MB的临时文件
echo 3 > /proc/sys/vm/drop_caches #清理缓存
pcstat file #确定刚才生成文件不在系统缓存中，此时cached和percent都是0
cachetop 5
dd if=file of=/dev/null bs=1M #测试文件读取速度
#此时文件读取性能为30+MB/s，查看cachetop结果发现并不是所有的读都落在磁盘上，读缓存命中率只有50%。
dd if=file of=/dev/null bs=1M #重复上述读文件测试
#此时文件读取性能为4+GB/s，读缓存命中率为100%
pcstat file #查看文件file的缓存情况，100%全部缓存

O_DIRECT选项绕过系统缓存

cachetop 5
sudo docker run --privileged --name=app -itd feisky/app:io-direct
sudo docker logs app #确认案例启动成功
#实验结果表明每读32MB数据都要花0.9s，且cachetop输出中显示1024次缓存全部命中

但是凭感觉可知如果缓存命中读速度不应如此慢，读次数时1024，页大小为4K，五秒的时间内读取了1024*4KB数据，即每秒0.8MB，和结果中32MB相差较大。说明该案例没有充分利用缓存，怀疑系统调用设置了直接I/O标志绕过系统缓存。因此接下来观察系统调用.

strace -p $(pgrep app)
#strace 结果可以看到openat打开磁盘分区/dev/sdb1，传入参数为O_RDONLY|O_DIRECT

这就解释了为什么读32MB数据那么慢，直接从磁盘读写肯定远远慢于缓存。找出问题后我们再看案例的源代码发现flags中指定了直接IO标志。删除该选项后重跑，验证性能变化。

Memori bocor, bagaimana untuk mencari dan menanganinya?

Untuk aplikasi, peruntukan memori dinamik dan kitar semula ialah modul fungsi logik teras dan kompleks. Pelbagai "kemalangan" akan berlaku dalam proses menguruskan ingatan:

• Memori yang diperuntukkan tidak dituntut semula dengan betul, mengakibatkan kebocoran
• Alamat di luar sempadan memori yang diperuntukkan telah diakses, menyebabkan program keluar secara tidak normal

memori

memori

🎜🎜🎜 🎜🎜 Pengagihan memori maya dari rendah ke tinggi ialah 🎜segmen baca sahaja, segmen data, timbunan, segmen pemetaan memori dan tindanan 🎜lima bahagian. Antaranya yang boleh menyebabkan kebocoran ingatan ialah: 🎜🎜
• Timbunan: Diperuntukkan dan diuruskan oleh aplikasi itu sendiri tidak akan dikeluarkan secara automatik oleh sistem melainkan program keluar.
• Segmen pemetaan memori: termasuk perpustakaan pautan dinamik dan memori kongsi, di mana memori dikongsi secara automatik diperuntukkan dan diuruskan oleh program

Kebocoran memori ini bukan sahaja digunakan oleh kenangan aplikasi Mereka tidak boleh mengaksesnya sendiri, dan sistem tidak boleh memperuntukkannya kepada aplikasi lain lagi. Kebocoran memori terkumpul dan juga memori sistem ekzos.

Cara mengesan kebocoran memori

Prapasang systat, docker, bcc

sudo docker run --name=app -itd feisky/app:mem-leak
sudo docker logs app
vmstat 3

可以看到free在不断下降，buffer和cache基本保持不变。说明系统的内存一致在升高。但并不能说明存在内存泄漏。此时可以通过memleak工具来跟踪系统或进程的内存分配/释放请求。另外，搜索公众号Linux就该这样学后台回复“git书籍”，获取一份惊喜礼包。

/usr/share/bcc/tools/memleak -a -p $(pidof app)

从memleak输出可以看到，应用在不停地分配内存，并且这些分配的地址并没有被回收。通过调用栈看到是fibonacci函数分配的内存没有释放。定位到源码后查看源码来修复增加内存释放函数即可.

为什么系统的Swap变高

系统内存资源紧张时通过内存回收和OOM杀死进程来解决。其中可回收内存包括：

• Cache/buffer, yang merupakan sumber yang boleh dikitar semula, biasanya dipanggil halaman fail dalam pengurusan fail
• Halaman kotor disegerakkan ke cakera melalui fsync dalam aplikasi
• ke sistem, benang kernel pdflush bertanggungjawab untuk menyegarkan halaman kotor ini
• Data (halaman kotor) yang telah diubah suai oleh aplikasi dan belum ditulis ke cakera buat masa ini mesti ditulis ke cakera dahulu dan kemudian ingatan boleh dilepaskan
• Halaman pemetaan fail yang diperolehi dengan pemetaan juga boleh dilepaskan dan dibaca semula daripada fail pada kali berikutnya ia diakses Untuk memori timbunan yang diperuntukkan secara automatik oleh program, ia adalah halaman tanpa nama kami dalam pengurusan memori Walaupun memori ini Ia tidak boleh dikeluarkan secara langsung, tetapi Linux menyediakan mekanisme Swap untuk menulis memori yang jarang diakses ke cakera untuk melepaskan memori, dan kemudian membaca memori dari cakera apabila diakses. sekali lagi.
Prinsip Swap tidak digunakan buat sementara waktu oleh proses Data disimpan ke cakera dan memori ini dikeluarkan

Bertukar masuk: Apabila proses mengakses memori sekali lagi, bacanya dari cakera ke dalam memori

• Bagaimanakah Linux mengukur sama ada sumber ingatan ketat?

  • 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.

  • Memori yang tinggal

  ; pages_high
  pages_low

• 剩余内存 > pages_high，说明剩余内存较多，无内存压力

  pages_low = pages_min 5 / 4 pages_high = pages_min 3 / 2

NUMA 与 SWAP

很多情况下系统剩余内存较多，但SWAP依旧升高，这是由于处理器的NUMA架构。

在NUMA架构下多个处理器划分到不同的Node，每个Node都拥有自己的本地内存空间。在分析内存的使用时应该针对每个Node单独分析

numactl --hardware #查看处理器在Node的分布情况，以及每个Node的内存使用情况

内存三个阈值可以通过/proc/zoneinfo来查看，该文件中还包括活跃和非活跃的匿名页/文件页数。

Apabila Nod kehabisan memori, sistem boleh mencari sumber percuma daripada Nod lain atau menuntut semula memori daripada memori tempatan. Laraskan melalui /proc/sys/vm/zone_raclaim_mode. . data kotor boleh dikembalikan untuk menuntut semula memori, 4 menunjukkan bahawa memori boleh dituntut semula menggunakan Swap.

• swappiness
• Semasa proses kitar semula sebenar, Linux melaraskan keaktifan menggunakan Swap mengikut pilihan /proc/sys/vm/swapiness, dari 0-100, semakin besar nilainya Swap digunakan, iaitu, lebih cenderung untuk menggunakan Swap Untuk mengitar semula halaman tanpa nama, lebih pasif Swap digunakan, iaitu, lebih besar kemungkinan untuk mengitar semula halaman fail.

  注意：这只是调整Swap积极程度的权重，即使设置为0，当剩余内存+文件页小于页高阈值时，还是会发生Swap。

  Swap升高时如何定位分析

  free #首先通过free查看swap使用情况，若swap=0表示未配置Swap
  #先创建并开启swap
  fallocate -l 8G /mnt/swapfile
  chmod 600 /mnt/swapfile
  mkswap /mnt/swapfile
  swapon /mnt/swapfile
  
  free #再次执行free确保Swap配置成功
  
  dd if=/dev/sda1 of=/dev/null bs=1G count=2048 #模拟大文件读取
  sar -r -S 1  #查看内存各个指标变化 -r内存 -S swap
  #根据结果可以看出，%memused在不断增长，剩余内存kbmemfress不断减少，缓冲区kbbuffers不断增大，由此可知剩余内存不断分配给了缓冲区
  #一段时间之后，剩余内存很小，而缓冲区占用了大部分内存。此时Swap使用之间增大，缓冲区和剩余内存只在小范围波动
  
  停下sar命令
  cachetop5 #观察缓存
  #可以看到dd进程读写只有50%的命中率，未命中数为4w+页，说明正式dd进程导致缓冲区使用升高
  watch -d grep -A 15 ‘Normal’ /proc/zoneinfo #观察内存指标变化
  #发现升级内存在一个小范围不停的波动，低于页低阈值时会突然增大到一个大于页高阈值的值

  说明剩余内存和缓冲区的波动变化正是由于内存回收和缓存再次分配的循环往复。有时候Swap用的多，有时候缓冲区波动更多。此时查看swappiness值为60，是一个相对中和的配置，系统会根据实际运行情况来选去合适的回收类型.

  Cara mencari masalah memori sistem dengan cepat dan tepat

  Penunjuk prestasi memori

  Penunjuk memori sistem

  Memori terpakai/baki memori : fail baca cakera Cache halaman , bahagian yang boleh dituntut semula dalam pengalokasi papak

  • Penampan: penyimpanan sementara blok cakera mentah, cache data yang akan ditulis ke cakera
  Penunjuk memori proses
  • • Memori Maya: 5 Paling
    • Memori Penduduk: Memori fizikal yang sebenarnya digunakan oleh proses, tidak termasuk Swap dan Memori Dikongsi
    • dengan Memori yang dikongsi bersama: dan Perkongsian Kod yang lain segmen perpustakaan dan program pautan dinamik
    • Tukar memori: Tukar memori ke cakera melalui Swap. Ikuti komuniti Cina Linux

    pengecualian halaman yang tiada

    • boleh diperuntukkan terus dari memori fizikal Pengecualian tiada halaman sekunder
    • memerlukan campur tangan IO cakera (seperti Swap), dan pengecualian tiada halaman utama. 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 disertakan dalam alat analisis ingatan:

    

    Gambar dari:

    How. untuk menganalisis ingatan dengan cepat performance Bottleneck

    Biasanya jalankan beberapa alatan prestasi dengan liputan yang agak besar dahulu, 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 Akhir sekali, jalankan analisis terperinci, Contohnya, analisis peruntukan memori, analisis cache/penampan, analisis penggunaan memori proses tertentu, dll.
    • Idea pengoptimuman biasa:
    • Sebaik-baiknya lumpuhkan Swap Jika anda mesti mendayakannya, cuba kurangkan nilai swappiness
    • Kurangkan peruntukan memori yang dinamik. Contohnya, anda boleh menggunakan kumpulan memori, HugePage .
    • Gunakan cache dan penimbal sebanyak mungkin untuk mengakses data. Contohnya, gunakan tindanan untuk mengisytiharkan ruang memori secara eksplisit untuk menyimpan data yang perlu dicache, atau gunakan komponen cache luaran Redis untuk mengoptimumkan akses data
    • ckumpulan dan kaedah lain untuk mengehadkan penggunaan memori bagi proses dan pastikan memori sistem tidak digunakan oleh proses yang tidak normal Cuba
    • /proc/pid/oom_adj melaraskan oom_score aplikasi teras untuk memastikan aplikasi teras tidak akan dimatikan oleh OOM. ingatan ketat

    Penjelasan terperinci tentang penggunaan vmstat

    Arahan vmstat adalah yang paling biasa Alat pemantauan Linux/Unix boleh memaparkan nilai status pelayan pada selang masa tertentu, termasuk penggunaan CPU pelayan , penggunaan memori, status pertukaran memori maya dan status baca dan tulis IO.可以看到整个机器的CPU,内存,IO的使用情况，而不是单单看到各个进程的CPU使用率和内存使用率(使用场景不一样)。

    vmstat 2
    procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
     1  0      0 1379064 282244 11537528    0    0     3   104    0    0  3  0 97  0  0
     0  0      0 1372716 282244 11537544    0    0     0    24 4893 8947  1  0 98  0  0
     0  0      0 1373404 282248 11537544    0    0     0    96 5105 9278  2  0 98  0  0
     0  0      0 1374168 282248 11537556    0    0     0     0 5001 9208  1  0 99  0  0
     0  0      0 1376948 282248 11537564    0    0     0    80 5176 9388  2  0 98  0  0
     0  0      0 1379356 282256 11537580    0    0     0   202 5474 9519  2  0 98  0  0
     1  0      0 1368376 282256 11543696    0    0     0     0 5894 8940 12  0 88  0  0
     1  0      0 1371936 282256 11539240    0    0     0 10554 6176 9481 14  1 85  1  0
     1  0      0 1366184 282260 11542292    0    0     0  7456 6102 9983  7  1 91  0  0
     1  0      0 1353040 282260 11556176    0    0     0 16924 7233 9578 18  1 80  1  0
     0  0      0 1359432 282260 11549124    0    0     0 12576 5495 9271  7  0 92  1  0
     0  0      0 1361744 282264 11549132    0    0     0    58 8606 15079  4  2 95  0  0
     1  0      0 1367120 282264 11549140    0    0     0     2 5716 9205  8  0 92  0  0
     0  0      0 1346580 282264 11562644    0    0     0    70 6416 9944 12  0 88  0  0
     0  0      0 1359164 282264 11550108    0    0     0  2922 4941 8969  3  0 97  0  0
     1  0      0 1353992 282264 11557044    0    0     0     0 6023 8917 15  0 84  0  0
    
    # 结果说明
    - r 表示运行队列(就是说多少个进程真的分配到CPU)，我测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。
    
    - b 表示阻塞的进程,这个不多说，进程阻塞，大家懂的。
    
    - swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。
    
    - free   空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。
    
    - buff   Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用300多M
    
    - cache cache直接用来记忆我们打开的文件,给文件做缓冲，我本机大概占用300多M(这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高 程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。)
    
    - si  每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。
    
    - so  每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。
    
    - bi  块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒
    
    - bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。
    
    - in 每秒CPU的中断次数，包括时间中断
    
    - cs 每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
    
    - us 用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
    
    - sy 系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
    
    - id 空闲CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。
    
    - wt 等待IO CPU时间

    pidstat 使用详解

    pidstat主要用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。

    使用方法：

    . proses Maklumat penggunaan
    • pidstat -w masa selang Kira penukaran konteks setiap proses
    • p PID Nyatakan PID
    • penggunaan I

      pidstat -d 1 10
      
      03:02:02 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
      03:02:03 PM     0       816      0.00    918.81      0.00  jbd2/vda1-8
      03:02:03 PM     0      1007      0.00      3.96      0.00  AliYunDun
      03:02:03 PM   997      7326      0.00   1904.95    918.81  java
      03:02:03 PM   997      8539      0.00      3.96      0.00  java
      03:02:03 PM     0     16066      0.00     35.64      0.00  cmagent
      
      03:02:03 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
      03:02:04 PM     0       816      0.00   1924.00      0.00  jbd2/vda1-8
      03:02:04 PM   997      7326      0.00  11156.00   1888.00  java
      03:02:04 PM   997      8539      0.00      4.00      0.00  java

      • UID
      • PID
      • kB_rd/s: 每秒进程从磁盘读取的数据量 KB 单位 read from disk each second KB
      • kB_wr/s: 每秒进程向磁盘写的数据量 KB 单位 write to disk each second KB
      • kB_ccwr/s: 每秒进程向磁盘写入，但是被取消的数据量，This may occur when the task truncates some dirty pagecache.
      • iodelay: Block I/O delay, measured in clock ticks
      • Command: 进程名 task name

      2、统计CPU使用情况

      # 统计CPU
      pidstat -u 1 10
      03:03:33 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
      03:03:34 PM     0      2321    3.96    0.00    0.00    3.96     0  ansible
      03:03:34 PM     0      7110    0.00    0.99    0.00    0.99     4  pidstat
      03:03:34 PM   997      8539    0.99    0.00    0.00    0.99     5  java
      03:03:34 PM   984     15517    0.99    0.00    0.00    0.99     5  java
      03:03:34 PM     0     24406    0.99    0.00    0.00    0.99     5  java
      03:03:34 PM     0     32158    3.96    0.00    0.00    3.96     2  ansible

      • UID
      • PID
      • %usr: 进程在用户空间占用 cpu 的百分比
      • %system: 进程在内核空间占用 CPU 百分比
      • %guest: 进程在虚拟机占用 CPU 百分比
      • %wait: 进程等待运行的百分比
      • %CPU: 进程占用 CPU 百分比
      • CPU: 处理进程的 CPU 编号
      • Command: 进程名

      3. Statistik penggunaan memori

      # 统计内存
      pidstat -r 1 10
      Average:      UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
      Average:        0         1      0.20      0.00  191256   3064   0.01  systemd
      Average:        0      1007      1.30      0.00  143256  22720   0.07  AliYunDun
      Average:        0      6642      0.10      0.00 6301904 107680   0.33  java
      Average:      997      7326     10.89      0.00 13468904 8395848  26.04  java
      Average:        0      7795    348.15      0.00  108376   1233   0.00  pidstat
      Average:      997      8539      0.50      0.00 8242256 2062228   6.40  java
      Average:      987      9518      0.20      0.00 6300944 1242924   3.85  java
      Average:        0     10280      3.70      0.00  807372   8344   0.03  aliyun-service
      Average:      984     15517      0.40      0.00 6386464 1464572   4.54  java
      Average:        0     16066    236.46      0.00 2678332  71020   0.22  cmagent
      Average:      995     20955      0.30      0.00 6312520 1408040   4.37  java
      Average:      995     20956      0.20      0.00 6093764 1505028   4.67  java
      Average:        0     23936      0.10      0.00 5302416 110804   0.34  java
      Average:        0     24406      0.70      0.00 10211672 2361304   7.32  java
      Average:        0     26870      1.40      0.00 1470212  36084   0.11  promtail

      • UID
      • PID
      • Minflt/s : 每秒次缺页错误次数 （minor page faults），虚拟内存地址映射成物理内存地址产生的 page fault 次数
      • Majflt/s : 每秒主缺页错误次数 (major page faults), 虚拟内存地址映射成物理内存地址时，相应 page 在 swap 中
      • VSZ virtual memory usage : 该进程使用的虚拟内存 KB 单位
      • RSS : 该进程使用的物理内存 KB 单位
      • %MEM : 内存使用率
      • Command : 该进程的命令 task name

      4、查看具体进程使用情况

      pidstat -T ALL -r -p 20955 1 10
      03:12:16 PM   UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
      03:12:17 PM   995     20955      0.00      0.00 6312520 1408040   4.37  java
      
      03:12:16 PM   UID       PID minflt-nr majflt-nr  Command
      03:12:17 PM   995     20955         0         0  java

Atas ialah kandungan terperinci Ringkasan pengalaman penalaan menyeluruh prestasi Linux. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!