Conflictos en Linux y sus respuestas

La estabilidad del sistema Linux se ha convertido en una buena arma para muchos críticos contra el sistema de Windows cada vez mayor. Sin embargo, aunque los conflictos del sistema Linux son relativamente pocos, una vez que aparecen en situaciones inesperadas, es fácil poner a la gente en problemas. Es importante aprender algunas formas comunes de evitar que ocurran estos conflictos. Puede ayudar a los administradores de sistemas Linux a evitar los dilemas.

En una entrevista con este sitio, Mark Wilding y Dan Behman brindan una forma relativamente simple y directa de prevenir y solucionar los conflictos del sistema Linux. Los dos publicaron conjuntamente un nuevo libro: "Self-Service Linux: Mastering the Art of Problem Determination".

En general, se cree que no hay conflicto en el sistema del servidor Linux. Sin embargo, hay algunos conflictos y problemas de estancamiento en el sistema. ¿En qué se diferencia el conflicto o el estancamiento en el nivel de la aplicación del nivel del kernel?

Mark Wilding: Los conflictos a nivel de la aplicación o los problemas de estancamiento se limitan a un proceso o proceso específico. Este tipo de conflicto o estancamiento no causa conflictos o estancamiento de otros subprocesos o procesos que se ejecutan en el mismo sistema. Sin embargo, si sucede a nivel del kernel, afectará a todos los procesos que se ejecutan en el sistema.

Conflictos de sistemas y estancamiento, ¿cuál es la diferencia entre ellos?

Dan Behman: En cualquier nivel, los atributos de conflicto y estancamiento son básicamente los mismos. El estancamiento se produce cuando un proceso o subproceso se bloquea, en este punto debido a que algún tipo de bloqueo o algunos recursos de hardware están ocupados, por lo que el proceso o subproceso tiene que esperar. La espera de ciertos bloqueos o recursos es una ocurrencia común, pero solo cuando dichos bloqueos o recursos sean eventualmente imposibles de lograr causarán bloqueos en el sistema.

También hay un punto muy importante a tener en cuenta que los problemas de estancamiento a veces se pueden diagnosticar temprano. Quiero decir, por ejemplo, un momento particular en un recurso está muy ocupado, y un proceso o subproceso que necesita dicho recurso debe esperar un tiempo muy largo hasta que el recurso esté inactivo. Los usuarios a menudo no entienden la condición de ocupado de los recursos, pero solo ven que el proceso está en espera, por lo que piensa que el sistema se ha estancado, pero en realidad el sistema aún está de acuerdo con el flujo de trabajo establecido, pero la velocidad es relativamente lenta.

Y el problema de conflicto del sistema es diferente del estancamiento anterior, que se debe principalmente a un error de hardware o software desconocido. Cuando se produce un error de este tipo, es muy probable que el extraordinario manejador de errores llame a esos diagnósticos e informes, de modo que tenga la esperanza de que se pueda rastrear la causa del error.

Un conflicto puede verse como un problema fatal que debe analizarse antes de poder analizarse. El problema del estancamiento puede considerarse como un problema en tiempo real, que puede analizarse y resolverse en tiempo real.

Sé que una de las mayores ventajas de Linux es la apertura de su código fuente. Además, hay otras razones por las que Linux puede resolver conflictos fácilmente con otros sistemas operativos.

Behman: con la apertura de este código fuente, hay bastantes archivos de referencia en todos los niveles del sistema Linux. Al mismo tiempo, dado que el código fuente está abierto, su equipo de desarrollo está igualmente abierto. De esta manera, puede dirigirse a los desarrolladores del kernel de Linux para resolver los problemas con los que se encuentran, incluidos los desarrolladores originales, incluso el propio Linus Torvalds, y todos los programas de búsqueda de ayuda solo están enviando un correo electrónico. . Que yo sepa, esta capacidad de Linux falta en los sistemas operativos que no son de código abierto.

¿Cuáles son las dificultades y los desafíos para lidiar con el estancamiento?

Wilding: El estancamiento de una aplicación se debe a una variedad de razones, incluidas aquellas que pueden ser causadas por problemas con el espacio del kernel. . Esto significa que a veces estos problemas no son controlados por el desarrollador. Pero esta es la ventaja de Linux. Todo el código fuente está abierto, por lo que si encuentra un bloque de kernel en un proceso, puede comunicarse con el código fuente para ver cómo funciona el proceso en el kernel. Sin embargo, en la mayoría de los casos, no es necesario realizar una investigación tan profunda. Para explorar las razones del estancamiento del proceso, los desarrolladores de software de aplicación deben estudiar cuidadosamente el estado y la evidencia de estos niveles de software.

Para los usuarios o el personal de mantenimiento, generalmente no entienden los procedimientos de trabajo específicos del software de la aplicación y no tienen la capacidad de ingresar el nivel del código fuente para las pruebas. Esta es una operación flexible cuando el sistema se atasca. Procesamiento. Por ejemplo, en algunos casos, el proceso A está esperando los recursos liberados después de que el proceso B finalice, y el proceso B está esperando los recursos que son propiedad del proceso A. Este es el llamado "interbloqueo", que es un problema que ocurre con frecuencia en aplicaciones complejas y se puede usar como una solución de diagnóstico para problemas de estancamiento.

Si no conoce las razones específicas de espera para el Proceso A y el Proceso B, entonces ni siquiera necesita entender si este es el caso del "interbloqueo" y no tiene más remedio que desactivar ambos procesos. A continuación, vuelva a encenderlo. Es esta situación similar, por lo que para el software de aplicación, es muy importante llevar a cabo el seguimiento de los recursos completos y la situación de bloqueo, lo que puede ayudar a resolver este problema más difícil.

Behman: Otro desafío con el problema del estancamiento es que cuando ocurre un problema de estancamiento, el proceso o el subproceso a menudo no sabe si está bloqueado o cuándo se detendrá. Esta situación es diferente del problema de conflicto. Cuando se produce un problema de conflicto, el proceso puede interceptar la mayoría de las señales, y el manejador de señales se puede agregar al sistema de la plataforma para manejar estas situaciones extraordinarias, como limpiar la memoria, rastrear la pila, etc. Sin embargo, cuando se produce el problema del estancamiento, este proceso extraordinario no es completamente imposible, pero a menudo es flexible y no muy fijo.

Cuando se produce un problema de estancamiento, a menudo es necesario reiniciar el sistema o el software de la aplicación. Una cosa que se debe tener en cuenta es que cuando se produce un problema de estancamiento, el kernel activo y el software de aplicación a menudo capturan parte de la información y las pruebas para diagnosticar el problema. Si no recopila estos importantes y se reinicia de inmediato, nunca sabrá cómo diagnosticar el problema y, por lo tanto, es imposible evitar que vuelva a suceder en el futuro.

Para algunos entornos extraordinarios, la estabilidad y confiabilidad del sistema está estrechamente relacionada con la velocidad del diagnóstico y la resolución de problemas. Por lo tanto, es necesario adherirse a una idea razonable, es decir, "primero recopile el error y luego reinicie".

Comparando con los conflictos, ¿qué es lo primero que se debe hacer cuando se trata del estancamiento?

Behman: Cómo lidiar con el estancamiento en el nivel del kernel y el estancamiento en el nivel de la aplicación Muy diferente

Si está preguntando sobre el nivel de aplicación. Cuando ocurre un problema de conflicto, hay una función extraordinaria llamada "procesamiento de señal" que llama a manejar una variedad de cosas, como en la memoria, retroalimentación de seguimiento de la pila, etc. Por lo tanto, en general, cuando se enfrentan conflictos, el problema principal es recopilar, organizar y analizar los datos.

Si bien los datos no se recopilan automáticamente cuando ocurren problemas de estancamiento, a menudo se trata de un proceso manual. Dos puntos clave para recopilar datos de estado estancado son el seguimiento de la salida y la retroalimentación de seguimiento de la pila. Esta forma de hacer un seguimiento de la salida puede darle una idea de lo que está haciendo el proceso porque sigue supervisando el proceso todo el tiempo, por ejemplo, si el proceso sigue funcionando y así sucesivamente. La información de seguimiento de la pila puede dar al código fuente parte del proceso actual. Esto es muy importante para los desarrolladores, para que puedan estudiar la causa del estancamiento del proceso.

¿Cuáles son las razones principales del conflicto y el estancamiento?

Wilding: Para los conflictos, podemos dividir las razones principales en dos, una es Preventivo, el otro es el manejo de errores. Los conflictos preventivos son situaciones en las que el software del kernel o de la aplicación tiene un conflicto debido a una situación grave. El software es consciente de este problema y produce un enfoque de "suicidio" para evitar que se produzcan más errores, evitando así problemas más graves. Para conflictos de manejo de errores, significa que se ingresa cierto contenido ilegal en la memoria y casi todos los errores de programa. En este caso, el hardware detecta la aplicación y luego envía una señal para bloquear el progreso del software.

Para el problema del estancamiento, generalmente hay dos razones. Uno es el caso en el que un proceso o subproceso espera un recurso, que puede no resolverse. Otros procesos o subprocesos restringen el recurso de modo que cuando el proceso o subproceso está esperando, todavía ocupa recursos, por lo que otros procesos o subprocesos solo pueden esperar. Un ejemplo es un proceso que bloquea los recursos importantes que ocupa y que, a su vez, recibe Internet sin un propósito. La segunda razón más común es un tipo de espera de "bucle por bucle", donde dos o más procesos están esperando los recursos del otro, cayendo así en "interbloqueo". La solución a esta situación puede ser liberar un bloqueo o compartir la memoria en un espacio.

Bajo estos conflictos y el estancamiento, ¿cuáles son las reglas básicas de investigación que los gobernadores pueden aplicar?

Wilding: Una de las mejores pautas básicas es organizar el trabajo. . Es muy importante mantener los datos recopilados en un lugar claro para que se puedan encontrar fácilmente en el futuro. Esto es especialmente útil para situaciones en las que se encuentran múltiples problemas al mismo tiempo.

Behman: Otro criterio básico es recopilar datos cuantitativamente en lugar de cualitativamente. Por ejemplo, "a las 6 en punto de la noche anterior, la utilización de la memoria del sistema es menor", esta es una observación cualitativa. Esto tiene poco efecto en el manejo de problemas. La versión cuantitativa de este ejemplo debe recopilar y guardar todos los comandos de datos de salida, así como otros comandos de diagnóstico relacionados. El propósito es recopilar suficientes datos, para evitar que el problema se repita lo más posible, este es el método "de una sola vez", sin la necesidad de repetir el problema, varias colecciones pueden obtener datos más completos. .