Iniciamos la clase explicando como hacer la práctica final:
El objetivo de una comparativa nunca es la propia comparativa.
Al final tiene que haber un índice numérico que indique claramente cual es el mejor sistema (modo gráfico o tabla)
1º Elegimos un sistema base. Si vamos a mejorar un sistema el sistema base será el inicial sin mejora alguna.
1ª mejora->A
2ª mejora->B
Si tenemos Windows (A o sistema base) y Linux (B puesto que será mas eficiente que A)
Cuidado con las medidas, si son del tipo mayor es mejor o menor es mejor.
El sistema base su índice será 1.
A B IA IB
M1 3 5 1 1.66
M2 2 6 1 3
1 2,2 (media geométrica)
Media geométrica de B=raizCuadrada(IB(A)*IB(B))
La última frase del trabajo será: El sistema base tiene un índice 1 y el mejor sistema es Y con índice X para la mejora planteada en el objetivo.
El índice se calcula de forma distinta si las medidas son distintas (por ejemplo una de tipo Mayor es Mejor y otra Menor es Mejor). Los índices siempre son de tipo Mayor es Mejor.
Errores:
-No pantallazas
-Tabla-gráfico: sólo una al final.
-No poner los pantallazas de los Benchmark, presentarlos en uno final.
- Tratar de ser breves. No más de 10 páginas (vista de impresión).
-Poner las características del sistema sobre el que vamos a hacer la práctica
-Comparar mínimo 3 sistemas.
La práctica estará suspensa si no ponemos el índice final.
Baja puntos:
-Gráficos mal etiquetados.
Fecha de entrega: día del examen o un poco después, según cuando caiga.
-Vemos el resumen de la clase anterior de yuyumk.
Continuamos con el temario:
3.7. Optimización de la red:
-Desabilitar redirecciones o ignorar el Ping. Para ello deshabilitamos el protocolo ICMP que es el que se encarga de ello.
-CheckSum: lo suele hacer el procesador, pero algunas tarjetas también pueden.
Rx-checksumming: suma de reopción
Tema 4: Selección y configuración de sistemas informáticos: Benchmarking
Un benchmark es un programa o conjunto de programas que evalúan las prestaciones de un sistema informático reproduciendo una carga de trabajo genérica en dicho sistema informático.
Para evaluar las prestaciones de un sistema informático es necesario conocer y caracterizar previamente cuál es la carga de trabajo.
Para escoger o diseñar un buen paquete benchmark deben de seguirse los siguientes pasos:
- Determinar los objetivos de uso del benchmark
- Analizar la carga de trabajo de los distintos sistemas.
- Escoger los programas según los objetivos.
- Escoger las métricas o mediciones que se van a tomar sobre el sistema. Para ello debemos establecer un sistema base y siempre tenemos que usar el mismo.
- Se deben de tener en cuenta todos los factores que influyan en el rendimiento.
- Establecer uno de los sistemas de comparación como sistema base, y referir el resto de las medidas a él.
Vemos un ejercicio de Tupakamaru.
En comparativas no usar medidas de usos de recursos (CPU, memoria…)
Se usan varias copias simultáneas para que se vea que en unas condiciones uno es más lento que otro.
Explicamos la práctica 6: programación de un benchmark portable.
Este debe funcionar al menos en windows y Linux.
Calcular el tiempo que tarda, o le espacio que ocupa,…
Que tarde 5 o 6 minutos, lo suficiente como para que se vena diferencias significativas entre los distintos sistemas.
Fecha de entrega-> 2 de Junio (tiene 3 sesiones de prácticas)
El día 27 de mayo no hay clase.
Terminamos la clase viendo los videos del día.
martes, 13 de mayo de 2008
29-04-08
¿De qué va el Tema 3? Comenzamos la clase haciendo un breve repaso a lo visto en el tema 3 (monitores de prestaciones).
Se avisa de que las bitácoras alojadas en blogspot.es deben cerrarse.
Vemos algunos de los ejercicios de autoevaluación:
De http://dyec2008.blogspot.com/
Los pen usan sistema de archivos vFAT32.
Sistemas de ficheros raros:
- GmailFS: montamos la ruta con Gmail como si fuese un directorio.
Sería interesante ver Gmail y sus prestaciones comerciales.
http://tupakamaru.wordpress.com/2008/04/25/ejercicios-autoevaluacion-362/
La práctica 5 se entrega el 5 de Mayo.
A continuación vemos una comparativa entre cartuchos de tinta:
http://www.trustedreviews.com/printers/review/2007/04/21/The-Inkjet-Investigation/p3
En este ejemplo el objetivo sería comparar cartuchos de tinta originales y piratas.
Vemos que está mal pues no es objetivo (compara calidad, brillo...)
Continuamos con la teoría
3.6.1 Consideraciones sobre la configuración.
Hay dos formas de hacer RAID:
- Mediante software: lo hace el Sistema Operativo. Hacemos particiones gemelas y replicamos los datos.
- Mediante hardware: directo sobre el disco duro. Es mejor puesto que se encarga la propia placa base.
3.6.2 Particiones y filesystems
En Linux podemos usar particiones dedicadas a los siguientes fines:
-Swap
-/home: para usuario
-/var: para registros del sistema y spool
-/usr: programas del sistema
-/opt: programas de pago o con algo particular
En todas ellas hay tipos similares de ficharos.
Debemos tener un mínimo número de particiones, pero no demasiadas pues perdemos mucho espacio si no las ultimamos mucho.
Sda: disco a del sistema (el primero).
En cada partición suele haber un filesystems; y un sistema UNIX suele tener muchas particiones en cada disco, aparte de varios discos en cada sistema.
3.6.6 Usando
Modificando diversos parámetros en
Vemos algunos trucos para mejorar el sistema desde
3.7 Optimización de la red
Servidor web: almacena
Vemos el servidor Web de la bitácora de JJ y como se almacenan las peticiones.
Las peticiones llegan con parámetros como: IP, user, clave, petición, sitio desde donde llega…
Hacemos una petición DNS inversa.
También hacemos una petición, y comprobamos cuanto tiempo se mantiene dicha petición. Esto se hace con el fichero de configuración de Apache apache2.conf
La distancia en Internet se mide con traceroute
Espanix.net: punto de interconexión entre redes.
Nos fijamos en la página barrapunto:
-barrapunto.com: servidor dinámico
-Images.barrapunto.com: servidor de imágenes.
- También dispone de otro servidor para publicidad.
Así mejora el número de peticiones que ofrece.
Por último, vemos el video del día.
jueves, 17 de abril de 2008
15-4-2008
Comenzamos la clase analizando los gráficos del último anuncio de Movistar,
Se emplea el dato real (los millones de clientes en esa ocasión) para definir una de las dimensiones de un área o un volumen, y no para definir el área o el volumen completo. Esto provoca una magnificación de las diferencias que solo puede clasificarse como un engaño y una manipulación interesada.
A continuación vemos el ejercicio 3.1. de autoevalucación de tupakamaru.
Uno de los parámetros al medir un sistema es la disponibilidad.
SL (Service Level): nivel de disponibilidad del servicio.
En este tema veremos reglas y políticas para mejorar un sistema en general.
Minimizar el tamaño de las fotos
Usar ModGZip, que es un módulo de Apache que comprime sobre la marcha las páginas que recibe.
Alojar las imágenes en sitios gratuitos de alojamiento de imágenes
Servir imágenes de otros sitios
Usar mod-rewrite, que es otro módulo de Apache que reescribe el resultado que va a dar el servidor
¿Cómo saber el nivel de servicio que estamos dando y cuando se a pasar del límite? Configurando herramientas de monitorización, como por ejemplo logwath que mira el reloj del sistema, y los demás que queramos ver, configuramos las reglas sobre cuándo queremos salir, y que nos avise cuando sucede algo.
3.3 Políticas de gestión del sistema
Tanto los usuarios como el administrador pueden mejorar el funcionamiento del sistema. Algunas medidas que se pueden tomar son:
- Eliminar daemons inútiles y malos para el alma de la máquina. Como ejemplo eliminamos: sudo /etc/init.d mysql pues no lo estamos usando.
Nice: en función de la carga del sistema cambia la prioridad de un proceso de forma dinámica.
Ulimit –a: dice las limitaciones del sistema.
Es el primer ensayo para el trabajo final de la asignatura, por lo que es bastante importante.
Tenemos una plantilla que podemos usar. La fecha de entrega es el 7 de mayo.
Para finalizar vemos el vídeo del día.
8-4-2008
Comenzamos la clase hablando de las prácticas. Recordamos que se pueden volver a entregar las prácticas anteriores hasta el día 24 si queremos subir nota, pero que en esta ocasión puntuarán hasta 8.
Comentamos prácticas anteriores:
En la práctica 2 uno de los errores que se comentó fue el de las faltas de ortografía, incluir imágenes que estaban mal enlazadas y confundir monitor con benchmark.
En la práctica 3, vimos la práctica de Miguel Ángel Medina Medina que había aplicado el profiler sobre un programa que calcula la sucesión de Fibonacci, y tras esto vimos los errores comunes de la práctica 3
Por último acordamos que la 4ª práctica se podía entregar hasta el 21 de Abril
Después vemos una comparativa entre Vista y XP. No se debe usar la carga de los sistemas para compararlos, en vez de esto, es mejor comparar mediante una medición de prestaciones como lo que tarda abrir x ventanas….
Ejercicios de autoevaluación del tema 2 de Vkthor sobre diagramas de líneas y barras.
Líneas: funciones o variables que sigan una progresión determinada.
Barras: se usan para representar variables categóricas.
Medio punto del trabajo final puede depender de que usemos bien los diagramas (líneas o barras)
Continuamos con la teoría:
Tema 3, solución de problemas en un sistema informático
- Ajuste de parámetros del sistema operativo: muchos de los parámetros del kernel ya se pueden modificar desde filesystem/proc tales como el tamaño del quantum, la prioridad de algunos programas…
- Ajuste de parámetros del hardware: son parámetros de
- Equilibrado de cargas: repartir las cargas a las que son sometidos los diversos dispositivos, como red, discos duros, entre las diferentes máquinas que las gestionen y personas que lo usan, o repartir los ficheros entre los diferentes filesystems del sistema. Por ejemplo si disponemos dos discos duros usar uno para procedimientos del user y otro para bases de datos. Si las bases de datos apenas se usan tendremos un disco muy cargado y otro ocioso, por lo que deberíamos equilibrarlos.
- Ampliación: añadir nuevos dispositivos al sistema.
- Cambio del software: puede ser una actualización de una parte del sistema o cambiar a una versión superior, o cambiar el software que se está usando por otra versión u otra marca.
Conviene también tener en cuenta una serie de principios a la hora de mejorar las prestaciones de un sistema:
- Conoce y comprende tu entorno: saber todo lo que hace el sistema.
Lsof: lista todos los procesos del sistema y los archivos que tiene abiertos cada uno de ellos
lsof | grep
- Hay que buscar el equilibrio: Por ejemplo, no se puede mejorar la velocidad percibida por un usuario sin empeorar la de todos los demás usuarios; no se puede optimizar al máximo un programa sin aumentar, como mínimo, el tiempo que se le dedica al mismo.
- Throughput contra latencia: el throughput se refiere a la cantidad de cosas que se pueden hacer, o transmitir, en la unidad de tiempo. La latencia, es el tiempo total que tarda en hacerse algo. Por ejemplo, en una red, la latencia sería el tiempo que tarda un paquete para transmitirse de un punto a otro de la red, mientras que el throughput sería la cantidad de bytes que la red es capaz de soportar.
- No sobreutilices un recurso: ningún recurso usado al 100% estará al óptimo de su capacidad, sino más bien por encima. Esta medida es del tipo Nominal es Mejor.
- Diseña las pruebas con cuidado: aplica el primer principio, y mira bien lo que vas a medir antes de medirlo.
Después de esto hicimos algo de los ejercicios de autoevaluación de este apartado para tener una idea.
lunes, 7 de abril de 2008
1-4-2008
Empezamos la clase viendo el ejemplo del profiler usando un programa en Perl. El profiler que trae Perl se llama DpProf.
Vemos que en la llamada a una función es en lo consume la mayor parte el programa, y entonces ejecutamos la misma función pero guardando en una caché los argumentos y las llamadas a función. Con esto conseguimos ahorrar un 5%-6% del tiempo.
El tiempo total que tarda en ejecutarse el programa siempre debe ser menor, ya que si mejoramos una función que tardaba mucho, pero a causa de eso otras tardan más no habremos mejorado nada.
Vemos un programa en brainfuck (es un lenguaje de programación esotérico, diseñado por Urban Müller en 1993, con el objetivo de hacer un lenguaje que fuera a la vez muy simple, Turing completo y que requiriese un compilador pequeño)
Recapitulación de la clase anterior:
Víctor explica su práctica 2.
Vemos un ejercicio de autoevaluación de tupakamaru sobre las distintas métricas.
El uso de recursos no se debe usar para medir prestaciones.
Seguimos con el temario:
1.5.4 Programas de monitorización de la actividad del sistema
Filesystem: mapeo de la memoria del sistema de ficheros.
Disksksts: muestra estadísticas de los discos
Otros programas sirven para evaluar las prestaciones de una red; o al menos los retrasos que la red introduce en las prestaciones de un ordenador.
Vmstat, Ping, Traceroute
Ejecutamos un programa a modo de ejemplo para ver los cambios del sistema (con vmstat) antes y después.
Vemos que el tiempo de CPU dedicado a user o system cambia y que la memoria apenas cambia.
Top: para ver que se está ejecutando y la carga del sistema.
Y con esto terminamos el tema 1.
TEMA 2. Representación gráfica aplicada a la evaluación de prestaciones
Hay que representar las cosas de forma sencilla y comprensible. Usaremos los gráficos de Gantt se representa en abscisas el tiempo, y en ordenadas una línea que representa los instantes durante los cuales un recurso ha estado ocupado.
A partir de la gráfica de Gantt se puede hacer análisis de Pert, con el objetivo de calcular caminos críticos es decir, en qué puntos se debe concentrar más esfuerzo para que el proyecto llegue a término) y demás.
En ellos se suele colocar alternativamente magnitudes del tipo “más alto es mejor” con magnitudes del tipo “bajo es mejor”. Una de las distribuciones puede ser, en sentido e las agujas del reloj, CPU ocupada, sólo CPU, CPU y un canal, un canal sin CPU, un canal activo, CPU esperando, CPU usuario, CPU sistema, alternando índices de uso con índices de solapamiento, e índices del tipo HB (más alto es mejor) con otros del tipo LB (más bajo es mejor).
2.2 Reglas para representaciones gráficas
R: programa de estadística que también sirve para hacer representaciones gráficas.
Reglas de las representaciones gráficas:
- Minimización del esfuerzo por parte del lector: fácil de entender
- Maximizar información: información suficiente pero no excesiva.
- Minimizar la tinta: intentamos transmitir la mayor cantidad de información con la menor cantidad de tinta.
- Usar prácticas comúnmente aceptadas: como el eje x para la variable independiente, el y para el resultado, el origen en el (0,0) que este en la esquina inferior izquierda, las abscisas y ordenadas en orden creciente.
- Evitar la ambigüedad: mostrar los ejes, las subdivisiones, las medidas, escalas, identificar cada una de las barras, hacerlo fácil de leer. Por ejemplo, si representamos distintas categorías en el eje horizontal hay que usar el mismo orden que el explicado en el texto.
- No poner demasiada información ni demasiada poca.
2.3 Errores comunes en la representación gráfica de resultados
- Presentar demasiadas alternativas en un solo gráfico: a partir de 7 objetos el número de objetos que se recuerdan decrece. Histograma: representación de la frecuencias de los distintos intervalos.
Por ejemplo la cantidad de tiempo que una CPU está en cada intervalo.
- Presentar muchas variables y (abscisas) en un solo gráfico: sobre todo si tienen diferentes escalas, ahorra espacio pero hace que la información se confunda. No representar más de 4 o 5.
- Usar símbolos en lugar de texto: en vez del nombre dado a una variable, debería usarse lo que contiene una variable; por ejemplo, en vez de %CPU, se debería usar Porcentaje de CPU dedicado al usuario, en un tipo de letra más pequeño, ya que lo que buscamos es que el usuario tenga que hacer el menor esfuerzo posible a la hora de entender nuestro gráfico.
- Seleccionar mal las escalas: muchas veces es mejor hacerlo a mano que automáticamente.
- Usar un gráfico de líneas en vez de uno de barras: en variables categóricas, se debe de usar un gráfico de barras.
A veces estas equivocaciones se suelen hacer a propósito, sobre todo si uno quiere demostrar algo con los gráficos.
El saber este tipo de cosas ayuda también a identificarlas cuando uno se las encuentra:
- Usar orígenes no nulos para hacer énfasis de la diferencia: cuando la diferencia es pequeña, se usa un origen no nulo para que parezca más grande.
- Trazar cantidades aleatorias sin los intervalos de confianza: la media transmite poca información si no se acompaña de la desviación típica, o rango o algún momento (medir ancho de banda).
- Usar pictogramas escalados por altitud: a veces se usan barquitos, o cochecitos... Siempre hay que tener en cuenta que es la altura, y no la superficie, lo que representa la cantidad.
- Usar tamaños de célula no adecuados en histogramas, y usar escalas partidas en gráficos de columnas. En el primer caso, hay que aplicar tests estadísticos para comprobar que se haya hecho adecuadamente; siempre tendrá que haber al menos 5 puntos experimentales en cada cubo (cuando hay una gran dispersión aleatoria en las variables).
Con esto terminamos el tema 2.
Para finalizar la clase explicamos la práctica 4 de forma breve.
Video del día : Gráficas de Gantt con Excel
lunes, 17 de marzo de 2008
CLASE 11-3-2008
La clase comienza comentando la práctica 1.
Actualidad: Vemos una noticia en la web sobre los sistemas multicore, Nvidia ha creado una gráfica con 128 cores.
¿Cómo se gestiona una gráfica con 128 cores, a 1´35 Hz? Cada uno procesa 3 o 4 bit, de forma simétrica. Esto sirve para procesar texturas…
El número de cores se doblará cada 18 meses, por lo que los cores se deberían dedicar a temas específicos, para aprovechar su capacidad (E/S,..)
A continuación comentan varios ejercicios de autoevaluación.
Seguimos con el temario.
1.5 Medición de la carga de un sistema
Carga del sistema: número medio de procesos que están esperando para ejecutarse.
Para medir la utilización de sistemas informáticos se usan los denominados monitores, que son herramientas de medición que permiten seguir el comportamiento de los principales elementos de un sistema informático cuando éste se halla sometido a una carga de trabajo determinada.
Comprobamos la carga del sistema con el comando top, y matamos al proceso que consume más CPU (sudo kill
En linux para ver las estructuras de datos se hace con filesystems virtual llamado /proc. Todos los procesos de root aparecen como un fichero (ls –alt).
Los maps son ficheros de los mapas de memoria (cat maps).
Los profilers son trozos de código linkados a un programa, y que son llamados cada cierto tiempo para medir el uso de esa parte del programa. Hay dos tipos: por muestreo y por poling.
Estos nos ayudan a detectar el código que el programa ejecuta más veces o tarda más (subrutinas,..). Una vez detectado, modificamos el código (por ejemplo cambiando por algoritmos más eficientes como Quicksort, o actualizando el valor de las variables antes de los bucles en lugar de dentro,..). Con está práctica el programa será mucho más rápido.
Otro método para disminuir el tiempo de ejecución, aunque poco aconsejado es desenrollar un bucle (copiar las veces que se ejecuta el bucle seguidas).
Para compilarlo se pone la opción -pg en la línea de comandos (bash$ gcc -pg mipogama.cpp -o mipogama).
Gprof-> Segundos que tarda cada subrutina, número de llamadas (no es igual gastar mucho tiempo en realizar muchas llamadas que en pocas), número de milisegundos por llamada.
Ejemplo. Ejecutamos un programa y vemos que el 2% del tiempo clona vectores, un 14% del tiempo lo consume en comprobar el número y la corrección de los parámetros que le pasamos…, por lo que estas serían las partes del programa que deberíamos mejorar.
Existen profiler en todos los lenguajes de programación (Java, php, C...)
1.5.2 Métricas de la carga de trabajo más comunes.
Se usan para ver lo bien/rápido/lento que va nuestro sistema.
- Throughpout: número de peticiones procesadas en la unidad de tiempo, es del tipo mas es mejor (por ejemplo, en una impresora el número de páginas que imprime por unidad de tiempo).
- Tiempo de respuesta: tiempo que se tarda en procesar una petición, por tanto opuesto del throughput.
- Eficiencia: diferencia entre throughput máximo y el throughput efectivo (por ejemplo, en ADSL es el número de bytes reales recibidos por unidad de tiempo).
- Ancho de banda: bits por segundo que es capaz de procesar el sistema, no confundir con baudios que son cambios de estados en la línea en la unidad de tiempo.
- Porcentaje de utilización de diversos componentes y solapamiento entre los mismos. A mayor solapamiento mayor eficiencia.
- Overhead: tiempo usado en tareas que no son directamente del usuario.
- Factores relacionados con la multiprogramación: como el tiempo usado en cambiar de contexto.
- Factores relacionados con la memoria virtual: fallos de página, swapping.
- Factores relacionados con la memoria caché: número de veces que se vacían los buffer TLB.
- Otros subsistemas: red, gráficos...
1.5.3 A qué se dedica el tiempo
Antes de intentar mejorar las prestaciones de cualquier sistema, es decir, hacerlo más rápido (al menos en algún aspecto), hay que saber en qué invierte el tiempo el sistema.
Para medir el tiempo que tarda en ejecutarse un programa, una de las medidas básicas de las prestaciones de cualquier sistema, se puede ejecutar una utilidad tal como /bin/time, /usr/bin/time o timex, que son el equivalente en las dos versiones del sistema operativo; y que son diferentes a una función del shell, también llamada time.
- Tiempo de usuario: tiempo que se tarda en ejecutar el código del usuario.
- Tiempo del sistema: tiempo que se tarda en hacer las llamadas, funciones de kernel...
- Tiempo de Entrada/Salida: tiempo que se pasa esperando a que algo suceda (que el usuario pulse el ratón, introduzca datos...)
Explicamos la práctica 3, uso de un profiler. En ella hay que interpretar lo que dice el profiler (la mayor parte del tiempo se gasta en tal subrutina...).
Para nota, mejorar el programa y poner los tiempos de ambos o indicar posibles mejoras. No confundir el tiempo de llamada con el de ejecución.
También concretamos las fechas de entrega de las prácticas 2 y 3:
Practica 2-> 31 Marzo.
Práctica 3-> 6 Abril
Para finalizar vemos el video del día: profiling de una aplicación web con C++.
lunes, 10 de marzo de 2008
EJERCICIOS AUTOEVALUACIÓN
1 Ejercicios de autoevaluación
- Mencionar sistemas operativos que no estén entre los anteriores, y el nicho de mercado que suelen cubrir.
BeOS es un sistema operativo para PC desarrollado por Be Incorporated en 1990, orientado principalmente a proveer alto rendimiento en aplicaciones multimedia.
Symbian es el sistema operativo para móviles más extendido. Fue diseñado pensando en dispositivos móviles, lo que hace que sea muy robusto (es raro que se 'cuelgue') y muy espartano con sus necesidades: ahorra siempre que puede espacio en memoria y apaga el procesador cuando no se utiliza, aumentando la vida de la batería.
Windows Mobile, antes conocido como Windows CE o Pocket PC, tiene una larga historia como segundón en el campo de los PDA u ordenadores de bolsillo, sin embargo hace pocos meses superó por primera vez al hasta entonces líder, Palm OS.
2. Ejercicios de autoevaluación
1. Indicar qué tipo de medidas sueles tomar para medir las prestaciones de un ordenador.
Uso un programa específico para ello llamado Everest que es un sistema de diagnóstico que incluye testeos de memoria, monitorización del hardware e información de hardware.
2. Indicar en qué casos de los que te encuentras en tu trabajo (u otro quehacer) diario necesitarás medir las prestaciones del ordenador
Normalmente no lo necesito.
3. Indicar en qué casos percibes una falta de prestaciones de los ordenadores que sueles manejar.
Cuando al usar una aplicación habitual va más lenta de lo normal y tarda en responder, llegando incluso a colgarse el sistema.
También cuando se produce un excesivo tiempo de arranque, o en el acceso a carpetas, archivos, …
4. Mirar qué servicios hay activos en nuestro ordenador personal y en algún otro ordenador al que tengamos acceso. ¿Qué usas para saber los servicios que hay activos? ¿Sabes lo que hacen? ¿Si suprimes alguno de ellos, qué pasa?
Descripción de algunos de los servicios:
Smss.exe es el Subsistema Administrador de Sesiones (Session Manager Subsystem) y es un proceso esencial para el sistema.
Csrss.exe: Archivo y proceso de los sistemas operativos Windows. Forma parte de los sistemas Windows NT, 2000, XP y 2003. CSRSS significa Client Server Runtime SubSystem. El proceso se encarga de controlar las API Win32.
En general, se trata de un proceso normal en algunas versiones de Windows, de todas maneras, muchos programas malignos pueden emplear el mismo nombre (o un nombre similar) para camuflarse y pasar desapercibidos.
Lsass.exe: Archivo y proceso fundamental de los sistemas operativos Windows. Se encarga de los mecanismos de seguridad local y las políticas de autentificación de los usuarios del sistema.
Los virus y programas malignos suelen usar nombres parecidos a este para pasar desapercibidos (por ejemplo, lass.exe). Se debe verificar que la ruta del archivo sea C:Windowssystem32.
Svchost.exe, es el nombre de un proceso en los sistemas operativos Windows más actuales. Su nombre es "Microsoft Service Host Process".
Solamente está presente en Windows 2000 y XP.
El proceso se ejecuta al iniciar el sistema, y chequea parte de los servicios del registro para hacer la lista de servicios que deben abrirse. Por lo general, múltiples instancias del proceso Svchost.exe son ejecutadas al mismo tiempo. Cada una de estas instancias puede contener un grupo de listas de servicios.
Este agrupamiento de servicios permite un mejor control y fácil depuración, pero también causa algunas dificultades a los usuarios. Esto se debe a que el mismo nombre de archivo es utilizado por virus, espías, caballos de troya y otros malwares para ocultar su actividad.
Mmc.exe: Archivo y proceso de Windows 2000, XP y 2003, que administra las consolas de servicios. Es un proceso esencial cuando se emplean algunas herramientas del sistema.
Alg.exe: Archivo y proceso que forma parte del sistema operativo Windows. Forma parte del servicio "Application Layer Gateway" de Windows XP. ALG.exe forma parte del ICS (Internet Connection Sharing) y ICF (Internet Connection Firewall) de Windows.
Se trata de una tarea del sistema de Microsoft y, en general, no representa ningún riesgo para el sistema y no debe ser desactivado. De todas maneras, muchos softwares malignos pueden usar el mismo nombre o similar para aparentar ser procesos no peligrosos.
System: Proceso presente en los Windows NT4, 2000 y XP que almacena la configuración del hardware y el software del sistema.
Es un proceso esencial en el sistema y no debería ser terminado.
Si suprimimos la mayoría de los anteriores no pasará nada, sólo se cerraría el programa asociado, otros volverían a ejecutarse automáticamente si los suprimimos, pero al suprimir otros como System podrían provocar cuelgues, o forzar un reinicio del sistema.
Suscribirse a:
Entradas (Atom)