Los sistemas ocupados en una red utilizada por múltiples usuarios locales (o miles de usuarios web) experimentan problemas de rendimiento durante sus ciclos de vida. Solo los sistemas que no están ocupados son inmunes a los problemas de rendimiento que nos afectan a todos. Este artículo explora los sospechosos habituales para encontrar y solucionar problemas de rendimiento.
Lo que sigue son pautas genéricas, un resumen básico de "lugares para comenzar". Cada problema es diferente, pero a medida que adquiera más experiencia, tendrá una mejor idea de dónde y cómo empezar a buscar un problema en particular. Creo que se le puede enseñar los conceptos básicos de resolución de problemas, pero no se le puede enseñar la experiencia o la intuición. Esos dos vienen con el tiempo. Además, tenga en cuenta que algunos problemas se manifiestan de tal manera que comienza por un camino y, a menudo, lo llevan a otro. Este factor es frustrante pero normal. Por ejemplo, ciertos problemas del disco pueden hacer que el uso de la CPU aumente, y los problemas de memoria pueden enmascararse como problemas de rendimiento del disco. Comience primero con las cosas fáciles y luego continúe con las más complejas. No te compliques la vida más de lo necesario. A veces, solo necesita reemplazar un cable de red o reiniciar un sistema. Simple, pero efectivo.
Revertir cambios recientes
Es necesario realizar cambios en un entorno de producción. Es obligatorio documentar esos cambios. Te alegrarás de haberlo hecho cuando algo salga mal, y lo hará. Lo extraño de hacer cambios en Linux (o cualquier otro sistema) es que el cambio en sí puede funcionar perfectamente cuando lo haces, pero en uno o dos días, el rendimiento de tu sistema se ve afectado. Antes de hacer cualquier otra cosa, consulte la documentación de cambios para ver si se realizaron cambios recientes en el sistema. Los cambios incluyen parches de software, actualizaciones de cualquier tipo, reemplazos o actualizaciones de hardware, actualizaciones de controladores, actualizaciones de firmware, inserción de código, nuevas instalaciones de software y cambios de configuración.
Cuando revise su documentación de cambios, compare los cambios recientes con los problemas que está teniendo. Después de realizar las comprobaciones habituales del sistema, debe revertir los cambios uno a la vez para ver cuál se puede rastrear hasta la causa raíz del rendimiento. A veces, encontrará que ciertos "clusters" de actualización no son compatibles, o deben instalarse o aplicarse en un orden particular. Siempre revise la documentación de su proveedor para ver si este es el caso.
Actualizar, actualizar, actualizar
Puede evitar problemas de rendimiento asociados con errores de software y hardware manteniendo todo actualizado, especialmente cuando se trata de software del lado del servidor (en lugar del lado del cliente, como un navegador web). El lado del cliente también debe actualizarse, por supuesto, pero esa es una discusión diferente.
Sí, mantener todos sus sistemas actualizados es un trabajo de tiempo completo. Siempre hay algo que debe actualizarse en un sistema:BIOS, firmware, controladores, el sistema operativo, aplicaciones, agentes, software de seguridad, bases de datos, software de copia de seguridad, etc. Esta tarea nunca termina. Decida con qué frecuencia necesita actualizar o cumplir con la política de parches de su organización para planificar, programar y aplicar esas actualizaciones. En uno de mis trabajos, parcheamos una vez por semana. Hacerlo fue un dolor. Requería que tuviéramos una noche entera una vez a la semana, lo que envejece rápidamente. Sin embargo, no se puede evitar hacerlo regularmente. Tienes que actualizar para asegurarte de que tus sistemas son seguros y tienen los parches de estabilidad más recientes.
Si sus sistemas están actualizados y no hay actualizaciones más recientes disponibles, generalmente puede descartar actualizaciones y parches como la causa principal del problema de rendimiento.
Limitaciones y fallas del hardware
Según mi experiencia, todo el mundo (programadores, administradores de red, gestión y proveedores) quiere culpar a la infraestructura de todos los problemas de rendimiento. Todos creen colectivamente que la infraestructura es el eslabón más débil y ahí es donde es más probable que ocurran las fallas, por lo que tendrá que demostrar que no es su hardware el que causa el problema antes de que alguien tome medidas. Estoy de acuerdo en un punto, pero es un poco molesto cuando esa es la primera suposición, en lugar de una que se investiga simultáneamente con otras posibles causas.
En general, hay cuatro componentes de hardware que pueden fallar o alcanzar limitaciones que pueden causarle problemas:CPU, red, memoria y disco. Hay otros componentes que también pueden fallar, como las fuentes de alimentación, pero estos "cuatro grandes" son los culpables más comunes y los primeros lugares en los que debe buscar cuando tiene un problema.
CPU
En estos días, la mayoría de los sistemas de servidor tienen bancos de CPU multinúcleo y multiprocesador. Si tiene un problema con la CPU, puede deberse a un defecto en la propia CPU. Encontrar la CPU específica que le está dando un problema está más allá del alcance de este artículo. Si sospecha una falla o anomalía real de la CPU, llame al proveedor de su sistema para que lo aconseje. Es probable que tengan rutinas de diagnóstico que pueda ejecutar para identificar el problema de la CPU. Más allá de eso, enviarán un técnico para reemplazar una CPU o todas.
Entonces, además de una falla total de la CPU, ¿qué busca cuando sospecha un problema de la CPU? Comprobar top para ver si algún proceso está sobrecargando su(s) CPU(s). Para ordenar top para CPU, ejecute top y luego escriba P (Mayús+P). Mire los procesos que consumen sus ciclos de CPU. ¿Los que están en la parte superior de la lista están relacionados con el sistema o con las aplicaciones? Si son procesos del sistema, verifique su tiempo de actividad. El tiempo de actividad no debería ser extremadamente alto debido al reinicio regular.
Si encuentra una aplicación en particular que usa una cantidad anormal de ciclos de CPU, reinicie la aplicación para ver si el problema persiste. Si el proceso está relacionado con el sistema, intente reiniciar el proceso si es posible. Si no, reinicie el sistema. Sí, reinicie el sistema.
Bonificación de solución de problemas (reinicio)
Sí, debe reiniciar al menos una vez al mes. Sé que hay un aluvión de argumentos sobre esta práctica, pero para descartar muchos problemas, un buen reinicio resuelve muchos problemas y lo ayuda a diagnosticar problemas de hardware con el mínimo esfuerzo. Apagar el sistema de vez en cuando también es una buena práctica, porque encender un sistema desde un arranque en frío puede identificar muchos problemas de hardware que podrían ocultarse en un sistema en ejecución. También podrá reducir los problemas si el problema de rendimiento persiste después de reiniciar.
Memoria
El siguiente lugar más obvio para buscar al solucionar problemas de rendimiento es el uso de la memoria. Los problemas de memoria pueden manifestarse de diferentes maneras que oscurecen el hecho de que la memoria es realmente el problema. Si descubre que durante el transcurso de un día la memoria de su sistema se agota, lo primero que debe verificar es su registro. Sé que suena loco, pero la captura de registros casi le cuesta millones de dólares a una empresa en la que solía trabajar. Noté en los informes de rendimiento que la memoria de nuestro sistema de clúster se estaba agotando durante el día. Había muchos gigabytes de memoria disponibles, por lo que este problema no debería haber ocurrido. Además, el rendimiento empeoró a medida que avanzaba el día. Cada noche a la medianoche, todo volvía. ¿Qué pasó a medianoche, preguntas? Rotación de registros. Aparentemente, alguien había activado la depuración de registros, lo que significaba que decenas de gigabytes por día se recopilaban, respaldaban y almacenaban innecesariamente. Y, estaba drenando nuestra memoria. Una vez descubierto y reparado, el rendimiento volvió con toda su fuerza y alivió la necesidad de gastar millones de dólares en sistemas adicionales para este enorme clúster.
También debe mirar el espacio de intercambio si sospecha que hay un problema de memoria. En esta salida, mi sistema está inactivo, por lo que el resultado no es dramático. Usa el free -m Comando para verificar el uso de memoria física y virtual (intercambio):
$ free -m
total used free shared buff/cache available
Mem: 821 200 288 10 333 484
Swap: 0 0 0
Si está utilizando mucho intercambio, su sistema podría estar haciendo lo que los administradores de *nix llaman "thrashing". Thrashing, al contrario de lo que hacen los skaters, es algo malo para nosotros. Usted no quiere que su sistema se derrumbe. La paliza también puede aparecer como un problema de disco si es lo suficientemente grave. Si su sistema está tan ocupado entrando y saliendo de páginas que afecta el rendimiento del disco, debe actuar de inmediato reiniciando el proceso infractor. Ahora, no me malinterpreten. El intercambio está configurado y configurado para paginar cosas en el disco, pero cuando causa un problema de rendimiento, este problema debe solucionarse.
Muchos sistemas modernos tienen tanta memoria que el intercambio basado en disco no se usa en absoluto. Algunos administradores sienten que es una pérdida de espacio en disco. Para mí, configurar el intercambio depende del propósito del sistema y de la cantidad de RAM que tenga. Las consideraciones de intercambio son realmente para otro artículo, pero diré que la forma en que maneja el intercambio depende de usted. No creo que la regla anterior de 1.5x RAM sea una buena fórmula. Piénsalo. Si su sistema tiene 128 GB de RAM, eso significa que configura 192 GB de RAM para el espacio de intercambio. Ridículo. Podría configurar 16 GB como máximo para ese sistema si configuré el intercambio.
En casos raros, su RAM puede ser mala o estropearse. Me ha pasado. También debe tener cuidado con el tipo de RAM que compra para un sistema si está actualizando. Combina lo que tienes o reemplázalo todo si no puedes combinarlo. No mezcles velocidades, cachés o marcas. Además, utilice el tipo de RAM recomendado para su sistema. El uso de memorias RAM no coincidentes o de otras marcas es un desastre a punto de ocurrir.
Finalmente, los programas errantes pueden causar problemas de memoria. Históricamente, los programas basados en Java me han causado más dolor. Algunos programadores de Java no programan correctamente para la limpieza de basura o la liberación de memoria, y surgen problemas cuando las cargas son altas o cuando se realizan ciertas llamadas. Siempre empiezo reiniciando el proceso. Mi próxima opción es verificar top por la cantidad de memoria consumida por el programa. Si todas mis comprobaciones y procesos de reinicio no funcionan, reinicio el sistema. Si el problema comienza de nuevo, acudiré al programador, me quejaré y proporcionaré mis informes.
Disco
Los discos fallan. Esa es una afirmación fuerte pero cierta. Incluso los SSD fallan en algún momento, así que prepárese para la falla del disco. Recuerda que RAID no es lo mismo que una copia de seguridad, y que los discos y particiones se llenan, lo que hace que se comporten con un rendimiento menos que óptimo. Si sospecha que un disco es su asesino de rendimiento, lo primero que debe mirar es el espacio disponible con un df rápido comando:
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 397M 0 397M 0% /dev
tmpfs 411M 0 411M 0% /dev/shm
tmpfs 411M 11M 400M 3% /run
tmpfs 411M 0 411M 0% /sys/fs/cgroup
/dev/sda2 16G 1.8G 14G 12% /
/dev/sda1 495M 152M 344M 31% /boot
tmpfs 83M 0 83M 0% /run/user/1000 Puede ver arriba que no hay sistemas de archivos completos o casi completos en mi servidor.
El siguiente elemento que debe verificar es si sus sistemas de archivos están llenos o casi llenos. Si ninguno lo es, entonces tiene un disco fallido. No puedo simular una falla de disco, pero algunos sistemas de servidor le avisan cuando tienen discos fallados. Por ejemplo, algunos de mis servidores antiguos mostraban una luz ámbar en lugar de una luz verde cuando algo andaba mal. Preste atención a los indicadores de su hardware. También tenía servidores que tenían una pequeña pantalla LCD que me notificaba fallas y errores. Estas herramientas fueron útiles cuando el sistema operativo no me notificó que había un problema.
Un disco fallido afecta el rendimiento, independientemente de la configuración. Las configuraciones de RAID no garantizan el rendimiento en caso de que falle un disco miembro. En cambio, garantizan la seguridad debido a la redundancia. En otras palabras, sus datos están intactos, pero sus usuarios y clientes no estarán contentos debido al bajo rendimiento. Espere problemas de rendimiento cuando falle un disco miembro.
Si tiene un sistema lento, verifique el servidor físico y todos sus componentes, alertas y mensajes. Este paso es para aquellos que tienen acceso a servidores físicos. Muchos administradores de sistemas tienen que lidiar con sistemas remotos o alojados y, por lo tanto, no tienen este tipo de acceso.
Red
Los problemas de red debido al hardware son algo raros, pero ocurren. Una NIC que parlotea, un cable defectuoso o un conmutador o puerto de conmutador fallidos pueden ser fuente de mucha frustración para un administrador de sistemas. Y, si agrega un puerto de conmutador o una configuración incorrecta de la red en el host mismo, ahora tiene una receta para muchos tirones de pelo. A veces es difícil encontrar el origen de un problema de red porque el problema puede ser local, en el conmutador o en algún lugar más allá del conmutador. Tienes que mirar cada nivel por separado para encontrar el problema.
Verifique sus otros anfitriones para comparar. ¿El problema está localizado en un solo host, está confinado a un solo grupo o afecta a todo el sistema? Esta verificación lo ayudará a identificar si el problema es local, si se limita a un solo interruptor, si afecta a todo un estante o fila, o si el problema está más generalizado.
Verifique las configuraciones de su red local. Verifique los registros de cambios para ver si algo ha cambiado recientemente. A continuación, realice una verificación física de su NIC. ¿Te parecen correctas las luces? ¿El cable se ve bien y el enchufe no parece estar dañado? ¿La configuración del cable parece correcta? Compruebe toda la longitud del cable en busca de daños físicos, si es posible. Compruebe el conmutador físico y el terminador del cable en el conmutador en busca de defectos físicos.
Verifique la configuración del interruptor usted mismo o pídale a un administrador de red que lo haga. Verifique físicamente la ubicación del conmutador o consulte su documentación para encontrar el puerto correcto para informar al administrador de la red. Si la configuración se ve bien, haga que el administrador de la red realice un restablecimiento rápido en el puerto. Además, pregunte al administrador sobre la última actualización del interruptor y la última fecha de reinicio.
Dependiendo de su trabajo y de dónde trabaje, es posible que no tenga control o visibilidad más allá de su interruptor. Trabaje con los administradores de red, los ISP o los proveedores de hospedaje para localizar mejor un problema de rendimiento de la red. La experiencia personal me dice que, a menos que un problema de red sea generalizado, los administradores de red quieren pruebas de lo que ha verificado que lo llevó a culpar a la red. Por este motivo, coloqué la solución de problemas de red en el último lugar de la lista. No puedo contar la cantidad de veces que escuché esas palabras frustrantes:"No es la red, hombre. Debe ser la infraestructura". Y luego un tono de marcación.
Conclusión
No hay atajos para obtener conocimientos sobre resolución de problemas. Puede aprender y estar preparado, pero desafortunadamente, la experiencia es el mejor maestro porque tiene que experimentar fallas antes de tener una idea real de cómo solucionar problemas en las trincheras. Incluso las fallas simuladas no le brindan la misma experiencia que una falla real, con usuarios reales que preguntan cuándo se arreglarán las cosas y gerentes reales que lo miran como si fuera su culpa que la empresa esté perdiendo dinero y molestos porque su teclado no está No hacer ningún ruido.
La resolución de problemas no es la parte divertida de ser un administrador de sistemas, pero es una parte necesaria. De hecho, no estoy seguro de si hay partes divertidas y todas son necesarias. Ser administrador de sistemas es estresante, y la resolución de problemas es una gran parte de ese estrés. Le he dado consejos en un intento de reducir ese estrés, pero todavía depende de usted ganar experiencia y confianza para ponerlos en práctica.