buenos dias!
tengo que hacer un chequeo de un servidor por un 'supuesto' bajo rendimiento.
El equipo es un SunFire V60 y corre Fedora 4 con una aplicacion en rm-cobol.

hasta el momento hice un script para guardar info del sistema cada 5 minutos, pero me gustaría que den opiniones y, porque no, mejoras.

start-monitoreo

mato el proceso con stop-monitoreo

luego lo meto en el crontab

me haría falta algún análisis de disco, pero no se que comando usar.
¿alguna otra cuestión que se me esté escapando?

ojalá le sirva a alguien como esqueleto para otros scripts similares.
saludos y gracias

Puntualmente ke tipo de analisis de disco deseas?

quisiera ver si es posible la carga de trabajo del disco.
amplio un poco mas:
la aplicación en rm-cobol genera una serie de archivos temporales que se eliminan luego de finalizada una tarea. Estos archivos son generados por conexión. Es decir, si tengo 30 conexiones simultaneas voy a tener 30 juegos de temporales.

quiero saber si esa cantidad de lecturas/escrituras a disco provocan un 'ralentizado' del equipo...

quedó claro??

Cobol es maravilloso en perfomance a disco (manejo de archivos planos). Si el código ya fué optimiazado y persiste el problema, una muy buena opción es distribuir la lecto/escritura en múltiples discos.
Comprobado en muy alto volumen transaccional.

Este mensaje fue modificado por última vez en: 06-11-2007 02:40 PM por p_eter.

jajaja... desconozco que tan bueno o malo sea cobol...
como me pidieron que viera donde está el problema de performance del equipo (ya que notan el sistema lento) se me ocurrió verificar todas las variables posibles... incluída la red física que no quieren renovar: horribles cascadas de hubs con switch, cableado deteriorado, etc.

como no quieren 'gastar' en renovar la red, entonces si les llevo un informe detallado del rendimiento del equipo demostrando que funciona bien, voy a poder forzarlos a que cambien lo que sea necesario.

Con iostat podes ver el I/O de disco en tiempo real.

Saludos!

jajaja ta bueno

barbaro!!!
iostat me viene al pelo

voy a terminar el script y cuando lo ponga en marcha los voy poniendo al tanto.
gracias

Actualizo...
ya había dicho que los usuarios entran a través de ssh (aplicación win mediante) al servidor y corren el sistema de gestión. Armé un script para determinar donde viene el problema de que se pone 'lento'.
El script corrió durante una semana, después de analizar en detalle la info encontré que:

46 usuarios utilizan un promedio de 80 sesiones (abren mas de dos en algunos casos)
el sistema está hecho en c y no en cobol como creía (perdon p_eter).
el motor de base de datos 'essentia' por momentos se chupa casi el 90% de micro (durante 10/15 minutos) !?!?!?!
los procesos del sistema de gestión se llaman del estilo tae1234.exe ?!?!?! (exe en linux?)
y que el uso de disco está en un 90%

No querían gastar en cablear la red... JA!
Ahora se les viene peor, porque obviamente la aplicación está tirando abajo el equipo y se están quedando sin espacio. ¿Alguien conoce algo de essentia? ¿es normal que haga eso con un Xeon 2.8GHz y 2Gb de Ram (para mi no)? Si dijera que es Oracle, bueeeno, pero essentia???

Saludos, seguiré investigando.

Ora se banca un creciente # de users. Otras, pues ya ves.
InterSoft Essentia parece que después del 96 no hay noticias.
Con suerte identificas queries que te cuelgan la base.

Este mensaje fue modificado por última vez en: 06-27-2007 08:14 PM por p_eter.

Bueno, cierro el comentario ya que se llegó a un acuerdo y no hay más por hacer ni estudiar.

Ya había aclarado que el sistema era en c, con base de datos essentia.
Después de mi informe, y una reunión entre el proveedor de soft, la empresa en cuestión y el proveedor de hard (nosotros) se llegó a esto:

El requerimiento : esta empresa necesita que sus precios se actualicen con máxima prioridad.

Problema 1: el soft se recompiló para que ejecute con máxima prioridad las actualizaciones de precios
Problema 2: esta priorización acapara el procesador mientras se ejecute dicho proceso. (si el tipo que ingresa la lista de precios le da diarrea y se clava 30 minutos en el baño son 30 minutos que el cpu que ahorcado con un proceso que se chupa mas del 90% de cpu)
Problema 3: en su momento, se ofrecieron 3 opciones de compra y la empresa en cuestión optó por lo más barato, por ende de menor capacidad... (típica argentinada)

Solución 1: recompilar el software para que priorice el proceso pero sin utilizar el máximo de cpu disponible.
Solución 2: realizar una instalación idéntica en un equipo mejor y testear durante un tiempo prudencial.

Obviamente es mejor esta última solución, ya que nos permitiría venderles un server

Bueno gente... será hasta el próximo post.
saludos

Sorry, 2 cosillas de curioso y metido nomás..

1) NIX: En la medida que se pueda, si hiciste un nuevo script estaría piola compartas últimos sh
2) App: No llego a entender el Problema 2, ¿como es eso de la diarrea?


Ah, y sobre el .exe?

Este mensaje fue modificado por última vez en: 07-14-2007 12:08 AM por p_eter.