Maison > Article > Opération et maintenance > Résumé de l'expérience de réglage complet des performances Linux

Résumé de l'expérience de réglage complet des performances Linux

Linux中文社区avant: 2023-08-03 14:59:491154parcourir

Partie 1Optimisation des performances Linux

1Optimisation des performances

Indicateurs de performance

Concentration élevée L'urgence et la réponse rapide correspondent à deux indicateurs clés de l'optimisation des performances : Débit et Latence

Résumé de l'expérience de réglage complet des performances Linux — Photos de : www.ctq6.cn

Charge de l'applicationAngle : affecte directement l'expérience utilisateur du terminal du produit
Ressources systèmeAngle : utilisation des ressources, saturation L'essence du problème de performances est que les ressources système ont atteint le goulot d'étranglement, mais le traitement des demandes n'est pas assez rapide pour prendre en charge davantage de demandes. L'analyse des performances consiste en fait à détecter les goulots d'étranglement de l'application ou du système et à essayer de les éviter ou de les atténuer.
- Choisir des métriques pour évaluer les performances des applications et des systèmes
- Définir des objectifs de performances pour les applications et les systèmes
- Effectuer des tests de performance
- Analyse des performances pour localiser les goulots d'étranglement
- Surveillance et alerte des performances
Pour différents problèmes de performances, différents outils d'analyse des performances doivent être sélectionnés. Les éléments suivants sont les outils de performances Linux couramment utilisés et les types correspondants de problèmes de performances analysés.

Photo de : www.ctq6.cn
Comment devrions-nous comprendre la "charge moyenne"

Charge moyenne : Le processus moyen du système dans un état exécutable et un état ininterrompu dans un nombre d'unités de temps, qui est le nombre moyen de processus actifs. Cela n’est pas directement lié à l’utilisation du processeur telle que nous l’entendons traditionnellement.

Le processus ininterruptible est un processus qui se trouve dans un processus critique dans l'état du noyau (comme la réponse d'E/S commune en attente du périphérique). L'état ininterruptible est en fait un mécanisme de protection du système pour les processus et les périphériques matériels.

Quelle est la charge moyenne raisonnable ?

Dans l'environnement de production réel, surveillez la charge moyenne du système et jugez la tendance des changements de charge en fonction des données historiques. Lorsqu’il y a une tendance évidente à la hausse de la charge, effectuez une analyse et une enquête en temps opportun. Bien sûr, vous pouvez également définir un seuil (comme lorsque la charge moyenne est supérieure à 70% du nombre de CPU)

Dans le vrai travail, on confond souvent les notions de charge moyenne et d'utilisation du CPU. les deux ne sont pas complètement équivalents :
- Processus gourmands en CPU, une grande quantité d'utilisation du CPU entraînera une augmentation de la charge moyenne, à ce moment-là, les deux sont cohérents
- Processus gourmands en E/S, l'attente des E/S sera également entraînera une augmentation de la charge moyenne, cela L'utilisation du processeur n'est pas nécessairement élevée
- Un grand nombre de processus en attente de planification du processeur entraînera une augmentation de la charge moyenne. À ce stade, l'utilisation du processeur sera également relativement élevée.
Lorsque la charge moyenne du processeur est élevée, il se peut que le processeur soit causé par des processus intensifs ou des E/S occupées. Lors d'une analyse spécifique, vous pouvez combiner l'outil mpstat/pidstat pour vous aider à analyser la source de charge

2CPU

Changement de contexte CPU (Partie 1)

Le changement de contexte CPU consiste à enregistrer le contexte CPU (registre CPU et PC) de la tâche précédente, puis à charger la nouvelle tâche. contexte à ces registres et au compteur de programme, et passe enfin à l'emplacement indiqué par le compteur de programme pour exécuter la nouvelle tâche. Parmi eux, le contexte enregistré sera stocké dans le noyau du système et chargé à nouveau lorsque la tâche sera reprogrammée pour exécution afin de garantir que l'état d'origine de la tâche ne soit pas affecté.

Selon le type de tâche, la commutation de contexte CPU est divisée en :
Commutation de contexte de processus Le processus ux suit Les autorisations de niveau divisent l'espace d'exécution d'un processus dans l'espace noyau et l'espace utilisateur. La transition du mode utilisateur au mode noyau doit être effectuée via des appels système.
- Un processus d'appel système effectue en fait deux changements de contexte CPU :
  - L'emplacement de l'instruction en mode utilisateur dans le registre CPU est enregistré en premier, le registre CPU est mis à jour à l'emplacement de l'instruction en mode noyau et passe à l'état du noyau pour exécuter la tâche du noyau
  - ; Une fois l'appel système terminé, le registre du processeur revient à son état d'origine. Enregistrez les données du mode utilisateur, puis passez à l'espace utilisateur pour continuer à fonctionner.
  Le processus d'appel système n'implique pas de ressources en mode utilisateur de processus telles que la mémoire virtuelle, et ne change pas non plus de processus. Cela diffère du changement de contexte de processus au sens traditionnel du terme. C'est pourquoi l'appel système est souvent appelé commutateur de mode privilégié .
  
  Les processus sont gérés et planifiés par le noyau, et le changement de contexte de processus ne peut se produire qu'en mode noyau. Par conséquent, par rapport aux appels système, avant de sauvegarder l'état du noyau et les registres du processeur du processus en cours, la mémoire virtuelle et la pile du processus doivent d'abord être enregistrées. Après avoir chargé l'état du noyau du nouveau processus, la mémoire virtuelle et la pile utilisateur du processus doivent être actualisées.
  
  Le processus n'a besoin de changer de contexte que lorsqu'il est programmé pour s'exécuter sur le processeur. Il existe les scénarios suivants : les tranches de temps du processeur sont allouées à tour de rôle, des ressources système insuffisantes entraînent le blocage du processus, le processus se bloque activement pendant le processus. fonction de veille et processus hautement prioritaires Tranche de temps de préemption, lorsque le matériel s'interrompt, le processus sur le processeur est suspendu et exécute à la place le service d'interruption dans le noyau.
  
  Changement de contexte de thread
  
  Le changement de contexte de thread est divisé en deux types :
  - Les threads avant et arrière appartiennent au même processus. Les ressources de mémoire virtuelle restent inchangées pendant le changement, et seules les ressources privées du thread. les données, les registres, etc. doivent être commutés ;
  - Les threads avant et arrière appartiennent à des processus différents, ce qui revient à changer de contexte de processus.
  Le changement de thread dans le même processus consomme moins de ressources, ce qui est également l'avantage du multi-thread.
  
  Changement de contexte d'interruption
  
  Le changement de contexte d'interruption n'implique pas l'état utilisateur du processus, donc le contexte d'interruption inclut uniquement l'état nécessaire à l'exécution du programme de service d'interruption d'état du noyau (registres CPU, pile du noyau, interruption matérielle paramètres, etc).
  
  La priorité du traitement des interruptions est supérieure à celle du processus, donc le changement de contexte d'interruption et le changement de contexte de processus ne se produiront pas en même temps
  
  Docker+K8s+Jenkins, informations vidéo complètes sur la technologie grand public
  
  Changement de contexte CPU (Partie 2)
  
  Vous pouvez vérifier la situation globale de changement de contexte du système via 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 (changement de contexte) Nombre de changements de contexte par seconde
  - in (interruption) Nombre d'interruptions par seconde
  - r (en cours d'exécution ou exécutable) La longueur de la file d'attente prête, en cours d'exécution et en attente Le nombre de processus dans le CPU
  - b (bloqué) Le nombre de processus en état de veille ininterrompue
  Pour afficher les détails de chaque processus, vous devez utiliser pidstat pour afficher le changement de contexte de chaque processus
```
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，通过修复权限问题来优化解决即可.
  
  Que dois-je faire s'il y a un grand nombre de processus ininterruptibles et de processus zombies dans le système ?
  
  Statut du processus
  - R En cours d'exécution/Runnable, indiquant que le processus est dans la file d'attente prête du processeur, en cours d'exécution ou en attente d'exécution
  - D Veille du disque, état de veille ininterrompue, indiquant généralement ; un processus Il interagit avec le matériel et ne peut pas être interrompu par d'autres processus pendant l'interaction
  - Z Zombie, un processus zombie, signifie que le processus est effectivement terminé, mais que le processus parent n'a pas récupéré ; ses ressources ;
  - S Le sommeil interrompu, qui peut interrompre l'état de veille, signifie que le processus est suspendu par le système car il attend un événement. Lorsque l'événement en attente se produit, il sera réveillé et entrera dans le système. État R ;
  - I Idle, état inactif, utilisé dans les threads du noyau en veille ininterrompue.该状态不会导致平均负载升高；
  - 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 &#39;/app&#39;
```
  可以看到此时有多个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。然后定位到具体代码位置进行优化即可。
  
  Processus zombies
  
  Après l'optimisation ci-dessus, iowait a considérablement diminué, mais le nombre de processus zombies continue d'augmenter. Tout d'abord, localisez le processus parent du processus zombie. Utilisez pstree -aps XXX pour imprimer l'arborescence des appels du processus zombie et constatez que le processus parent est le processus d'application.
  
  Vérifiez le code de l'application pour voir si la fin du processus enfant est gérée correctement (si wait()/waitpid() est appelé, si une fonction de traitement du signal SIGCHILD est enregistrée, etc.).
  
  Lorsque vous rencontrez une augmentation de l'iowait, utilisez d'abord des outils tels que dstat et pidstat pour confirmer s'il y a un problème d'E/S de disque, puis découvrez quels processus sont à l'origine de l'E/S si vous ne pouvez pas utiliser strace. pour analyser directement l'appel de processus, vous pouvez utiliser l'outil perf pour l'analyser.
  
  Pour le problème zombie, utilisez pstree pour trouver le processus parent, puis regardez le code source pour vérifier la logique de traitement pour la fin du processus enfant.
  
  Mesures de performances du processeur
  - Utilisation du processeur
  - Changement de contexte de processus
    
    Y compris la commutation volontaire lorsque les ressources ne peuvent pas être obtenues et la commutation involontaire lorsque le système force la planification. La commutation de contexte elle-même est une fonction essentielle pour garantir le fonctionnement normal de Linux. Une commutation excessive consommera le temps CPU du processus en cours d'exécution d'origine dans le registre. Noyau et mémoire virtuelle et autres sauvegardes et récupérations de données. De plus, parcourez les coulisses du programmeur de comptes publics Xiaole pour répondre aux « questions d'entretien » et obtenez un coffret cadeau surprise.
  - Taux de réussite du cache CPU
    
    Réutilisation du cache CPU, plus le taux de réussite est élevé, meilleures sont les performances Parmi eux, L1/L2 est couramment utilisé en monocœur et L3 est utilisé en multi. -core
    "Outils de performances" pid après avoir jugé la charge, les statistiques vérifient chacun. Processeurs et utilisation du processeur par processus. Découvrez les processus provoquant une charge moyenne plus élevée
  Cas de changement de contexte
  - Cas d'utilisation élevée du processeur du processus
  - cas d'utilisation élevée du processeur du système
  - Cas de processus ininterruptibles et zombies
  - cas d'interruption logicielle
  Trouvez le bon outil en fonction de différents indicateurs de performance :
  
  Photo de : www. ctq6.cn
  Dans un environnement de production, les développeurs n'ont souvent pas l'autorisation d'installer de nouveaux packages d'outils et ne peuvent que maximiser l'utilisation des outils déjà installés dans le système. Par conséquent, il est nécessaire de comprendre ce que certains indicateurs analysent. les outils peuvent fournir.
  
  Photos de : www.ctq6.cn
  Exécutez d'abord plusieurs outils qui prennent en charge plus d'indicateurs, tels que top/vmstat/pidstat. En fonction de leur sortie, vous pouvez déterminer de quel type de problème de performances il s'agit. Après avoir localisé le processus, utilisez strace/perf pour analyser la situation d'appel pour une analyse plus approfondie. Si elle est causée par une interruption logicielle, utilisez /proc/softirqs
  .
  Photos de : www.ctq6.cn
  Optimisation du processeur
  - Optimisation des applications

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration：

Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer

Article précédent：Linux - 11 étapes pour vous apprendre à vérifier parfaitement si votre serveur a été compromisArticle suivant：Linux - 11 étapes pour vous apprendre à vérifier parfaitement si votre serveur a été compromis

Articles Liés

Voir plus

Résumé de l'expérience de réglage complet des performances Linux

Partie 1Optimisation des performances Linux

1Optimisation des performances

Indicateurs de performance

Comment devrions-nous comprendre la "charge moyenne"

Quelle est la charge moyenne raisonnable ?

2CPU

Changement de contexte CPU (Partie 1)

Changement de contexte de thread

Changement de contexte d'interruption

Changement de contexte CPU (Partie 2)

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

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

Que dois-je faire s'il y a un grand nombre de processus ininterruptibles et de processus zombies dans le système ?

Statut du processus

磁盘O_DIRECT问题

Processus zombies

Mesures de performances du processeur

Optimisation du processeur

3Mémoire

Comment fonctionne la mémoire Linux

Mappage de la mémoire

Répartition de l'espace mémoire virtuelle

Allocation et recyclage de mémoire

allocation

Recyclage

如何查看内存使用情况

Comment comprendre le tampon et le cache de la mémoire ?

Comment utiliser le cache système pour optimiser l'efficacité de fonctionnement du programme

Taux de réussite du cache

dd缓存加速

O_DIRECT选项绕过系统缓存

Fuite mémoire, comment la localiser et y remédier ?

Allocation et recyclage de la mémoire

Comment détecter les fuites de mémoire

为什么系统的Swap变高

Principe de l'échange

NUMA 与 SWAP

swappiness

Swap升高时如何定位分析

Comment trouver rapidement et précisément les problèmes de mémoire système

Indicateurs de performances de la mémoire

Outil de performances de la mémoire

how pour analyser rapidement la mémoire Goulot d'étranglement des performances

Explication détaillée de l'utilisation de vmstat

pidstat 使用详解

Articles Liés