Cualquier idea de alguien con un poco de experiencia en el sistema Linux IO sería útil. Aquí está mi historia:
Recientemente saqué un grupo de seis Dell PowerEdge rx720xds para servir archivos a través de Ceph. Estas máquinas tienen 24 núcleos en dos zócalos con dos zonas numa y 70 gigabytes impares de memoria. Los discos están formateados como incursiones de un disco cada uno (de lo contrario, no podríamos ver una manera de exponerlos directamente). La conexión en red es proporcionada por mellanox infiniband IP sobre IB (los paquetes IP se convierten en IB en la tierra del kernel, no en el hardware).
Tenemos cada una de nuestras unidades SAS montadas así:
# cat /proc/mounts | grep osd
/dev/sdm1 /var/lib/ceph/osd/ceph-90 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdj1 /var/lib/ceph/osd/ceph-87 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdu1 /var/lib/ceph/osd/ceph-99 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdd1 /var/lib/ceph/osd/ceph-82 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdk1 /var/lib/ceph/osd/ceph-88 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdl1 /var/lib/ceph/osd/ceph-89 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdh1 /var/lib/ceph/osd/ceph-86 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdo1 /var/lib/ceph/osd/ceph-97 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdc1 /var/lib/ceph/osd/ceph-81 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdb1 /var/lib/ceph/osd/ceph-80 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sds1 /var/lib/ceph/osd/ceph-98 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdn1 /var/lib/ceph/osd/ceph-91 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sde1 /var/lib/ceph/osd/ceph-83 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdq1 /var/lib/ceph/osd/ceph-93 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdg1 /var/lib/ceph/osd/ceph-85 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdt1 /var/lib/ceph/osd/ceph-95 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdf1 /var/lib/ceph/osd/ceph-84 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdr1 /var/lib/ceph/osd/ceph-94 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdi1 /var/lib/ceph/osd/ceph-96 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdp1 /var/lib/ceph/osd/ceph-92 xfs rw,noatime,attr2,inode64,noquota 0 0
El IO que pasa por estas máquinas explota a unos pocos cientos de MB / s, pero la mayoría de las veces está inactivo con muchos pequeños 'pokes':
# iostat -x -m
Linux 3.10.0-123.el7.x86_64 (xxx) 07/11/14 _x86_64_ (24 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.82 0.00 1.05 0.11 0.00 97.02
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.11 0.25 0.23 0.00 0.00 27.00 0.00 2.07 3.84 0.12 0.61 0.03
sdb 0.02 0.57 3.49 2.28 0.08 0.14 77.18 0.01 2.27 2.99 1.18 1.75 1.01
sdd 0.03 0.65 3.93 3.39 0.10 0.16 70.39 0.01 1.97 2.99 0.79 1.57 1.15
sdc 0.03 0.60 3.76 2.86 0.09 0.13 65.57 0.01 2.10 3.02 0.88 1.68 1.11
sdf 0.03 0.63 4.19 2.96 0.10 0.15 73.51 0.02 2.16 3.03 0.94 1.73 1.24
sdg 0.03 0.62 3.93 3.01 0.09 0.15 70.44 0.01 2.06 3.01 0.81 1.66 1.15
sde 0.03 0.56 4.35 2.61 0.10 0.14 69.53 0.02 2.26 3.00 1.02 1.82 1.26
sdj 0.02 0.73 3.67 4.74 0.10 0.37 116.06 0.02 1.84 3.01 0.93 1.31 1.10
sdh 0.03 0.62 4.31 3.04 0.10 0.15 67.83 0.02 2.15 3.04 0.89 1.75 1.29
sdi 0.02 0.59 3.82 2.47 0.09 0.13 74.35 0.01 2.20 2.96 1.03 1.76 1.10
sdl 0.03 0.59 4.75 2.46 0.11 0.14 70.19 0.02 2.33 3.02 1.00 1.93 1.39
sdk 0.02 0.57 3.66 2.41 0.09 0.13 73.57 0.01 2.20 3.00 0.97 1.76 1.07
sdm 0.03 0.66 4.03 3.17 0.09 0.14 66.13 0.01 2.02 3.00 0.78 1.64 1.18
sdn 0.03 0.62 4.70 3.00 0.11 0.16 71.63 0.02 2.25 3.01 1.05 1.79 1.38
sdo 0.02 0.62 3.75 2.48 0.10 0.13 76.01 0.01 2.16 2.94 0.99 1.70 1.06
sdp 0.03 0.62 5.03 2.50 0.11 0.15 68.65 0.02 2.39 3.08 0.99 1.99 1.50
sdq 0.03 0.53 4.46 2.08 0.09 0.12 67.74 0.02 2.42 3.04 1.09 2.01 1.32
sdr 0.03 0.57 4.21 2.31 0.09 0.14 72.05 0.02 2.35 3.00 1.16 1.89 1.23
sdt 0.03 0.66 4.78 5.13 0.10 0.20 61.78 0.02 1.90 3.10 0.79 1.49 1.47
sdu 0.03 0.55 3.93 2.42 0.09 0.13 70.77 0.01 2.17 2.97 0.85 1.79 1.14
sds 0.03 0.60 4.11 2.70 0.10 0.15 74.77 0.02 2.25 3.01 1.10 1.76 1.20
sdw 1.53 0.00 0.23 38.90 0.00 1.66 87.01 0.01 0.22 0.11 0.22 0.05 0.20
sdv 0.88 0.00 0.16 28.75 0.00 1.19 84.55 0.01 0.24 0.10 0.24 0.05 0.14
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 1.84 1.84 0.00 1.15 0.00
dm-1 0.00 0.00 0.23 0.29 0.00 0.00 23.78 0.00 1.87 4.06 0.12 0.55 0.03
dm-2 0.00 0.00 0.01 0.00 0.00 0.00 8.00 0.00 0.47 0.47 0.00 0.45 0.00
El problema:
Después de aproximadamente 48 horas más tarde, las páginas contiguas están tan fragmentadas que magniutde cuatro (16 páginas, 65536 bytes) las asignaciones comienzan a fallar y comenzamos a soltar paquetes (debido a la falla de kalloc cuando crece una SLAB).
Así es como se ve un servidor relativamente "saludable":
# cat /sys/kernel/debug/extfrag/unusable_index
Node 0, zone DMA 0.000 0.000 0.000 0.001 0.003 0.007 0.015 0.031 0.031 0.096 0.225
Node 0, zone DMA32 0.000 0.009 0.015 0.296 0.733 0.996 0.997 0.998 0.998 1.000 1.000
Node 0, zone Normal 0.000 0.000 0.019 0.212 0.454 0.667 0.804 0.903 0.986 1.000 1.000
Node 1, zone Normal 0.000 0.027 0.040 0.044 0.071 0.270 0.506 0.772 1.000 1.000 1.000
Cuando la fragmentación empeora considerablemente, el sistema parece comenzar a girar en el espacio del núcleo y todo se desmorona. Una anomalía durante esta falla es que xfsaild parece usar mucha CPU y se queda atascado en el estado de suspensión ininterrumpible. Sin embargo, no quiero sacar conclusiones extrañas durante una falla total del sistema.
Solución alternativa hasta ahora.
Para garantizar que estas asignaciones no fallen, incluso bajo fragmentación, establecí:
vm.min_free_kbytes = 16777216
Después de ver millones de blkdev_requests en cachés SLAB, intenté reducir las páginas sucias a través de:
vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.min_slab_ratio = 1
vm.zone_reclaim_mode = 3
Posiblemente cambiando demasiadas variables a la vez, pero en caso de que los inodes y dentries estuvieran causando fragmentación, decidí mantenerlos al mínimo:
vm.vfs_cache_pressure = 10000
Y esto pareció ayudar. Sin embargo, la fragmentación sigue siendo alta, y los problemas reducidos de inodo y nebulización significaron que noté algo extraño que me lleva a ...
Mi pregunta:
¿Por qué tengo tantas blkdev_requests (que están activas no menos), que simplemente desaparecen cuando suelto cachés?
Esto es lo que quiero decir:
# slabtop -o -s c | head -20
Active / Total Objects (% used) : 19362505 / 19431176 (99.6%)
Active / Total Slabs (% used) : 452161 / 452161 (100.0%)
Active / Total Caches (% used) : 72 / 100 (72.0%)
Active / Total Size (% used) : 5897855.81K / 5925572.61K (99.5%)
Minimum / Average / Maximum Object : 0.01K / 0.30K / 15.69K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
2565024 2565017 99% 1.00K 80157 32 2565024K xfs_inode
3295194 3295194 100% 0.38K 78457 42 1255312K blkdev_requests
3428838 3399527 99% 0.19K 81639 42 653112K dentry
5681088 5680492 99% 0.06K 88767 64 355068K kmalloc-64
2901366 2897861 99% 0.10K 74394 39 297576K buffer_head
34148 34111 99% 8.00K 8537 4 273184K kmalloc-8192
334768 334711 99% 0.57K 11956 28 191296K radix_tree_node
614959 614959 100% 0.15K 11603 53 92824K xfs_ili
21263 19538 91% 2.84K 1933 11 61856K task_struct
18720 18636 99% 2.00K 1170 16 37440K kmalloc-2048
32032 25326 79% 1.00K 1001 32 32032K kmalloc-1024
10234 9202 89% 1.88K 602 17 19264K TCP
22152 19765 89% 0.81K 568 39 18176K task_xstate
# echo 2 > /proc/sys/vm/drop_caches :(
# slabtop -o -s c | head -20
Active / Total Objects (% used) : 965742 / 2593182 (37.2%)
Active / Total Slabs (% used) : 69451 / 69451 (100.0%)
Active / Total Caches (% used) : 72 / 100 (72.0%)
Active / Total Size (% used) : 551271.96K / 855029.41K (64.5%)
Minimum / Average / Maximum Object : 0.01K / 0.33K / 15.69K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
34140 34115 99% 8.00K 8535 4 273120K kmalloc-8192
143444 20166 14% 0.57K 5123 28 81968K radix_tree_node
768729 224574 29% 0.10K 19711 39 78844K buffer_head
73280 8287 11% 1.00K 2290 32 73280K xfs_inode
21263 19529 91% 2.84K 1933 11 61856K task_struct
686848 97798 14% 0.06K 10732 64 42928K kmalloc-64
223902 41010 18% 0.19K 5331 42 42648K dentry
32032 23282 72% 1.00K 1001 32 32032K kmalloc-1024
10234 9211 90% 1.88K 602 17 19264K TCP
22152 19924 89% 0.81K 568 39 18176K task_xstate
69216 59714 86% 0.25K 2163 32 17304K kmalloc-256
98421 23541 23% 0.15K 1857 53 14856K xfs_ili
5600 2915 52% 2.00K 350 16 11200K kmalloc-2048
Esto me dice que la acumulación de blkdev_request no está relacionada con páginas sucias y, además, que los objetos activos no están realmente activos. ¿Cómo se pueden liberar estos objetos si de hecho no están en uso? ¿Que esta pasando aqui?
Para algunos antecedentes, esto es lo que está haciendo drop_caches:
http://lxr.free-electrons.com/source/fs/drop_caches.c
Actualizar:
¿Resolvió que podrían no ser blkdev_requests, pero pueden ser entradas xfs_buf que aparecen debajo de ese 'encabezado'? No estoy seguro de cómo funciona esto:
/sys/kernel/slab # ls -l blkdev_requests(
lrwxrwxrwx 1 root root 0 Nov 7 23:18 blkdev_requests -> :t-0000384/
/sys/kernel/slab # ls -l | grep 384
lrwxrwxrwx 1 root root 0 Nov 7 23:18 blkdev_requests -> :t-0000384/
lrwxrwxrwx 1 root root 0 Nov 7 23:19 ip6_dst_cache -> :t-0000384/
drwxr-xr-x 2 root root 0 Nov 7 23:18 :t-0000384/
lrwxrwxrwx 1 root root 0 Nov 7 23:19 xfs_buf -> :t-0000384/
Todavía no sé por qué estos son eliminados por 'drop_slabs', o cómo averiguar qué está causando esta fragmentación.
Pregunta adicional: ¿Cuál es una mejor manera de llegar al origen de esta fragmentación?
Si lees hasta aquí, ¡gracias por tu atención!
Información adicional solicitada:
Información de memoria y xfs: https://gist.github.com/christian-marie/f417cc3134544544a8d1
Error de asignación de página: https://gist.github.com/christian-marie/7bc845d2da7847534104
Seguimiento: información de rendimiento y cosas relacionadas con la compactación
http://ponies.io/raw/compaction.png
El código de compactación parece un poco ineficiente, ¿eh? He improvisado un código para intentar replicar las compactaciones fallidas: https://gist.github.com/christian-marie/cde7e80c5edb889da541
Esto parece reproducir el problema.
Notaré también que un seguimiento de evento me dice que hay muchas reclamaciones fallidas, una y otra vez:
<...>-322 [023] .... 19509.445609: mm_vmscan_direct_reclaim_end: nr_reclaimed=1
La salida de Vmstat también es preocupante. Mientras el sistema se encuentra en este estado de alta carga, las compactaciones están atravesando el techo (y fallando principalmente):
pgmigrate_success 38760827
pgmigrate_fail 350700119
compact_migrate_scanned 301784730
compact_free_scanned 204838172846
compact_isolated 18711615
compact_stall 270115
compact_fail 244488
compact_success 25212
De hecho, hay algo mal con la recuperación / compactación.
Por el momento, estoy buscando reducir las asignaciones de alto orden al agregar soporte SG a nuestra configuración de ipoib. El problema real parece probablemente relacionado con vmscan.
Esto es interesante y hace referencia a esta pregunta: http://marc.info/?l=linux-mm&m=141607142529562&w=2
fuente
/proc/buddyinfoy los resultados defree -m? Las solicitudes blockdev probablemente se representan como buffers enfree. Ah, y la distribución que estás usando también sería buena. Además, ¿page allocation failureaparece algún mensajedmesg? Si es así, proporcione el resultado más cualquier contexto relevante.mkfs.xfslínea de comando específica ? ¿Grandes páginas habilitadas?/proc/meminfoRespuestas:
Pensé en poner una respuesta con mis observaciones porque hay muchos comentarios.
Basado en su salida en https://gist.github.com/christian-marie/7bc845d2da7847534104
Podemos determinar lo siguiente:
La fragmentación de zona es la ubicación aquí:
Y la utilización de la memoria en ese momento está aquí:
La fragmentación de cada zona es mala en la salida de falla de asignación de página. Hay muchas páginas de pedido gratis 0 con páginas de pedido mucho menor o ninguna. Un "buen" resultado será una gran cantidad de páginas gratuitas a lo largo de cada pedido, disminuyendo gradualmente su tamaño a medida que avanza el pedido. Tener 0 páginas de orden superior 5 y superiores indica fragmentación e inanición para asignaciones de orden superior.
Actualmente no veo un grado convincente de evidencia que sugiera que la fragmentación durante este período tenga algo que ver con los escondites de losas. En las estadísticas de memoria resultantes, podemos ver lo siguiente
No hay grandes páginas asignadas desde el espacio de usuario, y el espacio de usuario siempre reclamará memoria de orden 0. Por lo tanto, en ambas zonas hay más de 22 GiB de memoria desfragmentable.
Comportamientos que no puedo explicar
Cuando las asignaciones de alto orden fallan, tengo entendido que la compactación de memoria siempre se intenta para permitir que las regiones de asignación de memoria de alto orden tengan lugar y tengan éxito. ¿Por qué esto no sucede? Si sucede, ¿por qué no puede encontrar memoria para desfragmentar cuando hay 22 GiB de capacidad para reordenar?
Comportamientos que creo que puedo explicar
Esto necesita más investigación para comprenderlo correctamente, pero creo que la capacidad de la asignación de intercambiar / soltar automáticamente un caché de página para tener éxito probablemente no se aplique aquí porque todavía hay mucha memoria libre disponible, por lo que no se producen reclamos. Simplemente no es suficiente en las órdenes superiores.
Si bien hay mucha memoria libre y quedan pocas solicitudes de 4 pedidos en cada zona, el problema "total de memoria libre para cada pedido y deducir de la memoria libre real" da como resultado una "memoria libre" debajo de la marca de agua "min", que es lo que lleva a la falla de asignación real.
fuente
numadejecutando en este sistema?numadservicio y tome nota de las acciones en/var/log/numad.log. También es posible que necesite instalar libcgroup.