Saltar al contenido

Cómo hacer que la GUI de Linux sea "utilizable" cuando hay mucha actividad en el disco

Después de tanto luchar pudimos dar con la solución de este enigma que muchos los lectores de esta web han tenido. Si tienes algo que aportar no dudes en compartir tu conocimiento.

Solución:

Linux ha tenido durante mucho tiempo un problema con los programas que acaparan toda la memoria caché "sucia" del sistema. Lo que sucede es que el proceso de copia está llenando el caché de escritura con los datos del archivo que está copiando y lo está haciendo muy rápido. Entonces, cuando aparece Firefox y necesita escribir, primero debe esperar a que haya espacio de búfer sucio o una ranura de escritura de cola de disco disponible. Mientras espera, compite con el proceso de copia y el subproceso pdflush del núcleo, que mueve los datos de los búfer 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 transacciones con sus escrituras en disco vaciado al disco. Por lo tanto, no solo tiene que esperar por el espacio del búfer, sino que debe esperar a que la cola del disco, que está llena de archivos copiados, se borre antes de que pueda reconocer una escritura exitosa.

Ha habido una lote de ajustes realizados en el sistema de almacenamiento en búfer y cola de disco de Linux. Hay cambios en casi todas las versiones del kernel. Pruebe una de las versiones más recientes. También puede intentar ajustar los valores de sysctl. 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 modificar el número de ranuras en la cola del disco. Este valor está en /sys/block/sda/queue/nr_requests. Necesitas sustituir sda con lo que realmente sea su impulso. Más ranuras significan más posibilidades de fusionar solicitudes de E/S y el programador de E/S de CFQ puede hacer un mejor trabajo con las prioridades. Menos ranuras generalmente significa una espera más corta para escribir en el disco para IO síncrono como las transacciones de SQLite. Menos ranuras también significa una espera más corta para obtener E/S de lectura en la cola del disco si un proceso de escritura pesada llena completamente la cola con E/S de escritura.

Intente ionizar o mejorar el proceso de copia. El problema se debe al hecho de que IO tiene la misma prioridad que la GUI, lo que para un escritorio afecta la capacidad de respuesta percibida.

Hay una lluvia de ideas de Ubuntu sobre esto actualmente.

No eres el primero en notar este problema. Antiguo desarrollador del kernel [Con Kolivas] (http://en.wikipedia.org/wiki/Con_Kolivas) descubrió que muchas empresas están pagando por mejorar el rendimiento del servidor Linux a expensas del rendimiento del escritorio. Con tenía un impresionante conjunto de parches para hacer que el escritorio respondiera mejor. Desafortunadamente, hubo una especie de guerra de códigos y, finalmente, Con se retiró.

me gustaria saber como petición a los desarrolladores del kernel de Linux para un mejor rendimiento de escritorio. Mientras tanto, si está dispuesto a ejecutar el kernel 2.6.22, puede correr con el -ck conjunto de parches.

Sección de Reseñas y Valoraciones

Si te ha sido de provecho este artículo, nos gustaría que lo compartas con otros programadores de esta manera contrubuyes a dar difusión a nuestro contenido.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada.