Linux Kernel Technology 5 Page Cache - ¿Cómo juzgar si el problema es causado por Page Cache?

Cómo identificar si el título es causado por Page Cache

Sabemos que la ocurrencia de un problema muchas veces involucra a muchos módulos del sistema operativo, por ejemplo, cuando el sistema tiene un problema de alta carga, puede ser causado por el Page Cache, también puede ser que el conflicto de bloqueo sea demasiado severo. , los recursos físicos (CPU, memoria, E/S de disco, E/S de red) es causado por contención; también puede ser causado por fallas de diseño en las características del kernel.

Cuando ocurre un problema, debemos identificar la causa del problema para poder prescribir el remedio correcto. Adoptar estrategias a ciegas puede empeorar nuestro sistema.

Métodos de análisis típicos de Linux
/proc y /sys
El kernel de Linux exporta principalmente información del sistema a los usuarios a través de /proc y /sys

¿Cómo juzgar aproximadamente si el problema es causado por Page Cache
? Podemos leer el cambio de pgscan en proc/vmstat por unidad de tiempo . Si el cambio es demasiado grande, significa que el problema puede ser causado por Page Cache, porque pgscan representa la recuperación de memoria de Page Cache Behavior , varía más a menudo significa que la presión de la memoria del sistema es muy estrecha.

imagen.png

Cómo analizar el problema La
información en /proc y /sys puede indicarnos una dirección general de análisis del problema, y ​​podemos juzgar si el problema es causado por Page Cache. Luego, podemos usar algunas herramientas profesionales (como ftrace, ebpf, perf, etc.) para realizar un análisis más profundo del problema para comprender cómo surge el problema.

Cómo elegir la herramienta adecuada para
el seguimiento estático (con puntos de seguimiento preestablecidos) y el seguimiento dinámico (con la ayuda de una sonda)
Si lo que desea rastrear ya tiene puntos de seguimiento preestablecidos, puede usar estos puntos de seguimiento preestablecidos directamente; no hay un punto de seguimiento preestablecido, entonces debe ver si puede usar la sonda (incluidos kprobe y uprobe) para lograrlo.

Cabe señalar que la herramienta de análisis en sí misma también tendrá algún impacto en el negocio (Heisenbug) ; por ejemplo, usar strace bloqueará la ejecución del proceso y, por ejemplo, usar systemtap también tendrá la sobrecarga de carga y compilación . por lo que usamos estas herramientas antes También es necesario comprender los efectos secundarios de estas herramientas en detalle, para no causar problemas inesperados.

imagen.png

La carga del sistema de análisis de problemas en tiempo real
es muy alta ¿Se debe a la caché de páginas?
1. Prioridad para usar las herramientas propias del sistema para verificar la descripción general, fácil de comenzar:

sar -B #分析分页信息 (Paging statistics)
sar -r #分析内存使用情况统计 (Memory utilization statistics) 
复制代码

Después del kernel 4.20 de Linu, si sar también se actualiza a la versión 12.3.3, podemos usar la nueva función PSI de sar, y esta información también se registrará en el archivo /proc/pression:

formato de CPU

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
复制代码

Tenemos que centrarnos en la columna avg10, que indica la presión media de la memoria en los últimos 10. Si es grande (por ejemplo, superior a 40 ), la alta se debe a la presión de la memoria, especialmente la presión de la memoria caché de la página.

Documentación de referencia: PSI - Información de bloqueo de presión: la documentación del kernel de Linux

2.采集指标,定位问题点
sar 采集的只是一些常用的指标,它并没有覆盖 Page Cache 的所有行为,比如说内存规整(memory compaction)、业务 workingset 等这些容易引起 load 飙高的问题点。

采集完这些指标后,我们就可以分析 Page Cache 异常是由什么引起的了。 举个例子,当单位时间内 compact_fail 变化很大时,说明碎片整理失败次数很多,也意味着系统内存碎片很严重,已经很难申请到连续物理内存了,这时你就需要去调整碎片指数或者手动触发内存规整,来减缓因为内存碎片引起的压力了。

Page Cache常见指标速查

imagen.png

3.打破砂锅问到底,进一步分析问题
针对上面那个问题,我们需要知道是什么东西在进行连续内存的申请,从而来做更加有针对性的调整,这就需要进行进一步的观察了。

利用内核预置的相关 tracepoint 来做更加细致的分析

imagen.png

计算内存规整带来的延迟
内存规整 (memory compaction) 为例,来看下如何利用 tracepoint 来对它进行观察:

#触发compaction相关时间
$ echo 1 >
/sys/kernel/debug/tracing/events/compaction/mm_compaction_begin/enable
$ echo 1 >
/sys/kernel/debug/tracing/events/compaction/mm_compaction_end/enable 

#然后来读取信息,当compaction事件触发后就会有信息输出
$ cat /sys/kernel/debug/tracing/trace_pipe
 <...>-49355 [037] .... 1578020.975159: mm_compaction_begin: 
zone_start=0x2080000 migrate_pfn=0x2080000 free_pfn=0x3fe5800 
zone_end=0x4080000, mode=async
 <...>-49355 [037] .N.. 1578020.992136: mm_compaction_end: 
zone_start=0x2080000 migrate_pfn=0x208f420 free_pfn=0x3f4b720 
zone_end=0x4080000, mode=async status=contended
复制代码

可以看到是 49355 这个进程触发了 compaction,begin 和 end 这两个 tracepoint 触发的时间戳相减,就可以得到 compaction 给业务带来的延迟,我们可以计算出这一次的延迟为 17ms.

A veces recopilamos demasiados datos y, a menudo, necesitamos herramientas de análisis automatizadas que nos ayuden a analizar problemas, como: perf-script(1): página del manual de Linux (man7.org)

El valor de carga del sistema de análisis de problemas históricos
se disparó ayer. ¿Es causado por la memoria caché de la página?
Para problemas en tiempo real, es relativamente fácil de analizar porque hay información en el sitio para recopilar.
Pero a veces, no tenemos forma de recopilar información en el sitio de manera oportuna. Por ejemplo, cuando ocurre un problema a altas horas de la noche, no tenemos tiempo para recopilar información en el sitio. En este momento, solo podemos ver el historial. registros.

Información de registro de sar
Podemos juzgar lo que sucedió en ese momento en función de la información de registro de sar. Por ejemplo, nuestro sistema comercial experimentó fluctuación de RT anoche. Al ver el registro, descubrimos que el tiempo de fluctuación de RT comercial y pgscand en sar-B eran no 0. Los momentos coinciden en muchos momentos . Por lo tanto, podemos inferir que el jitter empresarial puede estar relacionado con el reciclaje de Page Cache.Podemos intentar aumentar vm.min_free_kbytes para verificar el efecto y ver si todavía hay jitter en el negocio.

Sugerencias: Ajustar vm.min_free_kbytes tendrá algunos riesgos. Si el sistema en sí ya está muy nervioso acerca de la recuperación de la memoria, es muy probable que ajustarlo a un valor mayor active OOM o incluso provoque un tiempo de inactividad del sistema. Así que asegúrese de hacer algunas comprobaciones primero para ver si se puede ajustar en este momento.

Suplemento del comando sar : 20 ejemplos de comandos sar en Linux [Hoja de referencia] | GoLinuxCloud

Supongo que te gusta

Origin juejin.im/post/7102678421448163364
Recomendado
Clasificación