Preguntas sobre el servidor: ¿AIX v5.3 es un sistema operativo?

El nombre completo de AIX es (Advanced Interactive Executive), que es el sistema operativo Unix de IBM.

El diseño de todo el sistema, desde la red, el sistema de hardware host hasta el. sistema operativo, se adhiere plenamente a los principios del sistema abierto.

La siguiente es una introducción a AIX.

RS/6000 utiliza el sistema operativo UNIX de IBM, AIX, como sistema operativo. Este es el sistema UNIX de segunda generación que actualmente es el más exitoso, más utilizado y abierto en la industria de los sistemas operativos.

Es especialmente adecuado para el procesamiento de datos críticos (CRITICAL).

AIX incluye muchas de las características populares tradicionales de los mainframes de IBM, como la integridad del sistema, la capacidad de administración y la disponibilidad del sistema.

En el sistema operativo AIX, existen muchas bases de datos y herramientas de desarrollo. Además de utilizar el software de aplicación

existente, los usuarios también pueden desarrollarlo según sus propias necesidades.

Además, en AIX, existe un conjunto de herramientas de gestión del sistema potentes y fáciles de usar. Existen soluciones muy maduras para la coexistencia mutua y la interoperabilidad de plataformas heterogéneas.

Debido a la avanzada tecnología del kernel de UNIX y su mejor apertura, aunque RS/6000

solo ha existido durante más de 5 años desde su anuncio, se ha utilizado ampliamente en todos ámbitos de la vida,

y ocupó el primer lugar en el campo de UNIX comercial MIDRANGE durante dos años consecutivos en 1993 y 1994.

El sistema operativo de RISC SYSTEM/6000 es AIX, que es de alto rendimiento y abierto.

UNIX reúne los resultados de la investigación de la industria informática sobre UNIX a lo largo de los años. en IBM

Más de 40 años de experiencia extremadamente rica en arquitectura informática y sistemas operativos. Se aprovecha al máximo la tecnología RISC

y se instala un sistema operativo UNIX con potencia industrial como AIX.

Puede conectarse tanto a la arquitectura SAA como a redes de sistemas que no sean de IBM. Por lo tanto, puede

interconectarse con los sistemas existentes de la mayoría de los bancos profesionales, lo que será beneficioso para el futuro. La expansión del sistema empresarial traerá gran

flexibilidad y reducirá la inversión.

AIX sigue una serie de estándares internacionales:

* IEEE POSIX1004.1-1990

* X/OPEN Migration Guide ISSUE3 Nivel Básico (XPG3)

* AES/OS REVISIÓN A (calificación OSF/1 NIVEL 2)

* FIPS 151-1

* Compiladores para AIX: XLC, C (puede (opcional ), FORTRAN (opcional), PASCAL (opcional), COBOL (opcional)

* El compilador de ADA ha alcanzado el nivel de aprobación de "miembro" XPG3.

* AIX admite multiusuario y multitarea.

AIX tiene algunas otras características que incluyen:

AIX proporciona 3 tipos de SHELL: KORN de SYSTEM V, BOURNE SHELL y 4.3BSDC

SHELL como sistema UNIX opcional interfaz

Las instalaciones de seguridad cumplen con el nivel C2 de TCB (Trusted Computing Base).

Capacidades de procesamiento en tiempo real, que son cruciales para aplicaciones "orientadas a transacciones" (como el comercio minorista); industria

Y bancos, etc.), lo que permite que RS/6000 alcance una respuesta y un rendimiento extremadamente altos

Gestión de almacenamiento virtual; cuando sea necesario, algunos módulos poco comunes se pueden transferir a externos; almacenamiento,

Mejora la disponibilidad de la memoria.

El sistema de archivos avanzado hace que la administración del sistema sea más efectiva y mejora la confiabilidad

e integridad de los datos.

Compatible con aplicaciones y datos Dos.

InfoExplorer, un rápido sistema de indexación de hipertexto de información: no solo incluye texto, sino también

Esta es una interfaz de archivos en línea para sistemas de indexación que incluyen sonidos e imágenes. Incluyendo toda la indexación y búsqueda de hipertexto, así como múltiples sistemas de indexación y orientación orientados a tareas y coordenadas.

Este sistema de indexación textual y gráfico utiliza información

detallada y materiales de capacitación de una manera flexible y basada en tareas.

Herramienta avanzada de gestión de sistemas (SMIT, System Management Interface Tool).

Proporciona un controlador de menú de primer nivel, como completar la instalación y configuración del software, configuración y

administración del dispositivo, determinación de problemas, administración de almacenamiento, etc. La configuración del dispositivo de E/S se puede automatizar y el terminal ASCII también puede servir como consola del sistema. La instalación remota del sistema se puede realizar en una LAN.

Carga de trabajo del sistema

Una definición completa y precisa de una carga de trabajo del sistema es fundamental para predecir o comprender su rendimiento. Al medir el rendimiento del sistema, las diferencias en la carga de trabajo pueden causar más variaciones que las diferencias en la velocidad del reloj de la CPU o el tamaño de la memoria de acceso aleatorio (RAM). La definición de una carga de trabajo debe incluir no sólo el tipo y la tasa de solicitudes enviadas al sistema, sino también los paquetes de software exactos y las aplicaciones internas que se ejecutarán.

También es importante incluir el trabajo que el sistema manejará en segundo plano. Por ejemplo, si un sistema contiene un sistema de archivos que se monta a través de NFS y al que otros sistemas acceden con frecuencia, entonces el manejo de esos accesos probablemente sea una parte muy importante de la carga de trabajo general, incluso si el sistema no es oficialmente un servidor.

Las cargas de trabajo que se han estandarizado para permitir la comparación entre diferentes sistemas se denominan puntos de referencia. Sin embargo, pocas cargas de trabajo del mundo real coinciden completamente con los algoritmos y entornos precisos del programa de referencia. Incluso los programas de referencia estándar de la industria que se desarrollaron originalmente a partir de aplicaciones del mundo real se han simplificado y homogeneizado, haciéndolos portátiles a una gran cantidad de plataformas de hardware. La única forma eficaz de utilizar procedimientos de evaluación comparativa estándar de la industria es reducir el alcance de los sistemas candidatos que recibirán una evaluación seria. Por lo tanto, no debe confiar únicamente en los resultados de las pruebas comparativas cuando intente comprender la carga de trabajo y el rendimiento de su sistema.

Las cargas de trabajo se pueden dividir en las siguientes categorías:

Multiusuario

Una carga de trabajo que consiste en el trabajo enviado por varios usuarios a través de sus respectivos terminales. Normalmente, existen dos posibles objetivos de rendimiento para dichas cargas de trabajo: maximizar el rendimiento del sistema manteniendo un tiempo de respuesta específico en el peor de los casos, u obtener el tiempo de respuesta más rápido posible para una carga de trabajo fija.

Servidor

Carga de trabajo formada por solicitudes originadas en otros sistemas. Por ejemplo, la carga de trabajo de un servidor de archivos está dominada por solicitudes de lectura y escritura de disco.

Es la parte de E/S del disco de una carga de trabajo multiusuario (más NFS u otra actividad de E/S), por lo que se aplica el mismo objetivo, que es maximizar el rendimiento dadas las limitaciones de tiempo correspondientes. Otras cargas de trabajo del servidor consisten en elementos como programas con uso intensivo de matemáticas, transacciones de bases de datos y trabajos de impresora.

Estación de trabajo

Carga de trabajo compuesta por usuarios individuales que envían su trabajo a través del teclado y reciben los resultados en el monitor del sistema. Normalmente, el objetivo de rendimiento de mayor prioridad para esta carga de trabajo es minimizar el tiempo de respuesta a las solicitudes de los usuarios.

Objetivos de rendimiento

Después de haber definido la carga de trabajo que debe manejar su sistema, puede seleccionar criterios de rendimiento y establecer objetivos de rendimiento basados ​​en esos criterios. Los criterios generales de rendimiento para los sistemas informáticos son el tiempo de respuesta y el rendimiento.

El tiempo de respuesta es el tiempo transcurrido entre enviar una solicitud y devolver una respuesta para esa solicitud. Los ejemplos incluyen:

Tiempo dedicado a consultas de bases de datos

Tiempo dedicado a enviar caracteres al terminal

Tiempo dedicado a acceder a páginas web

El rendimiento es una medida de la cantidad de trabajo realizado por unidad de tiempo. Los ejemplos incluyen:

Transacciones de bases de datos por minuto

Kilobytes de archivos transferidos por segundo

Kilobytes de archivos leídos o escritos por segundo

Visitas al servidor web por minuto

La relación entre estas métricas es compleja. A veces puede obtener un mayor rendimiento a expensas del tiempo de respuesta y, a veces, puede obtener un mejor tiempo de respuesta a expensas del rendimiento. En otros casos, un solo cambio puede mejorar ambos. El rendimiento aceptable se basa en un rendimiento razonable combinado con tiempos de respuesta razonables.

Al planificar o ajustar cualquier sistema, es importante tener objetivos claros en cuanto al tiempo de respuesta y el rendimiento al manejar una carga de trabajo específica. De lo contrario, existe el riesgo de que dedique tiempo y recursos de análisis a mejorar sólo un aspecto menor del rendimiento del sistema.

Modelo de ejecución de programa

Para examinar claramente las características de rendimiento de una carga de trabajo, se requiere un modelo de ejecución de programa dinámico en lugar de estático, como se muestra en la siguiente figura.

Figura 1. Jerarquía de ejecución del programa. El gráfico se basa en un triángulo. El lado izquierdo representa la entidad de hardware que coincide con la entidad del sistema operativo apropiado a la derecha. Un programa debe comenzar en el nivel más bajo donde está almacenado en el disco y terminar en el nivel más alto donde el procesador ejecuta las instrucciones del programa. Por ejemplo, de abajo hacia arriba, la entidad de hardware del disco contiene el programa ejecutable; la memoria real contiene los subprocesos del sistema operativo y los controladores de interrupciones; el búfer de búsqueda de traducción contiene las terminaciones despachables y la caché contiene los subprocesos y procesadores actualmente enviados; el registro contiene la instrucción actual.

Un programa debe ascender en las jerarquías de hardware y sistema operativo en paralelo para poder ejecutarse. Cada elemento en la jerarquía de hardware es más raro y más caro que el elemento debajo de él. Los programas no sólo tienen que competir con otros programas por cada recurso, sino que también lleva tiempo pasar de un nivel al siguiente. Para comprender la dinámica de ejecución del programa, se requiere una comprensión básica de cada nivel de la jerarquía.

Jerarquía de hardware

Normalmente, el tiempo necesario para pasar de un nivel de hardware a otro está dominado por el tiempo de espera en los niveles inferiores (desde el momento en que se realiza una solicitud hasta el momento en que se realiza la solicitud). el primer lote se recibe (tiempo de datos) composición.

Disco fijo

Para un programa que se ejecuta en un sistema independiente, la operación más lenta es obtener código o datos del disco. Esto se debe a las siguientes razones:

p> p>

Se debe indicar al controlador de disco que acceda directamente al bloque especificado (retardo de cola).

El brazo del disco debe buscar encontrar el cilindro correcto (buscar latencia).

Los cabezales de lectura/escritura deben esperar hasta que el bloque correcto haya girado debajo de ellos (tiempo de espera de giro).

Los datos deben ser transferidos al responsable del tratamiento (tiempo de transferencia) y luego transferidos a la aplicación (tiempo de interrupción del procesamiento).

Hay muchas razones para las operaciones de disco lentas además de las solicitudes explícitas de lectura o escritura de un programa. La actividad frecuente de ajuste del sistema resulta ser un seguimiento innecesario de la E/S del disco.

Memoria real

La memoria real, a menudo llamada memoria de acceso aleatorio o RAM, es más rápida que el disco pero muy costosa por byte. El sistema operativo intenta mantener sólo el código y los datos actualmente en uso en la RAM, y almacena cualquier contenido adicional en el disco o nunca lo lleva a la RAM en primer lugar.

Sin embargo, la RAM no es necesariamente más rápida que el procesador. A menudo hay un tiempo de espera de RAM de muchos ciclos de procesador entre el momento en que el hardware se da cuenta de la necesidad de acceso a la RAM y el momento en que los datos o instrucciones están disponibles para el procesador.

Si se accede a una página de memoria virtual que está almacenada en el disco (o que aún no ha sido paginada), se produce un error de página y la ejecución del programa se suspende hasta que la página se lee del disco.

Translation Lookaside Buffer (TLB)

Una forma de liberar al programador de las limitaciones físicas del sistema es implementar memoria virtual. Los programadores diseñan y escriben programas pensando que la memoria es muy grande y que el sistema será responsable de convertir las direcciones virtuales de las instrucciones y los datos del programa en las direcciones reales de las instrucciones y los datos que deben recuperarse de la RAM. Debido a que este proceso de traducción de direcciones puede llevar mucho tiempo, el sistema almacena las direcciones reales de las páginas de memoria virtual a las que se accedió recientemente en un caché llamado búfer de traducción (TLB).

Mientras el programa en ejecución continúe accediendo a una pequeña porción del programa y las páginas de datos, no es necesario rehacer el proceso completo de traducción de direcciones de páginas virtuales a reales en cada acceso a la RAM. Cuando un programa intenta acceder a una página de memoria virtual que no tiene una entrada TLB (es decir, una pérdida de TLB), se requiere una gran cantidad de ciclos de procesador (es decir, tiempo de espera de pérdida de TLB) para realizar la traducción de la dirección.

Caché

Para minimizar el tiempo de espera de RAM que debe experimentar un programa, el sistema organiza cachés para instrucciones y datos. Si la instrucción o los datos requeridos ya están en el caché, se produce un acierto en el caché y el procesador puede usar inmediatamente la instrucción o los datos en el siguiente ciclo. De lo contrario, se produce una pérdida de caché, acompañada de un tiempo de espera de RAM.

En algunos sistemas, hay dos o tres niveles de caché, a menudo llamados L1, L2 y L3. Si una referencia de memoria especial provoca una falla en L1, se verifica L2. Si L2 produce un error, la referencia pasa al siguiente nivel, ya sea L3 (si está presente) o RAM.

El tamaño y la estructura de las cachés varían de un modelo a otro, pero los principios para utilizarlas de forma eficaz son los mismos.

Canalización y registros

La arquitectura superescalar canalizada permite procesar múltiples instrucciones simultáneamente en algunos casos. Una gran cantidad de registros de propósito general y registros de punto flotante hacen posible mantener cantidades considerables de datos de programas en registros sin la necesidad de almacenamientos y recargas frecuentes.

Se pueden diseñar compiladores optimizados para aprovechar al máximo estas capacidades. Al crear un programa de producción, las funciones de optimización del compilador deberían estar disponibles sin importar cuán pequeño sea el programa. Cómo ajustar un programa para obtener el máximo rendimiento se describe en la Guía de optimización y ajuste para XL Fortran, XL C y XL C.

Jerarquía de software

Un programa debe seguir una serie de pasos en una jerarquía de software para poder ejecutarse.

Programa ejecutable

Cuando se solicita la ejecución de un programa, el sistema operativo realiza operaciones para convertir el programa ejecutable en el disco en un programa en ejecución. Primero, se deben escanear los directorios en la variable de entorno PATH actual para encontrar la copia correcta del programa. Luego, el cargador del sistema (que no debe confundirse con el comando ld, que es una carpeta) debe resolver cualquier referencia externa del programa a la biblioteca compartida.

Para representar la solicitud de un usuario, el sistema operativo crea un proceso o un conjunto de recursos (como un segmento de dirección virtual privada) que son necesarios para cualquier programa en ejecución.

El sistema operativo también creará automáticamente un hilo separado en el proceso. Un hilo es el estado de ejecución actual de una única instancia de programa. En AIX, el acceso a los procesadores y otros recursos se asigna por subproceso en lugar de por proceso. Las aplicaciones pueden crear múltiples subprocesos dentro de un proceso. Estos subprocesos comparten los recursos propiedad del proceso que los ejecuta.

Finalmente, el sistema se transfiere al punto de entrada del programa. Si la página del programa que contiene el punto de entrada aún no está en la memoria (quizás porque el programa fue compilado, ejecutado y copiado recientemente), la interrupción por falla de página causada por lee la página desde su almacén de respaldo.

Manejador de interrupciones

El mecanismo para notificar al sistema operativo que ha ocurrido un evento externo es interrumpir el hilo que se está ejecutando actualmente y transferir el control al manejador de interrupciones. Antes de que se pueda ejecutar el controlador de interrupciones, se debe guardar suficiente estado de hardware para garantizar que el sistema pueda restaurar el contexto del subproceso una vez que se complete el controlador de interrupciones. Un controlador de interrupciones recién llamado experimentará todos los retrasos asociados con el ascenso en la jerarquía de hardware (excepto las fallas de página). Si el controlador de interrupciones no se ha ejecutado recientemente (o la rutina intermedia es eficiente en el tiempo), es poco probable que su código o datos permanezcan en el TLB o en la caché.

Cuando se programa nuevamente un hilo interrumpido, su contexto de ejecución (como el contenido del registro) se restaura lógicamente para que pueda ejecutarse correctamente. Sin embargo, el contenido del TLB y el caché deben reconstruirse en función de solicitudes posteriores del programa. Por lo tanto, tanto el controlador de interrupciones como el subproceso interrumpido pueden experimentar importantes pérdidas de caché y latencias de pérdida de TLB como resultado de la interrupción.

Hilo en espera

Siempre que un programa en ejecución realiza una solicitud que no puede satisfacerse inmediatamente, como una operación de E/S síncrona (explícita o como resultado de un error de página), este hilo Estará en estado de espera hasta que se complete la solicitud. Esto a menudo da como resultado cierta latencia de caché y TLB adicional, además del tiempo necesario para la solicitud en sí.

Subprocesos distribuibles

Cuando un subproceso se puede distribuir pero no se está ejecutando, no puede hacer nada útil. Peor aún, otros subprocesos en ejecución pueden hacer que las líneas de caché del subproceso se reutilicen y las páginas de memoria real se desalojen, lo que provoca retrasos adicionales en el envío final.

Subprocesos actualmente enviados

El programador selecciona subprocesos que tienen fuertes demandas sobre el procesador. Las consideraciones que afectan esta elección se analizan en "Descripción general del rendimiento del programador de CPU". Cuando se envía un subproceso, el estado lógico del procesador se restaura al estado que estaba vigente cuando se interrumpió el subproceso.

Instrucciones de máquina actuales

En ausencia de TLB o errores de caché, la gran mayoría de las instrucciones de máquina se pueden ejecutar en un solo ciclo de procesador. Por el contrario, si un programa cambia rápidamente a una región diferente del programa y accede a una gran cantidad de datos en diferentes regiones, incurrirá en tasas de pérdida de caché y TLB más altas, y el número promedio de ciclos de procesador utilizados para ejecutar cada instrucción (CPI ) puede ser mayor que 1. Se considera que estos programas tienen capacidades de referencia locales deficientes. Puede que esté utilizando la cantidad mínima de instrucciones necesarias para realizar el trabajo, pero consumiendo muchos ciclos innecesarios. En parte debido a la débil correlación entre el recuento de instrucciones y el recuento de ciclos, examinar la lista de programas para calcular la longitud de la ruta ya no produce directamente un valor de tiempo. Dado que los caminos más cortos son generalmente más rápidos que los caminos más largos, las velocidades varían significativamente dependiendo de la longitud del camino.

Los compiladores reorganizan el código de formas sofisticadas para minimizar el número de ciclos necesarios para la ejecución del programa. Los programadores que buscan un rendimiento óptimo deben centrarse primero en garantizar que el compilador tenga toda la información que necesita para optimizar el código de manera efectiva, en lugar de intentar adivinar las técnicas de optimización del compilador (consulte "Uso efectivo de preprocesadores y compiladores").

La medida real de la eficacia de la optimización es el rendimiento de cargas de trabajo confiables.

Ajuste del sistema

Una vez que la aplicación se implementa de manera efectiva, la mejora adicional del rendimiento general del sistema se convierte en una cuestión de consideración del ajuste del sistema. Los componentes principales incluidos en el ajuste a nivel del sistema son:

E/S de comunicación

Dependiendo del tipo de carga de trabajo y del tipo de enlace de comunicación, una o más de las siguientes comunicaciones pueden Es necesario ajustar el controlador del dispositivo: TCP/IP o NFS.

Disco fijo

El Administrador de volumen lógico (LVM) controla la ubicación del sistema de archivos y el espacio de paginación en el disco, lo que puede afectar en gran medida el tiempo de espera de búsqueda que experimenta el sistema. Los controladores de dispositivos de disco controlan el orden en que se realizan las solicitudes de E/S.

Memoria real

El administrador de memoria virtual (VMM) controla el grupo de fotogramas de memoria real libres y decide cuándo y dónde tomar fotogramas para reponer el grupo.

El hilo en ejecución

El programador determina qué entidad programable recibe el control a continuación. En AIX, las entidades programables son subprocesos. Consulte "Soporte de enhebrado".

Introducción al proceso de ajuste del rendimiento

El ajuste del rendimiento tiene que ver principalmente con problemas de gestión de recursos y la configuración correcta de los parámetros del sistema. El ajuste de cargas de trabajo y sistemas para utilizar los recursos de manera eficiente consta de los siguientes pasos:

Identificar las cargas de trabajo en el sistema

Establecer objetivos:

Determinar cómo medir los resultados

Cuantificar y priorizar objetivos

Identificar recursos críticos que limitan el rendimiento del sistema

Minimizar los requisitos de recursos críticos para cargas de trabajo:

Si se le da un elección, utilice los recursos más apropiados

Reducir los requisitos de recursos críticos para programas individuales o funciones del sistema

Uso simultáneo de recursos estructurados

Modificar la asignación de recursos para reflejar la prioridad

Cambiar la prioridad o los límites de recursos de programas individuales

Cambiar la configuración de los parámetros de administración de recursos del sistema

Repetir los pasos del 3 al 5 hasta alcanzar los objetivos (o la saturación de recursos)

Utilice recursos adicionales si es necesario

Existen herramientas para cada etapa de la gestión del rendimiento del sistema (consulte el Apéndice A "Comandos de monitoreo y ajuste" y subrutinas‖). Algunas de estas herramientas están disponibles en IBM; otras son productos de terceros. El siguiente diagrama ilustra las etapas de la gestión del rendimiento en un entorno LAN simple.

Figura 2. Fases de rendimiento. Este diagrama utiliza cinco círculos ponderados para ilustrar los pasos de ajuste de un sistema para el rendimiento: planificación, instalación, monitoreo, ajuste y escalado. Cada círculo representa un sistema en un estado de rendimiento diferente: inactivo, desequilibrado, equilibrado y sobrecargado. Básicamente, escalar un sistema sobrecargado, ajustar el sistema hasta que esté equilibrado, monitorear el sistema desequilibrado e instalar más recursos cuando sea necesario escalar.

Identificar Cargas de Trabajo

Todo el trabajo realizado por el sistema debe ser identificable. Particularmente en sistemas conectados a LAN, se puede desarrollar fácilmente un conjunto complejo de sistemas de archivos cruzados con poco más que un acuerdo informal entre los usuarios del sistema. Estos sistemas de archivos deben identificarse y considerarse como parte de cualquier actividad de ajuste.

Para cargas de trabajo multiusuario, los analistas deben cuantificar las tasas de solicitudes promedio y máximas. También es importante determinar la proporción real de tiempo que el usuario interactúa realmente con el terminal.

Un elemento en esta fase de identificación es la decisión de si las actividades de evaluación y ajuste deben realizarse en el sistema de producción o si la evaluación y el ajuste deben completarse en otro sistema (o "conmutación") utilizando una versión simulada de la actividad de carga de trabajo real. Los analistas deben sopesar la mayor confiabilidad de los resultados de un entorno de producción frente a la flexibilidad de un entorno de no producción, donde los analistas pueden realizar experimentos con el riesgo de una degradación del rendimiento o algo peor.

La importancia de establecer objetivos

Si bien los objetivos se pueden establecer en función de cantidades mensurables, los resultados reales deseados suelen ser subjetivos, como tiempos de respuesta satisfactorios. Además, el analista debe resistir la tentación de sintonizarse con lo que es mensurable más que con lo que es importante para él. Si ningún sistema proporciona una evaluación que cumpla con las mejoras requeridas, entonces se debe diseñar la evaluación.

El aspecto más valioso de los objetivos cuantitativos no es la selección de números a alcanzar, sino el juicio abierto de la importancia relativa de (normalmente) múltiples objetivos. Si estas prioridades no se establecen de antemano y no son comprendidas por todos los involucrados, los analistas no pueden tomar decisiones de compromiso sin consultas frecuentes. Los analistas también son propensos a sorprenderse por las reacciones de los usuarios o por aspectos del desempeño de la gestión que se han pasado por alto. Si el sistema se admite y se utiliza a través de los límites de la organización, es posible que necesite un acuerdo de nivel de servicio por escrito entre el proveedor y el usuario para garantizar una comprensión clara y coherente de los objetivos y prioridades de rendimiento.

Identificar recursos críticos

A menudo, el rendimiento de una carga de trabajo determinada puede determinarse por la disponibilidad y la velocidad de uno o dos recursos críticos del sistema. Los analistas deben identificar correctamente esos recursos o arriesgarse a operaciones interminables de prueba y error.

El sistema dispone de recursos físicos y recursos lógicos. Los recursos físicos críticos suelen ser más fáciles de identificar porque hay más herramientas de rendimiento del sistema disponibles para evaluar la utilización de los recursos físicos. Los recursos físicos que más suelen afectar al rendimiento son los siguientes:

Ciclos de CPU

Memoria

Bus de E/S

Diferentes adaptadores

Disk Arm

Espacio en disco

Acceso a la red

Los recursos lógicos no se identifican fácilmente. Los recursos lógicos suelen ser abstracciones de programación que particionan recursos físicos. El propósito de la partición es compartir y administrar recursos físicos.

Algunos ejemplos de recursos físicos y lógicos construidos sobre él son:

CPU

Tiempo del procesador

Memoria

Marco de página

Pila

Búfer

Cola

Tabla

Bloqueo y semáforo

Espacio en disco

Volumen lógico

Sistema de archivos

Archivo

Partición

Acceso a la red

Sesión

Paquete

Canal

Es importante comprender los recursos lógicos y físicos. Un subproceso puede bloquearse por falta de recursos lógicos, del mismo modo que puede bloquearse por falta de recursos físicos. La expansión de los recursos físicos subyacentes no garantiza necesariamente la creación de recursos lógicos adicionales. Por ejemplo, considere usar el demonio de E/S de bloque NFS biod. Se requiere un demonio biod en la máquina cliente para manejar cada solicitud de E/S remota NFS pendiente. Por lo tanto, la cantidad de demonios biod limita la cantidad de operaciones de E/S de NFS que se pueden ejecutar simultáneamente. Cuando falta el demonio biod, la instrumentación del sistema indica que solo se está utilizando una pequeña parte de la CPU y los enlaces de comunicación. Es posible que tenga la ilusión de que su sistema está infrautilizado (y es lento) cuando en realidad es la falta de un demonio biod lo que limita los recursos restantes. El demonio biod utiliza ciclos de procesador y memoria, pero no se puede solucionar esto simplemente agregando memoria real o moviéndola a una CPU más rápida. La solución es crear más recursos lógicos (biod daemon).

Se pueden crear inadvertidamente recursos lógicos y cuellos de botella durante el desarrollo de aplicaciones. Los métodos para pasar datos o controlar un dispositivo crean efectivamente un recurso lógico. Cuando dichos recursos se crean accidentalmente, generalmente no existen herramientas para monitorear su uso ni una interfaz para controlar su asignación. Su existencia puede pasar desapercibida hasta que surge un problema de desempeño específico que resalta su importancia.

Minimizar los requisitos de recursos críticos

A continuación se analizan los requisitos de recursos críticos para minimizar las cargas de trabajo en tres niveles.

Utilice los recursos adecuados

La decisión de utilizar un recurso sobre otro debe tomarse de forma racional y con objetivos claros en mente. Un ejemplo de selección de recursos durante el desarrollo de aplicaciones es lograr un equilibrio aumentando el consumo de memoria y reduciendo el consumo de CPU. La decisión de configuración del sistema público utilizada para demostrar la selección de recursos es si colocar los archivos en una estación de trabajo local separada o en un servidor remoto.

Reducción de los requisitos de recursos críticos

Para las aplicaciones desarrolladas localmente, existen varias formas de verificar el programa para que realice la misma función de manera más eficiente o elimine funciones innecesarias. En el nivel de gestión del sistema, las cargas de trabajo de baja prioridad que compiten por recursos críticos pueden trasladarse a otros sistemas, ejecutarse en otros momentos o controlarse mediante un administrador de carga de trabajo.

Uso paralelo de recursos estructurados

Debido a que las cargas de trabajo necesitan ejecutar múltiples recursos del sistema, pueden aprovechar el hecho de que los recursos son independientes y se pueden usar en paralelo. Por ejemplo, el algoritmo de lectura anticipada del sistema operativo detecta el hecho de que el programa está accediendo al archivo de forma secuencial, por lo que programa otras operaciones de lectura secuencial para que se ejecuten en paralelo mientras la aplicación también procesa los datos anteriores. El paralelismo también se utiliza en la administración de sistemas. Por ejemplo, si una aplicación accede a dos o más archivos simultáneamente y si los archivos a los que se accede simultáneamente están en unidades diferentes, agregar una unidad de disco adicional puede aumentar la velocidad de E/S del disco.

Prioridad de asignación de recursos

El sistema operativo proporciona algunos métodos para priorizar actividades. Algunos se configuran a nivel del sistema, como el ritmo del disco. Otros, como las prioridades de los procesos, pueden ser establecidos por usuarios individuales para reflejar la importancia otorgada a tareas específicas.

Repita los pasos de ajuste

Es una perogrullada bien establecida en el análisis de rendimiento que siempre habrá un cuello de botella a continuación. Reducir el uso de un recurso significa que otro recurso está limitando el rendimiento o el tiempo de respuesta. Por ejemplo, supongamos que tenemos los siguientes niveles de utilización en nuestro sistema:

CPU: 90 Disco: 70 Memoria: 60

Esta carga de trabajo está limitada a la CPU. Si una carga de trabajo de ajuste exitosa reduce la carga de la CPU de 90 a 45, se puede esperar una mejora doble en el rendimiento. Lamentablemente, la carga de trabajo actual está vinculada a E/S y tiene la siguiente utilización aproximada:

CPU: 45 Disco: 90 Memoria: 60

La utilización mejorada de la CPU permite que el programa envíe solicitudes de disco inmediatamente , pero luego estamos limitados por la capacidad de la unidad de disco. La mejora del rendimiento podría ser de 30 en lugar de los 100 esperados.

Siempre hay un nuevo recurso clave. La pregunta importante es si se han cumplido los objetivos de desempeño utilizando los recursos disponibles.

Precaución: un ajuste inadecuado del sistema mediante vmtune, schedtune y otros comandos de ajuste puede provocar un comportamiento inesperado del sistema, como una reducción del rendimiento del sistema o de las aplicaciones o bloqueos del sistema. Los cambios sólo deben aplicarse si el análisis de desempeño identifica un cuello de botella.

Nota:

No existen recomendaciones generales para configuraciones de ajuste relacionadas con el rendimiento.

Aplicar recursos adicionales

Si el rendimiento del sistema aún no puede alcanzar sus objetivos después de que se hayan agotado todos los métodos anteriores, se deben mejorar o ampliar los recursos críticos. Si el recurso clave es un recurso lógico y los recursos físicos subyacentes son suficientes, el recurso lógico se puede ampliar sin costo adicional.

Si el recurso crítico es un recurso físico, el analista debe examinar algunas preguntas adicionales:

¿Hasta qué punto se debe mejorar o ampliar el recurso crítico para terminar con el cuello de botella?

¿El rendimiento del sistema alcanzará sus objetivos? ¿O se saturarán primero otros recursos?

Si hay una lista de recursos críticos, ¿sería más rentable mejorarlos o ampliarlos todos o dividir la carga de trabajo actual con otro sistema?

Parámetros de rendimiento

Al intentar comparar el rendimiento de un software determinado en diferentes entornos, es común encontrar muchos errores posibles, algunos técnicos y otros conceptuales. Esta sección contiene consejos principales. Otras secciones de este libro analizan diferentes métodos para medir tiempos de procesamiento pasados ​​y específicos.

Al medir el tiempo que se tarda en procesar una llamada al sistema (reloj de pared), es necesario obtener un número que consta de:

El tiempo exacto que se tarda en ejecutar las instrucciones del servicio en ejecución

La cantidad variable de tiempo que el procesador se retrasa mientras espera instrucciones o datos en la memoria (es decir, el costo de la caché y las pérdidas de TLB)

El tiempo requerido para acceder al reloj al principio y al final de una llamada Tiempo

Tiempo consumido por eventos periódicos, como interrupciones del temporizador del sistema

Tiempo consumido por eventos más o menos aleatorios, como E/S

Para evitar informar una cifra imprecisa, a menudo se pide que las cargas de trabajo se midan varias veces. Debido a que todos los factores externos aumentan el tiempo de procesamiento, un conjunto de evaluación típico tiene una forma curva