jeudi 18 avril 2013

Résoudre les problèmes de mémoire sur les cartes mv643xx_eth

Les cartes réseaux mv643xx_eth c'est ce qui équipe des équipements comme les GuruPlug, les DreamPlugs, probablement les SheevaPlugs et d'autres équipements du même genre.

Malheureusement, ces cartes ont un problème de pilote dans le noyau Debian Wheezy. Le problème se déclare lors d'utilisation de paquets encapsulés (IPSec, GRE, 6to4, et plein d'autres trucs) avec un peu de charge réseau (1,5Mb/s suffit chez moi à poser des soucis). On obtient dans ce cas là une belle trace kernel commençant environ par :

swapper: page allocation failure: order:8, mode:0x20

Hormis ça, le reste semble marcher. On a de la perte de paquets (logique, celui qui déclenche la trace est détruit). Une analyse plus fine montre quand même que le Kernel prend une mémoire folle (plus de 80Mo de RAM pour un simple flux IPSec), et que le débit n'est idéal alors que la bande passante n'est pas saturé et le processeur loin surchargé... J'avais déjà enquêté sur le problème en août, mais je n'avais pas trouvé de solution. Le Kernel semblait allouer des pages contiguës énormes pour un simple paquet (on peut monter jusqu'à un order:10 si on défragmente la mémoire avant), sans aucun lien avec les ressources normalement nécessaires. J'avais tout de même réussi à isoler ce commit, mais par manque de temps et de piste j'avais abandonné (et j'avais configuré mon tunnel IPSec pour utiliser un autre serveur). Les joies d'utiliser du matériel un peu exotique, pour des utilisations très exotiques.

J'ai trouvé aujourd'hui un peu par hasard la solution, ici. Et il y a même le patch qui va bien. J'ai testé ce patch en l'appliquant sur mv643xx_eth.c uniquement, dans l'objectif de recompiler que le module. Et ça a marché :) Plus d'erreurs mémoire, un débit logique, plus d'utilisation incompréhensible de la RAM, tout va pour le mieux.

Et grand merci à Cyril pour son soutien pendant mes recherches en août. Et pour avoir résolu un autre problème très emmerdant sur un autre ordinateur.

dimanche 7 juin 2009

Mais arrête de m'interrompre un peu !

Le noyau 2.6.30 n'est pas encore sorti en version finale mais c'est déjà trop la fête. J'ai testé le noyau 2.6.30-rc8 mis en paquet par un développeur Debian pour l'architecture ARM (oui faut le faire à la main car ARM n'est pas compilé par défaut sur le dépôt experimental des noyaux Debian...). Et le moins que l'on puisse dire c'est que les résultats sont impressionnants. Je me plaignais depuis longtemps du débit avec les disques durs, et je fais donc les tests à chaque installation d'un nouveau noyau (à tout autre logiciel égal, le serveur étant laissé en Debian Lenny depuis sa sortie).

Résultats avant le changement de noyau :

(en raid5) Timing buffered disk reads:   46 MB in  3.00 seconds =  15.31 MB/sec
(en raid10) Timing buffered disk reads:   36 MB in  3.08 seconds =  11.68 MB/sec

Résultats après le changement de noyau :

(en raid5) Timing buffered disk reads:  110 MB in  3.04 seconds =  36.14 MB/sec
(en raid10)  Timing buffered disk reads:   96 MB in  3.01 seconds =  31.86 MB/sec

Plus du double, ça fait beaucoup de différence. Comme hier soir c'était également « jour de vérification du raid » (premier samedi du mois quoi...) j'ai pu sentir la différence. Si par exemple au mois d'avril les logs indiquaient :

 
Apr  5 18:51:31 floolf kernel: md: md2: data-check done. 

Aujourd'hui j'ai eu le droit avant le réveil à ceci :

 
Jun  7 09:15:18 floolf kernel: md: md2: data-check done. 

Dans les deux cas même heure de départ vers 1h du matin :)

L'explication de cette énorme amélioration se trouve en surveillant les interruptions. Sur les noyaux précédents j'obtenais des graphiques avec munin de plus de 1500 interruptions par seconde lors de la reconstruction du raid. Désormais ça plafonne à 150, réduisant énormément la part du processeur utilisée pour les traiter. Dix fois moins d'interruptions pour un travail supérieur, je ne dis pas non. Reste à savoir ce qui coinçait exactement et pourquoi cette optimisation possible n'avait pas été repérée avant... En attendant je remercie mille fois la qualité de l'équipe Debian en ARM et les développeurs du noyau.

mardi 17 février 2009

Dépendances

Un peu par hasard je me suis demandé à quoi pouvait bien ressembler l'arbre de dépendance des paquets sur mes machines. Aptitude why et consort, c'est bien joli, mais visuellement, ça donne quoi ? KiBi m'a fait gagné énormément de temps en m'indiquant l'existence de debtree, qui fait presque ce que je voulais, mais paquet par paquet, et non pas l'ensemble du système.

Pour contourner le problème sans trop réfléchir, j'ai créé un paquet dépendant de tous les paquets installés manuellement, et ceci tout d'abord sur un serveur avec très peu de paquets installés (300 paquets au total, 80 installés « manuellement »). Je suis très content du résultat, même s'il faudrait un écran énorme pour le visualiser entièrement tout en restant lisible. Petit extrait du graphique :

floolf-extrait.jpg

Et comme c'est trop gros pour ressembler à quelque chose, la version réduite et en jpg (1,4Mo), l'originale en png (6,4 Mo).

debtree supprime naturellement les paquets comme libc6 dont beaucoup trop de paquets dépendent, ce qui a le bon goût d'éviter les points d'agglomérations évidents. Je n'ai pas encore testé toutes les options de debtree, mais il est probable qu'il soit possible de faire plus clair encore (l'option --condense par exemple...).

mardi 29 avril 2008

Debian et EM-7220

L'arrivée du noyau 2.6.25 dans les dépôts Debian est une bonne occasion pour revenir sur l'installation de cette distribution sur une machine assez étrange : une carte mère em7220. Cette carte mère est utilisée dans quelques produits de stockages vendus pour les petites entreprises, notamment le Acer Easy Store, le même chez son fabricant d'origine, Lanner NS-4410. On peut installer (c'est pas vraiment fait pour, mais bon) une debian dessus. Petit guide de comment j'ai fini par y arriver.

Lire la suite...