# [kernel] io en root ralentissent le système

## guilc

Hello,

Ca fait quelques temps que je me pose des questions sur les IO en root, qui rendent le système lent et a-réactif, alors que je n'avais pas ce problème avant...

La situation de base : typiquement portage qui décompresse un gros tar, type kernel ou gcc par exemple (ou tout simplement root qui fait la même chose).

Pendant cette opération, le système devient très lent, et le user qui fait tourner X voit de fortes lenteurs de rafraichissement de l'affichage entre autres sur toutes les opérations qui demandent des accès disque (cache navigateur, cache mail, etc...).

Je note que :

1) le changement de I/O scheduleur ne change pas le problème (que ce soit CFQ, anticipatory ou deadline)

2) Si un user autre que root fait la même opération, ça ne pose pas ce problème, il ne génère pas de telles latences

3) Dans mon souvenir, avec des kernel 2.6 beaucoup plus vieux, je n'avais pas ce problème

4) J'ai fait quelques tests avec ionice, ça ne change pas le problème, même en passant la tache en idle...

5) Le problème advient avec un 2.6.23, 2.6.24 ou 2.6.25, sans doute avant, mais je me rappelle plus (de toute façon, le downgrade n'est pas une solution)

6) Le FS en change rien (xfs etx ou reiserfs)

Bref, quelqu'un aurait une idée sur ce problème de latence disque clairement causée par des accès root toujours placés en prioritaires ?

Dans mon idée, ionice aurait dû régler le problème de priorisation des accès, or il n'en est rien...

bref, je prends toutes les pistes pour améliorer ça  :Smile: 

@+

----------

## gglaboussole

salut,

Je ne sais pas si cela à un rapport, mais j'ai constaté de grosses pertes de perfs avec le 2.6.24 (mais pas avant) qui était du à l'option Fair group CPU scheduler  introduite depuis cette version du kernel , j'avais d'ailleurs fait un post "d'avertissement" https://forums.gentoo.org/viewtopic-t-675590-postdays-0-postorder-asc-highlight-avertissement-start-0.html

J'ai pas constaté spécifiquement de ralentissement sur les I/O, c'était plutôt une impression générale, mais ça ne te coûte rien d'essayer de la desactiver

----------

## CryoGen

Tu es en amd64 ? 

https://forums.gentoo.org/viewtopic-t-482731.html

J'ai le problème de ce topic ... problème qui date de loinnnnnnnnnnnnn et qui dure toujours et personne ne sait d'où ca vient :/

----------

## guilc

 *gglaboussole wrote:*   

> salut,
> 
> Je ne sais pas si cela à un rapport, mais j'ai constaté de grosses pertes de perfs avec le 2.6.24 (mais pas avant) qui était du à l'option Fair group CPU scheduler  introduite depuis cette version du kernel , j'avais d'ailleurs fait un post "d'avertissement" https://forums.gentoo.org/viewtopic-t-675590-postdays-0-postorder-asc-highlight-avertissement-start-0.html
> 
> J'ai pas constaté spécifiquement de ralentissement sur les I/O, c'était plutôt une impression générale, mais ça ne te coûte rien d'essayer de la desactiver

 

Ca, déjà désactivé

J'avais effectivement constaté des problèmes de latence pendant les grosses compils à cause de cela  :Wink: 

 *CryoGen wrote:*   

> Tu es en amd64 ?

 

Non, x86 de base, chipset intel tout ce qu'il y a de plus bête et plutôt très bien supporté par le kernel depuis la nuit des temps...

Bon, quand même un nouvel élément : je viens de tester avec un nouvel utilisateur non-root, et différent de mon user qui fait tourner X => en fait si, le même problème de latence apparait.

Et toujours, si les grosses I/O sont faites avec mon propre user, ça tourne nickel, la latence reste très bonne...

Ca semble bien une histoire de partage des taches i/o entre users.

Mes process se tapent bien du iowait pendant cette opération, dixit dstat et la load qui grimpe...

La ou je coince, c'est que le changement de scheduleur devrait changer la donne ! et bien RIEN...

----------

## kopp

Je vis dans le même genre de problème quand je compile avec des accès disque, la charge monte beaucoup et le système devient parfois vraiment très peu réactif. J'ai cherché à identifier le problème sans succès. (enfin, pas trop cherché non plus)

Par contre si je compile en tmpfs, plus de soucis. Donc a priori, mon problème vient aussi de l'io.

----------

## nonas

J'ai eu ce problème il y a quelques noyaux mais c'est rentré dans l'ordre pour ma part (sans que j'ai eu l'impression de changer quoique ce soit à mon noyau).

x86+ICH.

Ma config : http://nitrotoxine.free.fr/www/libre/Gentoo/config-2.6.25.4-vanille

----------

## kopp

Ah oui, je précise. Ici aussi x86 et ICH7

Je regarderai ta config, nonas. Mais j'avoue que je ne suis pas fan de la lecture des .config  :Smile: 

EDIT: après un coup d'oeil vite fait sur un diff, j'ai rien remarqué qui pourrait être une cause de différence ...

----------

## gglaboussole

Pour cerner d'ou viennent tes problèmes de latence et ce qui les cause, est ce que cela pourrait te servir ? :

http://lwn.net/Articles/266153/

----------

## guilc

 *kopp wrote:*   

> Ah oui, je précise. Ici aussi x86 et ICH7
> 
> Je regarderai ta config, nonas. Mais j'avoue que je ne suis pas fan de la lecture des .config 
> 
> EDIT: après un coup d'oeil vite fait sur un diff, j'ai rien remarqué qui pourrait être une cause de différence ...

 

Pareil, rien de significatif.

La seule différence majeure est le support du HT que je n'ai pas... pour le reste, c'est pareil...

Effectivement, vais ptet faire un tour du côté de latencytop, mais je crois pas trop au miracle là...

----------

## guilc

Bon, petite update sur le problème.

Dans le doute, vu que c'est un chipset intel IDE, je viens de faire un test en repassant sur l'ancien support IDE (j'étais en libata), et....... très forte réduction des problèmes de latence...

Première conclusion rapide donc : le problème est dans libata (ou au moins dans le support ICH PATA de libata)...

----------

## kopp

Après des grandes discussions metaphilosophiques avec geekounet, je contourne le problème par une méthode fourbe

Le /var/tmp/portage monté en tmpfs et roule ma poule ! Bon faut avoir suffisament de ram, mais pour la plupart des paquets, ça passe sans problème  :Smile:  et mon dieu, non seulement le pc rame carrément moins, mais en plus les compils sont ultra plus rapide (jusqu'à 40% de gagné sur des compiles de plus de 10 minutes...)

----------

## nonas

Beaucoup c'est combien ? 

Avec mon Go ça risque de faire juste (en même temps j'ai pas beaucoup de gros paquets). D'ailleurs y'a un moyen rapide de savoir de combien d'espace un paquet a besoin pour builder ?

----------

## kopp

Beuh, j'ai deux gigas de ram donc j'en mets 1 pour le tmpfs. Pour le moment j'ai pas eu de gros probleme. Par contre c'est pas suffisant pour gcc apparemment (pas essayé)

sinon tout est passé sans aucune soucis depuis, le plus gros étant certainement xulrunner (et le gain de temps est de l'ordre de 50%)

----------

## guilc

Ouais, sauf que ça, ça contourne le problème pour les compils portage. Pas pour le reste (manipulations de gros tar, copies de gros fichiers, etc...) qui déclenchent aussi le problème.

En tous cas, pour le moment, le retour au bon vieux driver IDE au lieu de libata corrige carrément bien le problème, on ne perd quasiment plus l'interactivité de X pendant ces opérations !

----------

## Enlight

Juste une petite question vu que moi aussi je serais parti sur un test ionice, tu as bien testé ionice lorsque tu utilisais le scheduler cfq? Il me semble qu'avec les autres ça ne sert à  rien (ou alors ça a changé).

----------

## guilc

 *Enlight wrote:*   

> Juste une petite question vu que moi aussi je serais parti sur un test ionice, tu as bien testé ionice lorsque tu utilisais le scheduler cfq? Il me semble qu'avec les autres ça ne sert à  rien (ou alors ça a changé).

 

En fait j'ai testé avec/sans ionice sur tous les schedulers, donc oui, cfq entre-autre. J'ignorais que cela avait un effect que sur CFQ (je n'étais pas allé jusqu'à la section "NOTES" de la page man, honte sur moi   :Laughing:  )

Maintenant, vais commencer à écumer la lkml à la recherche de problèmes de latence sur libata et/ou son support PATA ICH sur x86. Je sens que c'est pas gagné  :Smile: 

----------

## NEOxAKIRA

quelles sont les variables correspondant à libata et aux vieux drivers IDE dans .config ? SVP

----------

## ghoti

Dans "Device Drivers" :

Les vieux drivers correspondent à la partie "ATA/ATAPI/MFM/RLL support (IDE)"

Les nouveaux drivers correspondent à "Serial ATA (prod) and Parallel ATA (experimental) drivers (ATA)"

----------

