Bahagian1Pengoptimuman Prestasi Linux

1Pengoptimuman Prestasi

1

Pengoptimuman Prestasi

• application loadangle: Secara langsung mempengaruhi pengalaman pengguna produk terminal
• system produk: penggunaan sumber, ketepuan, dan lain -lain.
Intipati masalah prestasi

• 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

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

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)

• 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

  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

  Salin selepas log masuk

  • cs (suis konteks) Bilangan suis konteks sesaat
  • ) Bilangan sampukan sesaat
  • r (berjalan atau boleh dijalankan) Panjang baris gilir sedia, bilangan proses berjalan dan menunggu CPU
  • b (Disekat) Bilangan proses dalam keadaan tidur tidak terganggu

  Untuk melihat butiran setiap proses Dalam kes ini, 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

  Salin selepas log masuk

  • 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列： 中断次数明显上升，说明中断处理也是潜在问题

  Salin selepas log masuk

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

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

  Salin selepas log masuk

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

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

  watch -d cat /proc/interrupts

  Salin selepas log masuk

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

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

  Salin selepas log masuk

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

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

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

  Salin selepas log masuk

  发现其中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个请求测试

  Salin selepas log masuk

  实验结果中每秒请求数依旧不高，我们将并发请求数降为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

  Salin selepas log masuk

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

  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.

对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了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升高。

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

Gambar 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

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 QPS
  QPS (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.

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 rendah
  Timbunan 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:

• 回收缓存：LRU算法回收最近最少使用的内存页面；

• 回收不常访问内存：把不常用的内存通过交换分区写入磁盘

• 杀死进程：OOM内核保护机制 （进程消耗内存越大oom_score越大，占用CPU越多oom_score越小，可以通过/proc手动调整oom_adj）

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

  Salin selepas log masuk

如何查看内存使用情况

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

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

• VIRT Saiz memori maya proses
• 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

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

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

Kebocoran memori terkumpul malah boleh menghabiskan memori sistem ekzos.

如何检测内存泄漏

预先安装systat，docker，bcc

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

可以看到free在不断下降，buffer和cache基本保持不变。说明系统的内存一致在升高。但并不能说明存在内存泄漏。此时可以通过memleak工具来跟踪系统或进程的内存分配/释放请求

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

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

为什么系统的Swap变高

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

• 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

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

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 #观察内存指标变化
#发现升级内存在一个小范围不停的波动，低于页低阈值时会突然增大到一个大于页高阈值的值