Quizá no me he explicado bien. En primer lugar el script es un poco irrelevante, es solo un ejemplo de muchas situaciones diversas que me he encontrado. Este caso lo he visto desde complejos procesos java en tomcats hasta sencillos scripts. Cito este ejemplo por su aplastante sencillez: compara dos cadenas de texto recogidas de un archivo de texto con grep y si cumplen una condicion, hace un sed.
Procesos o tareas "sencillas" que ni de lejos usan todos los recursos. Así como también el hardware en el que se corre, ya que he probado en hardware diferente, desde un laptop convencional hasta servidores de mi trabajo con mucha capacidad. No existen cuotas de CPU (en respuesta a manolo) y todos tienen configurado como scheduler un CFQ. Pero no he caído en abordar el problema por esa vía, y voy a realizar pruebas con otros scheduler (gracias por la sugerencia, camaleón) Son maquinas y seguro que tiene una explicacion. Pero si fuese un problema sencillo no lo compartiría con vosotros. ;) El día 7 de octubre de 2015, 16:20, fernando sainz <fernandojose.sa...@gmail.com> escribió: > El día 6 de octubre de 2015, 20:30, Alex <darthc...@gmail.com> escribió: >> Aunque el disco sea mas lento que la cpu 500 kb/s no me parece que sea >> precisamente un stress... A eso me refiero >> >> Enviado desde el dispositivo móvil >> > > No acabo de entender lo que dices. > Si tu disco va una velocidad de 500 kb/s y tu procesador a varios Ghz > aunque necesitara varios ciclos de reloj para cada byte le sobrarían > muchos... > > De forma simplificada, los procesadores se comunican con los > periféricos mandando una orden y quedándose haciendo otras cosas hasta > que reciben una señal (interrupción) indicando que ha finalizado la > tarea y que se puede mandar la siguiente. > > Incluso suponiendo que el S.O. cachee las operaciones de disco, > seguirá cada cierto tiempo sincronizando con el disco, lo que siempre > será lento. > > > S2. > -- -Alejandro Izquierdo-
