overloaded - performance disk linux
Cómo hacer que la GUI de Linux sea "utilizable" cuando hay mucha actividad en el disco (4)
Si empiezo a copiar un enorme árbol de archivos de una posición a otra o si algún otro proceso comienza a hacer gran cantidad de actividad en el disco, la aplicación de primer plano (GUI) reduce la velocidad. Por ejemplo, tome un árbol de archivos de 2 gb con 100k archivos en él. Abra una consola y realice cp -r bigtree bigtree2. Luego ve a Firefox y comienza a navegar. Firefox es casi inutilizable. Incluso si configuro el buen nivel de Firefox en alta prioridad (-20), sigue siendo super lento con grandes retrasos.
Recuerdo que hace algunos años, cuando trabajaba en una caja de Solaris, el sistema se comportaba mucho mejor en circunstancias similares.
Mi HD está usando DMA, no PIO. Es SATA. No montado con la bandera atime.
Asegúrese de que DMA esté habilitado en todas sus unidades que lo admitan. Dependiendo de su distribución, este puede no ser el predeterminado. Lea man hdparm , y mire en su mecanismo init sistemas.
Linux siempre ha tenido un problema con programas que acaparan toda la memoria caché "sucia" del sistema. Lo que está sucediendo es que el proceso de copia está llenando la caché de escritura con los datos de archivo que está copiando y lo está haciendo muy rápidamente. Entonces, cuando Firefox aparece y necesita escribir, primero debe esperar un espacio sucio en el búfer o una ranura disponible para escribir en la cola del disco. Mientras espera, compite con el proceso de copia y el subproceso pdflush del kernel, que mueve los datos de los buffers sucios a la cola de escritura del disco.
Firefox tiene otro problema en este escenario. Utiliza SQLite para almacenar sus marcadores, historial y otras cosas. SQLite es una base de datos compatible con ACID y utiliza un sistema de transacción con sus grabaciones de disco en el disco . Por lo tanto, no solo tiene que esperar al espacio en el búfer, sino que debe esperar a que la cola del disco, que está llena de archivos copiados, se borre antes de que pueda confirmar una escritura exitosa.
Se han realizado muchos ajustes en el sistema de almacenamiento en búfer y en cola de discos de Linux. Hay cambios en casi todas las versiones del kernel. Pruebe uno de los lanzamientos más nuevos. También puede intentar ajustar los valores de sysctl. En cierto modo me gustan estos:
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 9000
vm.dirty_background_ratio = 4
vm.dirty_ratio = 80
También puede intentar ajustar el número de ranuras en la cola del disco. Este valor está en /sys/block/sda/queue/nr_requests . Necesitas sustituir a sda con lo que realmente sea tu disco. Más ranuras significa más posibilidades de combinar solicitudes de IO y el planificador de IO de CFQ puede hacer un mejor trabajo con las prioridades. Menos espacios normalmente significa una espera más corta para escribir en el disco para IO sincrónico, como las transacciones de SQLite. Menos espacios también significa una espera más corta para leer IO en la cola del disco si un proceso de escritura llena completamente la cola con escritura IO.
No eres el primero en notar este problema. El antiguo desarrollador de Kernel [Con Kolivas] ( http://en.wikipedia.org/wiki/Con_Kolivas ) descubrió que muchas compañías están pagando para mejorar el rendimiento del servidor de Linux a expensas del rendimiento de su escritorio . Con tenía un impresionante conjunto de parches para hacer que el escritorio fuera más receptivo . Desafortunadamente hubo una especie de guerra de códigos y eventualmente Con se abandonó .
Me encantaría saber cómo solicitar a los desarrolladores del kernel de Linux un mejor rendimiento de escritorio. Mientras tanto, si está dispuesto a ejecutar kernel 2.6.22, puede ejecutarlo con el -ck parches -ck .