El servidor Linux solo usa el 60% de la memoria, luego intercambia

12

Tengo un servidor Linux que ejecuta nuestro sistema de copia de seguridad bacula. La máquina está moliendo como loca porque está cambiando mucho. ¡El problema es que solo usa el 60% de su memoria física!

Aquí está la salida de free -m:

free -m
             total       used       free     shared    buffers     cached
Mem:          3949       2356       1593          0          0          1
-/+ buffers/cache:       2354       1595
Swap:         7629       1804       5824

y algunos resultados de muestra de vmstat 1:

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 1843536 1634512      0   4188   54   13  2524   666    2    1  1  1 89  9  0
 1 11 1845916 1640724      0    388 2700 4816 221880  4879 14409 170721  4  3 63 30  0
 0  9 1846096 1643952      0      0 4956  756 174832   804 12357 159306  3  4 63 30  0
 0 11 1846104 1643532      0      0 4916  540 174320   580 10609 139960  3  4 64 29  0
 0  4 1846084 1640272      0   2336 4080  524 140408   548 9331 118287  3  4 63 30  0
 0  8 1846104 1642096      0   1488 2940  432 102516   457 7023 82230  2  4 65 29  0
 0  5 1846104 1642268      0   1276 3704  452 126520   452 9494 119612  3  5 65 27  0
 3 12 1846104 1641528      0    328 6092  608 187776   636 8269 113059  4  3 64 29  0
 2  2 1846084 1640960      0    724 5948    0 111480     0 7751 116370  4  4 63 29  0
 0  4 1846100 1641484      0    404 4144 1476 125760  1500 10668 105358  2  3 71 25  0
 0 13 1846104 1641932      0      0 5872  828 153808   840 10518 128447  3  4 70 22  0
 0  8 1846096 1639172      0   3164 3556  556 74884   580 5082 65362  2  2 73 23  0
 1  4 1846080 1638676      0    396 4512   28 50928    44 2672 38277  2  2 80 16  0
 0  3 1846080 1628808      0   7132 2636    0 28004     8 1358 14090  0  1 78 20  0
 0  2 1844728 1618552      0  11140 7680    0 12740     8  763 2245  0  0 82 18  0
 0  2 1837764 1532056      0 101504 2952    0 95644    24  802 3817  0  1 87 12  0
 0 11 1842092 1633324      0   4416 1748 10900 143144 11024 6279 134442  3  3 70 24  0
 2  6 1846104 1642756      0      0 4768  468 78752   468 4672 60141  2  2 76 20  0
 1 12 1846104 1640792      0    236 4752  440 140712   464 7614 99593  3  5 58 34  0
 0  3 1846084 1630368      0   6316 5104    0 20336     0 1703 22424  1  1 72 26  0
 2 17 1846104 1638332      0   3168 4080 1720 211960  1744 11977 155886  3  4 65 28  0
 1 10 1846104 1640800      0    132 4488  556 126016   584 8016 106368  3  4 63 29  0
 0 14 1846104 1639740      0   2248 3436  428 114188   452 7030 92418  3  3 59 35  0
 1  6 1846096 1639504      0   1932 5500  436 141412   460 8261 112210  4  4 63 29  0
 0 10 1846104 1640164      0   3052 4028  448 147684   472 7366 109554  4  4 61 30  0
 0 10 1846100 1641040      0   2332 4952  632 147452   664 8767 118384  3  4 63 30  0
 4  8 1846084 1641092      0    664 4948  276 152264   292 6448 98813  5  5 62 28  0

Además, la salida de top ordenada por tiempo de CPU parece respaldar la teoría de que el intercambio es lo que está bloqueando el sistema:

top - 09:05:32 up 37 days, 23:24,  1 user,  load average: 9.75, 8.24, 7.12
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.4%sy,  0.0%ni, 76.1%id, 20.6%wa,  0.1%hi,  0.2%si,  0.0%st
Mem:   4044632k total,  2405628k used,  1639004k free,        0k buffers
Swap:  7812492k total,  1851852k used,  5960640k free,      436k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 4174 root      17   0 63156  176   56 S    8  0.0   2138:52  35,38 bacula-fd                                                                                                                            
 4185 root      17   0 63352  284  104 S    6  0.0   1709:25  28,29 bacula-sd                                                                                                                            
  240 root      15   0     0    0    0 D    3  0.0 831:55.19 831:55 kswapd0                                                                                                                              
 2852 root      10  -5     0    0    0 S    1  0.0 126:35.59 126:35 xfsbufd                                                                                                                              
 2849 root      10  -5     0    0    0 S    0  0.0 119:50.94 119:50 xfsbufd                                                                                                                              
 1364 root      10  -5     0    0    0 S    0  0.0 117:05.39 117:05 xfsbufd                                                                                                                              
   21 root      10  -5     0    0    0 S    1  0.0  48:03.44  48:03 events/3                                                                                                                             
 6940 postgres  16   0 43596    8    8 S    0  0.0  46:50.35  46:50 postmaster                                                                                                                           
 1342 root      10  -5     0    0    0 S    0  0.0  23:14.34  23:14 xfsdatad/4                                                                                                                           
 5415 root      17   0 1770m  108   48 S    0  0.0  15:03.74  15:03 bacula-dir                                                                                                                           
   23 root      10  -5     0    0    0 S    0  0.0  13:09.71  13:09 events/5                                                                                                                             
 5604 root      17   0 1216m  500  200 S    0  0.0  12:38.20  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  580  248 S    0  0.0  11:58.00  11:58 java

Aquí está el mismo ordenado por tamaño de imagen de memoria virtual:

top - 09:08:32 up 37 days, 23:27,  1 user,  load average: 8.43, 8.26, 7.32
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  3.4%sy,  0.0%ni, 62.2%id, 30.2%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   4044632k total,  2404212k used,  1640420k free,        0k buffers
Swap:  7812492k total,  1852548k used,  5959944k free,      100k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 5415 root      17   0 1770m   56   44 S    0  0.0  15:03.78  15:03 bacula-dir                                                                                                                           
 5604 root      17   0 1216m  492  200 S    0  0.0  12:38.30  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  476  200 S    0  0.0  11:58.20  11:58 java                                                                                                                                 
 4598 root      16   0  117m   44   44 S    0  0.0   0:13.37   0:13 eventmond                                                                                                                            
 9614 gdm       16   0 93188    0    0 S    0  0.0   0:00.30   0:00 gdmgreeter                                                                                                                           
 5527 root      17   0 78716    0    0 S    0  0.0   0:00.30   0:00 gdm                                                                                                                                  
 4185 root      17   0 63352  284  104 S   20  0.0   1709:52  28,29 bacula-sd                                                                                                                            
 4174 root      17   0 63156  208   88 S   24  0.0   2139:25  35,39 bacula-fd                                                                                                                            
10849 postgres  18   0 54740  216  108 D    0  0.0   0:31.40   0:31 postmaster                                                                                                                           
 6661 postgres  17   0 49432    0    0 S    0  0.0   0:03.50   0:03 postmaster                                                                                                                           
 5507 root      15   0 47980    0    0 S    0  0.0   0:00.00   0:00 gdm                                                                                                                                  
 6940 postgres  16   0 43596   16   16 S    0  0.0  46:51.39  46:51 postmaster                                                                                                                           
 5304 postgres  16   0 40580  132   88 S    0  0.0   6:21.79   6:21 postmaster                                                                                                                           
 5301 postgres  17   0 40448   24   24 S    0  0.0   0:32.17   0:32 postmaster                                                                                                                           
11280 root      16   0 40288   28   28 S    0  0.0   0:00.11   0:00 sshd                                                                                                                                 
 5534 root      17   0 37580    0    0 S    0  0.0   0:56.18   0:56 X                                                                                                                                    
30870 root      30  15 31668   28   28 S    0  0.0   1:13.38   1:13 snmpd                                                                                                                                
 5305 postgres  17   0 30628   16   16 S    0  0.0   0:11.60   0:11 postmaster                                                                                                                           
27403 postfix   17   0 30248    0    0 S    0  0.0   0:02.76   0:02 qmgr                                                                                                                                 
10815 postfix   15   0 30208   16   16 S    0  0.0   0:00.02   0:00 pickup                                                                                                                               
 5306 postgres  16   0 29760   20   20 S    0  0.0   0:52.89   0:52 postmaster                                                                                                                           
 5302 postgres  17   0 29628   64   32 S    0  0.0   1:00.64   1:00 postmaster

Intenté ajustar el swappinessparámetro del kernel a valores altos y bajos, pero nada parece cambiar el comportamiento aquí. No puedo entender qué está pasando. ¿Cómo puedo averiguar qué está causando esto?

Actualización: el sistema es un sistema completamente de 64 bits, por lo que no debería haber ninguna cuestión de limitaciones de memoria debido a problemas de 32 bits.

Actualización 2: Como mencioné en la pregunta original, ya he intentado ajustar el intercambio a todo tipo de valores, incluido 0. El resultado es siempre el mismo, con aproximadamente 1.6 GB de memoria sin usar.

Actualización 3: Se agregó salida superior a la información anterior.

Kamil Kisiel
fuente
2
Parece que Linux no está utilizando la memoria caché de la página para nada, pero aún tiene una gran cantidad de memoria libre. Algo está claramente mal.
David Pashley
1
¿Puedes publicar algunos detalles adicionales del sistema operativo Linux? Proveedor, lanzamiento, versión del kernel, etc. Hay un par de herramientas que me gustaría sugerir, pero algunas requieren una versión de kernel particular o una versión de biblioteca de soporte.
Christopher Cashell

Respuestas:

6

El rendimiento de Bacula depende en gran medida de la base de datos. Probablemente, es postgresql lo que está matando a su servidor. El alto promedio de carga y el porcentaje bastante grande de tiempo de CPU en estado de espera muestran claramente que está esperando la E / S de disco ... Y eso es lo que está haciendo PostgreSQL. Para cada archivo en su conjunto de copia de seguridad está haciendo al menos una declaración de ACTUALIZACIÓN. No te preocupes por el intercambio.

Ajuste la instalación de PostgreSQL. Posiblemente proporcione a la base de datos individual (o incluso a las tablas) sus propios conjuntos de discos / incursiones para distribuir la E / S. Puede forzar a PostgreSQL a utilizar escrituras aynschronous si aún no lo ha hecho ... Aunque eso está cambiando la integridad de la base de datos por el rendimiento de escritura. Aproveche al máximo la memoria compartida disponible para PostgreSQL. Eso aliviará al menos gran parte de la lectura en la base de datos. Si nunca lo ha hecho, ejecute VACCUM ANALYZE en la base de datos de Bacula también para darle al optimizador de consultas algo con lo que trabajar.

De lejos, el punto más débil de Bacula son las dependencias de la base de datos (y la muerte cerebral de algunas de ellas ...) Ejecute una purga de una copia de seguridad grande reciente y observe cuánto tiempo (a menudo) demora ejecutar un par de docenas de millones de consultas. .. A Bacula le gustan relativamente pocos archivos grandes, de lo contrario es un perro.

Alexandre Carmel-Veilleux
fuente
Gracias. Esto realmente parece ser el quid del problema. Veremos formas de rectificarlo.
Kamil Kisiel
19

Estás vinculado a E / S. Su sistema es una pequeña balsa salvavidas, maltratada en un mar tormentoso de olas de búfer / memoria caché / paginación de máquinas virtuales que tienen 100 pies de altura.

Guau. Simplemente guau. Estás moviendo alrededor de 100Mbyte / s fuera de tu E / S, estás más allá del 50% del tiempo de CPU en espera de E / S y tienes 4 Gb de RAM. La contrapresión en la VM de este servidor debe ser enorme. En circunstancias "normales", a medida que el sistema comienza a almacenarse en el búfer / caché, cualquier RAM libre que tenga se comerá viva en menos de 40 segundos .

¿Sería posible publicar los ajustes de /proc/sys/vm? Esto proporcionaría una idea de lo que su núcleo piensa que es "normal".

Esos postmasterprocesos también indican que está ejecutando PostgreSQL en segundo plano. ¿Es esto normal para su configuración? PostgreSQL en una configuración predeterminada usará muy poca RAM, pero una vez que se vuelve a ajustar para la velocidad, puede masticar 25% -40% de su RAM disponible rápidamente. Así que solo puedo adivinar, dado el número de ellos en la salida, está ejecutando algún tipo de base de datos de producción mientras ejecuta copias de seguridad. Esto no es un buen augurio. ¿Puedes dar más información sobre por qué se está ejecutando? ¿Cuál es el tamaño del parámetro de memoria compartida para todospostmasterprocesos? ¿Sería posible cerrar el servicio o reconfigurar temporalmente la base de datos para usar menos conexiones / buffers mientras se ejecutan las copias de seguridad? Esto ayudará a aliviar la presión sobre la E / S ya tensa y la RAM libre. Tenga en cuenta que cada postmasterproceso consume RAM más allá de lo que usa la base de datos para el almacenamiento en caché interno. Por lo tanto, cuando realice ajustes en la configuración de la memoria, tenga cuidado con cuáles son "compartidas" y cuáles son "por proceso" .

Si está utilizando PostgreSQL como parte de su proceso de copia de seguridad, intente volver a sintonizarlo para aceptar solo la cantidad mínima de conexiones y asegúrese de reducir sus parámetros por proceso a algo razonable (solo unos pocos megas cada uno). La desventaja de esto es que PostgreSQL se derramará en el disco si no puede funcionar con el conjunto de datos en la RAM como lo desea, por lo que en realidad aumentará la E / S del disco , así que sintonice con cuidado.

X11 en sí mismo no requiere mucha memoria, pero una sesión de escritorio completa puede consumir varios megas. Cierre sesión en cualquier sesión activa que tenga y ejecute su conexión desde la consola o mediante SSH.

Aún así, no creo que sea completamente un problema de memoria. Si tiene más del 50% de E / S, espere durante períodos prolongados (y está publicando cifras que tocan los años 70), el cuello de botella resultante eventualmente aplastará al resto del sistema. Al igual que Darth Vader aplasta los cuellos.

Alguien en el negocio final del control mortal de Darth Vader

¿Para cuántos hilos de descarga está configurado? Utilizar

cat /proc/sys/vm/nr_pdflush_threads

para descubrir y

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

para configurarlo en un solo hilo. Tenga en cuenta que el último comando hace que se cargue permanentemente al reiniciar. Ver 1 o 2 allí no es inusual. Si tiene varios núcleos o una gran cantidad de capacidad de husillo / bus para E / S, querrá aumentarlos (ligeramente). Más subprocesos de descarga = más actividad de E / S, pero también más tiempo de CPU gastado en espera de E / S.

¿Es el valor predeterminado o lo has golpeado? Si lo ha golpeado, ¿ha considerado disminuir el número para reducir la cantidad de presión en las operaciones de E / S? ¿O tiene una gran cantidad de ejes y canales con los que trabajar, en cuyo caso, ha considerado aumentar la cantidad de hilos de descarga?

PD: desea establecer el intercambio en los valores más bajos, no en los valores más altos, para evitar el intercambio. Valor más alto = 100 = intercambiar como loco cuando se siente bien, valor más bajo = 0 = tratar de no intercambiar en absoluto.

Avery Payne
fuente
Veré algunas de tus sugerencias. No, no estoy loco y estoy ejecutando una base de datos de producción en el sistema de respaldo. PostgreSQL es parte del sistema de respaldo, ya que Bacula lo utiliza como su almacén de información para realizar un seguimiento de lo que hay en qué cinta, etc. Echaré un vistazo para ajustar algunos de los parámetros que especificó. El alto rendimiento de E / S es el resultado de que otros servidores descarguen datos en la bandeja de disco de este servidor, y este servidor posteriormente extrae esos datos y los escribe en una biblioteca de cintas LTO4.
Kamil Kisiel
¿Cómo se organizan los discos del servidor? ¿Está utilizando una configuración de unidad reflejada?
Avery Payne
1
+1 para prosa púrpura :)
pjc50
Sí, me sentía un poco creativo ese día. Perdón por el drama. :)
Avery Payne
7

Si observa los bloques leídos por segundo (bi) bajo IO, eclipsa la actividad de intercambio en múltiples órdenes de magnitud. No creo que el uso de intercambio sea lo que está causando la agitación de su disco, creo que tiene algo ejecutándose en la caja que simplemente está causando mucha actividad de disco (lecturas).

Investigaría las aplicaciones en ejecución y vería si puedes encontrar al culpable.

Christopher Cashell
fuente
Bueno, como dije, está ejecutando el sistema de respaldo bacula. Es probable que los bloques sean el resultado de que el servidor arroje datos a su matriz de discos SAS externamente conectada.
Kamil Kisiel
1
¿Está seguro de que el disco se está volcando por el intercambio y no por las copias de seguridad? ¿Qué otros procesos se están ejecutando en la caja? Si el kernel es lo suficientemente nuevo, existen algunas herramientas muy útiles (iotop) que pueden profundizar en las entrañas del uso de io e incluso establecer la prioridad de IO (ionice) si está utilizando el programador de IQ CFQ.
Christopher Cashell
6

Vea si este enlace responde algunas de sus preguntas. Regularmente veo paginación de Linux (no intercambio) fuera de la memoria mucho antes del 60% de utilización. Esta es una parte esperada de su ajuste de memoria:

http://www.sheepguardingllama.com/?p=2252

Pero tu falta de buffers / cache me preocupa. Eso se ve muy inusual. Así que estoy pensando que algo más está mal.

Scott Alan Miller
fuente
Hola, buena llamada, ¿dónde están los búferes / caché? ¿Están apagados? ¿Hay algo que los invalida constantemente?
MikeyB
6

¿Puedes intentar deshabilitar el intercambio por completo?

swapoff /dev/hdb2

o algo así, al menos eso validará que el cambio es tu problema, y ​​no otra cosa.

Tim Howland
fuente
+1 para confirmar que el presunto diagnóstico es en realidad la causa del problema.
Wayne
Lo intentaré mañana en el trabajo. Además, mi spaw no está en / dev / hdb2;)
Kamil Kisiel
Sin embargo, debe tenerse en cuenta que, si bien es una buena ayuda para el diagnóstico, esto es muy peligroso en un sistema de producción. Si realmente necesita el intercambio, se quedará rápidamente sin RAM. Y luego el asesino OOM vendrá y matar a un proceso aleatorio, lo que podría ser su producción DB ...
sleske
De acuerdo, no debería estar haciendo esto cerca de la producción.
Tim Howland
3

De forma predeterminada, el intercambio se establece en 60.

cat / proc / sys / vm / swappiness 60

Swappiness es un kernel que se utiliza para ajustar cuánto favorece el kernel intercambiar sobre RAM; un intercambio alto significa que el núcleo se intercambiará mucho, y un intercambio bajo significa que el núcleo intentará no usar espacio de intercambio.

Podemos cambiar esta edición del valor de vm.swappiness en /etc/sysctl.conf .

nitinas
fuente
O puede escribir el porcentaje directamente en /proc/sys/vm/swappiness.
user2284570
2

Puede establecer manualmente el intercambio del núcleo, que puede ver /proc/sys/vm/swappinesso emitir el comando sysctl vm.swappiness. El intercambio es una configuración del núcleo que determina cuánto se usa el intercambio.

Al establecer sudo sysctl vm.swappiness=0que está desactivando efectivamente la partición de intercambio. Para hacer este cambio permanente puede añadir / modificar vm.swappiness=0en /etc/sysctl.conf. Debería ver cuál es un buen valor para usted. Personalmente lo tengo configurado vm.swappiness=10, siendo 60 el valor predeterminado.

viajero
fuente
No del todo, con swappiness = 0 estás diciendo que nunca cambies si hay una manera de evitarlo, pero aún así intercambia si la única otra opción es fallar una asignación o un OOM kill. Considero que un intercambio de 30 es una buena mejora en las computadoras portátiles, pero no he tenido la necesidad de jugar con otros sistemas.
LapTop006
1

Otra cosa que es posible que desee ver es la cola de ejecución del kernel y los procesos ininterrumpibles (las columnas 'r' y 'b' en vmstat) son un indicador de que el sistema está saturado a veces. En una nota al margen, no confunda la saturación con la utilización ... el verdadero problema puede ser una pila de procesos hambrientos contra el núcleo saturado :-(

También puede ejecutar 'pmap -x [PID]' para obtener detalles de memoria adicionales de algunos de los procesos más exigentes. ¡Te deseo suerte!

Mate

Matt Cummings
fuente
1

Tal vez tenga procesos de corta duración que usan mucha memoria, luego salga antes de tener la oportunidad de notarlos.

Esto sería consistente con lo que estás viendo de todos modos.

MarkR
fuente
1

¿Has investigado problemas con la caché de inodo? slabtopal menos debería darte un punto de partida si te encuentras con algo como esto.

Martin M.
fuente
0

Si bien su sistema tiene 64 bits, es posible que el sistema no pueda direccionar realmente toda la memoria disponible. Esta es una limitación del conjunto de chips. Por ejemplo, la generación anterior de Mac mini "admite" 4 GB de RAM, pero solo 3.3 GB eran realmente direccionables.

Dustin
fuente
Es un SGI Altix XE240, estoy bastante seguro de que puede soportar más de 4 GB de RAM ya que he usado unidades de demostración con 32 GB.
Kamil Kisiel
No es una limitación del conjunto de chips en el viejo mini, ese conjunto de chips puede llegar a 8 GB, sin embargo, Apple no agregó las líneas de direccionamiento para manejarlo correctamente (IIRC, pero hay un caso general entre varios fabricantes)
LapTop006