J'ai pass=E9 mon serveur d'un ancien PC C=E9l=E9ron 500Mhz, 384Mo de RAM =
en
une machine neuve C=E9l=E9ron 2.66Ghz, 1Go de RAM, avec un disque SATA.
Sur mon ancien serveur, certes les sauvegardes compl=E8tes duraient
longtemps (en gros 5-7 heures), mais au moins, =E7a ne mettait pas le PC =
=E0
genoux, et je pouvais continuer =E0 bosser dessus normalement pour des
t=E2ches d'administration l=E9g=E8res.
Sur le nouveau, les sauvegardes vont =E9videmment beaucoup plus vite, mai=
s
pas contre, tout le reste est du coup tr=E8s ralenti. Un 'top' prend plus=
ieurs
secondes avant d'arriver, et parfois m=EAme beaucoup plus et, beaucoup
plus emb=EAtant, les acc=E8s ssh sont impossibles.
De plus, ce ne sont pas seulement les sauvegardes qui sont en cause mais
toute grosse utilisation du processeur puisqu'une compilation quelconque =
a
les m=EAmes effets.
J'ai pens=E9 'jouer' du 'nice', mais d=E9j=E0, =E7a semble sans effet, et=
je me
demande malgr=E9 tout si je n'aurais pas un petit d=E9faut ailleurs, en
particulier sur le noyau. En effet, c'est la premi=E8re fois que je compi=
le
avec CONFIG_PREEMPT=3Dy. Est-ce r=E9ellement un bon choix ? Et cela peut-=
il
avoir un rapport ?
Sinon, quelle piste pensez-vous que je pourrais explorer ?
Je pr=E9cise que =E7a ne vient =E0 priori pas de mes disques IDE et SATA =
qui,
lors de simples transferts de gros volumes ne cr=E9ent pas ces
perturbations.
Pour info, Gentoo stable, =E0 jour :
# uname -a
Linux serveur1 2.6.11.11 #1 Thu Jun 16 18:43:18 AST 2005 i686 Intel(R) Ce=
leron(R) CPU 2.66GHz GenuineIntel GNU/Linux
J'ai essay=E9 avec un noyau gentoo, pareil.
Une discussion a eu lieu sur le newsgroup usenet fcolc, mais sans grand
r=E9sultat. Si malgr=E9 tout quelqu'un veut en savoir plus, en voici les
r=E9f=E9rences :
Date: Thu, 07 Apr 2005 12:21:28 -0400
From: Christophe PEREZ <christophe.perez_faute@nova=
zur.com>
Message-ID: <pan.2005.04.07.16.21.25.907098@novazur.fr>
Newsgroups: fr.comp.os.linux.configuration
Subject: tache gourmande
J'avoue ne plus du tout savoir quoi tenter, d'o=F9 cet appel =E0 l'aide i=
ci.
Merci d'avance.
PS : Je vous lis depuis lgtps mais sans avoir jamais pu intervenir sur la
liste depuis gmane, je tente donc =E0 nouveau par un autre biais
--=20
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bertrand Jacquin
On 6/23/05, Christophe PEREZ wrote:
Bonjour,
Salut a toi :)
J'ai passé mon serveur d'un ancien PC Céléron 500Mhz, 384Mo de RAM en une machine neuve Céléron 2.66Ghz, 1Go de RAM, avec un disque SATA.
Sur mon ancien serveur, certes les sauvegardes complètes duraient longtemps (en gros 5-7 heures), mais au moins, ça ne mettait pas le PC à genoux, et je pouvais continuer à bosser dessus normalement pour des tâches d'administration légères.
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
Sur le nouveau, les sauvegardes vont évidemment beaucoup plus vite, mais pas contre, tout le reste est du coup très ralenti. Un 'top' prend plusieurs secondes avant d'arriver, et parfois même beaucoup plus et, beaucoup plus embêtant, les accès ssh sont impossibles. De plus, ce ne sont pas seulement les sauvegardes qui sont en cause mais toute grosse utilisation du processeur puisqu'une compilation quelconque a les mêmes effets.
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me demande malgré tout si je n'aurais pas un petit défaut ailleurs, en particulier sur le noyau. En effet, c'est la première fois que je compile avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il avoir un rapport ?
CONFIG_PREEMPT=y doit normalement justement te permettre de faire autre chose en meme temps, mais donne aussi plus de ressource a ta sauvegarde
Sinon, quelle piste pensez-vous que je pourrais explorer ?
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas acces à un linux ici)
Je précise que ça ne vient à priori pas de mes disques IDE et SATA qui, lors de simples transferts de gros volumes ne créent pas ces perturbations.
Pour info, Gentoo stable, à jour : # uname -a Linux serveur1 2.6.11.11 #1 Thu Jun 16 18:43:18 AST 2005 i686 Intel(R) Celeron(R) CPU 2.66GHz GenuineIntel GNU/Linux
J'ai essayé avec un noyau gentoo, pareil.
La meme chose en 2.6.12 ? Utilise tu des logiciels pour changer/visualiser les paramètres de tes disques (en particulier le sata) ? ([hs]dparm)
++ Beber
-- mailing list
On 6/23/05, Christophe PEREZ <christophe.perez@novazur.com> wrote:
Bonjour,
Salut a toi :)
J'ai passé mon serveur d'un ancien PC Céléron 500Mhz, 384Mo de RAM en
une machine neuve Céléron 2.66Ghz, 1Go de RAM, avec un disque SATA.
Sur mon ancien serveur, certes les sauvegardes complètes duraient
longtemps (en gros 5-7 heures), mais au moins, ça ne mettait pas le PC à
genoux, et je pouvais continuer à bosser dessus normalement pour des
tâches d'administration légères.
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
Sur le nouveau, les sauvegardes vont évidemment beaucoup plus vite, mais
pas contre, tout le reste est du coup très ralenti. Un 'top' prend plusieurs
secondes avant d'arriver, et parfois même beaucoup plus et, beaucoup
plus embêtant, les accès ssh sont impossibles.
De plus, ce ne sont pas seulement les sauvegardes qui sont en cause mais
toute grosse utilisation du processeur puisqu'une compilation quelconque a
les mêmes effets.
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me
demande malgré tout si je n'aurais pas un petit défaut ailleurs, en
particulier sur le noyau. En effet, c'est la première fois que je compile
avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il
avoir un rapport ?
CONFIG_PREEMPT=y doit normalement justement te permettre de faire
autre chose en meme temps, mais donne aussi plus de ressource a ta
sauvegarde
Sinon, quelle piste pensez-vous que je pourrais explorer ?
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas
acces à un linux ici)
Je précise que ça ne vient à priori pas de mes disques IDE et SATA qui,
lors de simples transferts de gros volumes ne créent pas ces
perturbations.
Pour info, Gentoo stable, à jour :
# uname -a
Linux serveur1 2.6.11.11 #1 Thu Jun 16 18:43:18 AST 2005 i686 Intel(R) Celeron(R) CPU 2.66GHz GenuineIntel GNU/Linux
J'ai essayé avec un noyau gentoo, pareil.
La meme chose en 2.6.12 ?
Utilise tu des logiciels pour changer/visualiser les paramètres de tes
disques (en particulier le sata) ? ([hs]dparm)
J'ai passé mon serveur d'un ancien PC Céléron 500Mhz, 384Mo de RAM en une machine neuve Céléron 2.66Ghz, 1Go de RAM, avec un disque SATA.
Sur mon ancien serveur, certes les sauvegardes complètes duraient longtemps (en gros 5-7 heures), mais au moins, ça ne mettait pas le PC à genoux, et je pouvais continuer à bosser dessus normalement pour des tâches d'administration légères.
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
Sur le nouveau, les sauvegardes vont évidemment beaucoup plus vite, mais pas contre, tout le reste est du coup très ralenti. Un 'top' prend plusieurs secondes avant d'arriver, et parfois même beaucoup plus et, beaucoup plus embêtant, les accès ssh sont impossibles. De plus, ce ne sont pas seulement les sauvegardes qui sont en cause mais toute grosse utilisation du processeur puisqu'une compilation quelconque a les mêmes effets.
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me demande malgré tout si je n'aurais pas un petit défaut ailleurs, en particulier sur le noyau. En effet, c'est la première fois que je compile avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il avoir un rapport ?
CONFIG_PREEMPT=y doit normalement justement te permettre de faire autre chose en meme temps, mais donne aussi plus de ressource a ta sauvegarde
Sinon, quelle piste pensez-vous que je pourrais explorer ?
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas acces à un linux ici)
Je précise que ça ne vient à priori pas de mes disques IDE et SATA qui, lors de simples transferts de gros volumes ne créent pas ces perturbations.
Pour info, Gentoo stable, à jour : # uname -a Linux serveur1 2.6.11.11 #1 Thu Jun 16 18:43:18 AST 2005 i686 Intel(R) Celeron(R) CPU 2.66GHz GenuineIntel GNU/Linux
J'ai essayé avec un noyau gentoo, pareil.
La meme chose en 2.6.12 ? Utilise tu des logiciels pour changer/visualiser les paramètres de tes disques (en particulier le sata) ? ([hs]dparm)
++ Beber
-- mailing list
Ivan Havlicek
Christophe PEREZ wrote:
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me demande malgré tout si je n'aurais pas un petit défaut ailleurs, en particulier sur le noyau. En effet, c'est la première fois que je compile avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il avoir un rapport ?
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le noyau recalcule les priorités), il faudrait le faire executer par un cron toutes les 2 secondes.
CONFIG_PREEMPT me semble une piste très plausible
Sinon, quelle piste pensez-vous que je pourrais explorer ?
A tout hasard : 1) Swap disque (manque de mémoire), vérifier avec la commande `free' 2) Accès DMA aux disques (commande `hdparm -dtT') 3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage. -- Ivan -- mailing list
Christophe PEREZ wrote:
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me
demande malgré tout si je n'aurais pas un petit défaut ailleurs, en
particulier sur le noyau. En effet, c'est la première fois que je compile
avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il
avoir un rapport ?
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le
noyau recalcule les priorités), il faudrait le faire executer par un
cron toutes les 2 secondes.
CONFIG_PREEMPT me semble une piste très plausible
Sinon, quelle piste pensez-vous que je pourrais explorer ?
A tout hasard :
1) Swap disque (manque de mémoire), vérifier avec la commande `free'
2) Accès DMA aux disques (commande `hdparm -dtT')
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage.
--
Ivan
--
gentoo-user-fr@gentoo.org mailing list
J'ai pensé 'jouer' du 'nice', mais déjà, ça semble sans effet, et je me demande malgré tout si je n'aurais pas un petit défaut ailleurs, en particulier sur le noyau. En effet, c'est la première fois que je compile avec CONFIG_PREEMPT=y. Est-ce réellement un bon choix ? Et cela peut-il avoir un rapport ?
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le noyau recalcule les priorités), il faudrait le faire executer par un cron toutes les 2 secondes.
CONFIG_PREEMPT me semble une piste très plausible
Sinon, quelle piste pensez-vous que je pourrais explorer ?
A tout hasard : 1) Swap disque (manque de mémoire), vérifier avec la commande `free' 2) Accès DMA aux disques (commande `hdparm -dtT') 3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage. -- Ivan -- mailing list
Christophe PEREZ
Le Thu, 23 Jun 2005 13:07:08 +0200, Bertrand Jacquin a écrit :
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
star en mode -bz Mais comme dit, cela ne vient pas de ça puisque même d'autres tâche s comme de la grosse compilation me fait le même problème. C'est juste que je m'en suis initialement rendu compte lors de ces sauvegardes.
CONFIG_PREEMPT=y doit normalement justement te permettre de faire autre chose en meme temps,
C'est bien ce que j'avais cru comprendre.
mais donne aussi plus de ressource a ta sauvegarde
Mais même en le désactivant du noyau, c'est pareil.
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas acces à un linux ici)
/etc/security/limits.conf n'est rempli que de commentaires. De plus, je doute que ce soit un pb de config puisque sur mon propre poste, d'une config hard moins puissante, et d'une config soft (noyau etc...) similaire, je n'ai pas ce genre de problème.
La meme chose en 2.6.12 ?
Non, pas encore, mais j'ai essayé des dizaines de noyaux. Et on me disa it pareil pour le 2.6.11 quand il sortait juste. Mais faut dire que si j'ai une option mal placée dans ma config de noya u, c'est tout les noyaux que je teste qui l'ont.
Utilise tu des logiciels pour changer/visualiser les paramètres de te s disques (en particulier le sata) ? ([hs]dparm)
Pour le non sata, oui, hdparm semble me donner de bons résultats : # hdparm -t /dev/hdc
/dev/hdc: Timing buffered disk reads: 180 MB in 3.06 seconds = 58.74 MB/sec # hdparm -t /dev/hdd
/dev/hdd: Timing buffered disk reads: 100 MB in 3.02 seconds = 33.14 MB/sec
Pour le sata, j'avais cru comprendre qu'il n'y avait pas d'outils, du coup, non, je n'en utilise aucun évidemment. Je ne connais pas ce sdpar m, et je n'ai pas essayé puisqu'il semble que ce soit pour du scsi. Malgré tout, je viens de l'installer, et sans lire aucune doc, voici ce qu'il me répond : # sdparm /dev/sda /dev/sda: ATA ST3160827AS 3.42 Read write error recovery mode page: AWRE 1 [ sav: 1] ARRE 1 [ sav: 1] PER 0 [ sav: 0] Caching (SBC) mode page: WCE 1 [ sav: 1] RCD 0 [ sav: 0] Control mode page: SWP 0 [ sav: 0]
Ceci dit, comme déjà précisé dans le post initial, je n'ai pas ce genre de problème en faisant par exemple un cp de plusieurs Go d'un disque à l'autre. J'ai donc à priori exclu le problème d'accès di sque.
-- Christophe PEREZ -- mailing list
Le Thu, 23 Jun 2005 13:07:08 +0200, Bertrand Jacquin a écrit :
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
star en mode -bz
Mais comme dit, cela ne vient pas de ça puisque même d'autres tâche s
comme de la grosse compilation me fait le même problème. C'est juste que
je m'en suis initialement rendu compte lors de ces sauvegardes.
CONFIG_PREEMPT=y doit normalement justement te permettre de faire
autre chose en meme temps,
C'est bien ce que j'avais cru comprendre.
mais donne aussi plus de ressource a ta sauvegarde
Mais même en le désactivant du noyau, c'est pareil.
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas
acces à un linux ici)
/etc/security/limits.conf n'est rempli que de commentaires.
De plus, je doute que ce soit un pb de config puisque sur mon propre
poste, d'une config hard moins puissante, et d'une config soft (noyau
etc...) similaire, je n'ai pas ce genre de problème.
La meme chose en 2.6.12 ?
Non, pas encore, mais j'ai essayé des dizaines de noyaux. Et on me disa it
pareil pour le 2.6.11 quand il sortait juste.
Mais faut dire que si j'ai une option mal placée dans ma config de noya u,
c'est tout les noyaux que je teste qui l'ont.
Utilise tu des logiciels pour changer/visualiser les paramètres de te s
disques (en particulier le sata) ? ([hs]dparm)
Pour le non sata, oui, hdparm semble me donner de bons résultats :
# hdparm -t /dev/hdc
/dev/hdc:
Timing buffered disk reads: 180 MB in 3.06 seconds = 58.74 MB/sec
# hdparm -t /dev/hdd
/dev/hdd:
Timing buffered disk reads: 100 MB in 3.02 seconds = 33.14 MB/sec
Pour le sata, j'avais cru comprendre qu'il n'y avait pas d'outils, du
coup, non, je n'en utilise aucun évidemment. Je ne connais pas ce sdpar m,
et je n'ai pas essayé puisqu'il semble que ce soit pour du scsi.
Malgré tout, je viens de l'installer, et sans lire aucune doc, voici ce
qu'il me répond :
# sdparm /dev/sda
/dev/sda: ATA ST3160827AS 3.42
Read write error recovery mode page:
AWRE 1 [ sav: 1]
ARRE 1 [ sav: 1]
PER 0 [ sav: 0]
Caching (SBC) mode page:
WCE 1 [ sav: 1]
RCD 0 [ sav: 0]
Control mode page:
SWP 0 [ sav: 0]
Ceci dit, comme déjà précisé dans le post initial, je n'ai pas ce
genre de problème en faisant par exemple un cp de plusieurs Go d'un
disque à l'autre. J'ai donc à priori exclu le problème d'accès di sque.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Thu, 23 Jun 2005 13:07:08 +0200, Bertrand Jacquin a écrit :
Qu'est ce que tu utilise comme soft/commande pour faire tes sauvegarde ?
star en mode -bz Mais comme dit, cela ne vient pas de ça puisque même d'autres tâche s comme de la grosse compilation me fait le même problème. C'est juste que je m'en suis initialement rendu compte lors de ces sauvegardes.
CONFIG_PREEMPT=y doit normalement justement te permettre de faire autre chose en meme temps,
C'est bien ce que j'avais cru comprendre.
mais donne aussi plus de ressource a ta sauvegarde
Mais même en le désactivant du noyau, c'est pareil.
regarde du coté de /etc/limits.conf (je crois que c'est ca, j'ai pas acces à un linux ici)
/etc/security/limits.conf n'est rempli que de commentaires. De plus, je doute que ce soit un pb de config puisque sur mon propre poste, d'une config hard moins puissante, et d'une config soft (noyau etc...) similaire, je n'ai pas ce genre de problème.
La meme chose en 2.6.12 ?
Non, pas encore, mais j'ai essayé des dizaines de noyaux. Et on me disa it pareil pour le 2.6.11 quand il sortait juste. Mais faut dire que si j'ai une option mal placée dans ma config de noya u, c'est tout les noyaux que je teste qui l'ont.
Utilise tu des logiciels pour changer/visualiser les paramètres de te s disques (en particulier le sata) ? ([hs]dparm)
Pour le non sata, oui, hdparm semble me donner de bons résultats : # hdparm -t /dev/hdc
/dev/hdc: Timing buffered disk reads: 180 MB in 3.06 seconds = 58.74 MB/sec # hdparm -t /dev/hdd
/dev/hdd: Timing buffered disk reads: 100 MB in 3.02 seconds = 33.14 MB/sec
Pour le sata, j'avais cru comprendre qu'il n'y avait pas d'outils, du coup, non, je n'en utilise aucun évidemment. Je ne connais pas ce sdpar m, et je n'ai pas essayé puisqu'il semble que ce soit pour du scsi. Malgré tout, je viens de l'installer, et sans lire aucune doc, voici ce qu'il me répond : # sdparm /dev/sda /dev/sda: ATA ST3160827AS 3.42 Read write error recovery mode page: AWRE 1 [ sav: 1] ARRE 1 [ sav: 1] PER 0 [ sav: 0] Caching (SBC) mode page: WCE 1 [ sav: 1] RCD 0 [ sav: 0] Control mode page: SWP 0 [ sav: 0]
Ceci dit, comme déjà précisé dans le post initial, je n'ai pas ce genre de problème en faisant par exemple un cp de plusieurs Go d'un disque à l'autre. J'ai donc à priori exclu le problème d'accès di sque.
-- Christophe PEREZ -- mailing list
Christophe PEREZ
Le Thu, 23 Jun 2005 13:50:25 +0200, Ivan Havlicek a écrit :
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le noyau recalcule les priorités), il faudrait le faire executer par un cron toutes les 2 secondes.
Effectivement, c'est sans effet.
CONFIG_PREEMPT me semble une piste très plausible
pourtant, même en le virant du noyau lors de divers tests, j'ai eu le même problème.
A tout hasard : 1) Swap disque (manque de mémoire), vérifier avec la commande `fre e'
à priori non, régulièrement : # free -m total used free shared buffers cached Mem: 883 754 129 0 52 333 -/+ buffers/cache: 368 515 Swap: 980 2 977
Le swap n'est quasiment jamais touché.
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vid e...
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse proc esseur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aid e ici.
Bon courage.
-- Christophe PEREZ -- mailing list
Le Thu, 23 Jun 2005 13:50:25 +0200, Ivan Havlicek a écrit :
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le
noyau recalcule les priorités), il faudrait le faire executer par un
cron toutes les 2 secondes.
Effectivement, c'est sans effet.
CONFIG_PREEMPT me semble une piste très plausible
pourtant, même en le virant du noyau lors de divers tests, j'ai eu le
même problème.
A tout hasard :
1) Swap disque (manque de mémoire), vérifier avec la commande `fre e'
à priori non, régulièrement :
# free -m
total used free shared buffers cached
Mem: 883 754 129 0 52 333
-/+ buffers/cache: 368 515
Swap: 980 2 977
Le swap n'est quasiment jamais touché.
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vid e...
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse proc esseur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aid e ici.
Bon courage.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Thu, 23 Jun 2005 13:50:25 +0200, Ivan Havlicek a écrit :
Un "nice" n'est pas du tout efficace pour une tâche de longue durée (le noyau recalcule les priorités), il faudrait le faire executer par un cron toutes les 2 secondes.
Effectivement, c'est sans effet.
CONFIG_PREEMPT me semble une piste très plausible
pourtant, même en le virant du noyau lors de divers tests, j'ai eu le même problème.
A tout hasard : 1) Swap disque (manque de mémoire), vérifier avec la commande `fre e'
à priori non, régulièrement : # free -m total used free shared buffers cached Mem: 883 754 129 0 52 333 -/+ buffers/cache: 368 515 Swap: 980 2 977
Le swap n'est quasiment jamais touché.
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vid e...
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse proc esseur)
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aid e ici.
Bon courage.
-- Christophe PEREZ -- mailing list
Christophe PEREZ
Le Thu, 23 Jun 2005 13:52:10 -0400, Christophe PEREZ a écrit :
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit v ide...
/dev/hdd: using_dma = 1 (on) Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs : # hdparm -dtT /dev/sda
/dev/sda: Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse pro cesseur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'ai de ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette liste, vu le nombre de questions (et parfois même des réponses) que j'avais en suspend et dont je ne trouve de solution nulle part.
-- Christophe PEREZ -- mailing list
Le Thu, 23 Jun 2005 13:52:10 -0400, Christophe PEREZ a écrit :
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit v ide...
/dev/hdd:
using_dma = 1 (on)
Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs :
# hdparm -dtT /dev/sda
/dev/sda:
Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device
Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse pro cesseur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de
service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'ai de ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette
liste, vu le nombre de questions (et parfois même des réponses) que
j'avais en suspend et dont je ne trouve de solution nulle part.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
/dev/hdd: using_dma = 1 (on) Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs : # hdparm -dtT /dev/sda
/dev/sda: Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioct l for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse pro cesseur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'ai de ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette liste, vu le nombre de questions (et parfois même des réponses) que j'avais en suspend et dont je ne trouve de solution nulle part.
-- Christophe PEREZ -- mailing list
Yoann Pannier
Christophe PEREZ wrote, On 06/23/2005 07:52 PM:
# free -m total used free shared buffers cached Mem: 883 754 129 0 52 333
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'est intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour voir 120-130MB de plus sur ton 1GB de RAM.
-- Yoann Pannier
-- mailing list
Christophe PEREZ wrote, On 06/23/2005 07:52 PM:
# free -m
total used free shared buffers cached
Mem: 883 754 129 0 52 333
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'est
intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour voir
120-130MB de plus sur ton 1GB de RAM.
# free -m total used free shared buffers cached Mem: 883 754 129 0 52 333
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'est intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour voir 120-130MB de plus sur ton 1GB de RAM.
-- Yoann Pannier
-- mailing list
Christophe PEREZ
Le Fri, 24 Jun 2005 01:18:40 +0200, Yoann Pannier a écrit :
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'e st intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour vo ir 120-130MB de plus sur ton 1GB de RAM.
Ah oui, effectivement. Je m'étais déjà demandé pourquoi je ne voy ais pas toute la RAM, mais sans me poser plus de question.
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée, mon problème pouvait venir de là puisqu'il y aurait une incompatibili té avec certaines carte mère ASUS.
Ceci dit, merci, je vais activer ça pour le prochain reboot (=coupure de courant ;-) )
-- Christophe PEREZ -- mailing list
Le Fri, 24 Jun 2005 01:18:40 +0200, Yoann Pannier a écrit :
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'e st
intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour vo ir
120-130MB de plus sur ton 1GB de RAM.
Ah oui, effectivement. Je m'étais déjà demandé pourquoi je ne voy ais
pas toute la RAM, mais sans me poser plus de question.
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée,
mon problème pouvait venir de là puisqu'il y aurait une incompatibili té
avec certaines carte mère ASUS.
Ceci dit, merci, je vais activer ça pour le prochain reboot (=coupure de
courant ;-) )
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Fri, 24 Jun 2005 01:18:40 +0200, Yoann Pannier a écrit :
Ca n'a rien à voir avec la choucroute, mais en passant et sauf si c'e st intentionnel, il te manque CONFIG_HIGHMEM4G=y dans ton kernel pour vo ir 120-130MB de plus sur ton 1GB de RAM.
Ah oui, effectivement. Je m'étais déjà demandé pourquoi je ne voy ais pas toute la RAM, mais sans me poser plus de question.
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée, mon problème pouvait venir de là puisqu'il y aurait une incompatibili té avec certaines carte mère ASUS.
Ceci dit, merci, je vais activer ça pour le prochain reboot (=coupure de courant ;-) )
-- Christophe PEREZ -- mailing list
Christophe PEREZ
Le Thu, 23 Jun 2005 20:08:59 -0400, Christophe PEREZ a écrit :
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée , mon problème pouvait venir de là puisqu'il y aurait une incompatibi lité avec certaines carte mère ASUS.
Ouh !! Replacez les 's' là où il faut et remplacer éventuellement par un ' t'... Désolé.
-- Christophe PEREZ -- mailing list
Le Thu, 23 Jun 2005 20:08:59 -0400, Christophe PEREZ a écrit :
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée ,
mon problème pouvait venir de là puisqu'il y aurait une incompatibi lité
avec certaines carte mère ASUS.
Ouh !!
Replacez les 's' là où il faut et remplacer éventuellement par un ' t'...
Désolé.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Thu, 23 Jun 2005 20:08:59 -0400, Christophe PEREZ a écrit :
Je croyais que cette option ne comptais justement qu'au dessus de 1Go.
De plus, ailleurs, on m'avais dit que si j'avais cette option activée , mon problème pouvait venir de là puisqu'il y aurait une incompatibi lité avec certaines carte mère ASUS.
Ouh !! Replacez les 's' là où il faut et remplacer éventuellement par un ' t'... Désolé.
-- Christophe PEREZ -- mailing list
Michel Paquet
Moi je regarderais personnelement le choix de mon processeur. Passé d'un Celeron de classe Pentium 3 vers un Celeron de classe Pentium 4, c'est emputé son ordinateur de 2 bras et 2 jambes à mon avis. Surtout que les Celeron sont réputé d'abors et avant tout pour être des processeur de très base gamme et plus que castré. Ton choix aurrais été beaucoup plus judicieux pour un réel Pentium 4 à vitesse moindre ou encore passé chez AMD qui eux fabrique de vrai processeur fiable et performant, même dans leurs bas de gamme
Intel avec sa gamme de Pentium 4 se sont mis dans un sacré pétrin car l'architecture est complement différente et moin performante, ce qui a provoqué une hausse des Mhz, donc une hausse de chaleur. Intel eux-même on décidé que le prochain Pentium 5 reviendra sur l'architecture du bon vieux Pentium 3 (qui est beaucoup mieux dessiné, beaucoup plus performant a vitesse équivalente) et avec quelques ajout comme les instruction SSE3 et le IE64...
Je n'apporte pas de réel solution à ton problème j'en convien... mais je tenais néenmoin à donné mon avis.
Michel Paquet
Christophe PEREZ a écrit :
Le Thu, 23 Jun 2005 13:52:10 -0400, Christophe PEREZ a écrit :
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vide...
/dev/hdd: using_dma = 1 (on) Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs : # hdparm -dtT /dev/sda
/dev/sda: Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette liste, vu le nombre de questions (et parfois même des réponses) que j'avais en suspend et dont je ne trouve de solution nulle part.
-- mailing list
Moi je regarderais personnelement le choix de mon processeur. Passé
d'un Celeron de classe Pentium 3 vers un Celeron de classe Pentium 4,
c'est emputé son ordinateur de 2 bras et 2 jambes à mon avis. Surtout
que les Celeron sont réputé d'abors et avant tout pour être des
processeur de très base gamme et plus que castré. Ton choix aurrais été
beaucoup plus judicieux pour un réel Pentium 4 à vitesse moindre ou
encore passé chez AMD qui eux fabrique de vrai processeur fiable et
performant, même dans leurs bas de gamme
Intel avec sa gamme de Pentium 4 se sont mis dans un sacré pétrin car
l'architecture est complement différente et moin performante, ce qui a
provoqué une hausse des Mhz, donc une hausse de chaleur. Intel eux-même
on décidé que le prochain Pentium 5 reviendra sur l'architecture du bon
vieux Pentium 3 (qui est beaucoup mieux dessiné, beaucoup plus
performant a vitesse équivalente) et avec quelques ajout comme les
instruction SSE3 et le IE64...
Je n'apporte pas de réel solution à ton problème j'en convien... mais
je tenais néenmoin à donné mon avis.
Michel Paquet
Christophe PEREZ a écrit :
Le Thu, 23 Jun 2005 13:52:10 -0400, Christophe PEREZ a écrit :
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vide...
/dev/hdd:
using_dma = 1 (on)
Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs :
# hdparm -dtT /dev/sda
/dev/sda:
Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de
service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette
liste, vu le nombre de questions (et parfois même des réponses) que
j'avais en suspend et dont je ne trouve de solution nulle part.
Moi je regarderais personnelement le choix de mon processeur. Passé d'un Celeron de classe Pentium 3 vers un Celeron de classe Pentium 4, c'est emputé son ordinateur de 2 bras et 2 jambes à mon avis. Surtout que les Celeron sont réputé d'abors et avant tout pour être des processeur de très base gamme et plus que castré. Ton choix aurrais été beaucoup plus judicieux pour un réel Pentium 4 à vitesse moindre ou encore passé chez AMD qui eux fabrique de vrai processeur fiable et performant, même dans leurs bas de gamme
Intel avec sa gamme de Pentium 4 se sont mis dans un sacré pétrin car l'architecture est complement différente et moin performante, ce qui a provoqué une hausse des Mhz, donc une hausse de chaleur. Intel eux-même on décidé que le prochain Pentium 5 reviendra sur l'architecture du bon vieux Pentium 3 (qui est beaucoup mieux dessiné, beaucoup plus performant a vitesse équivalente) et avec quelques ajout comme les instruction SSE3 et le IE64...
Je n'apporte pas de réel solution à ton problème j'en convien... mais je tenais néenmoin à donné mon avis.
Michel Paquet
Christophe PEREZ a écrit :
Le Thu, 23 Jun 2005 13:52:10 -0400, Christophe PEREZ a écrit :
2) Accès DMA aux disques (commande `hdparm -dtT')
comme répondu à Bertrand, ça ne me semble pas venir de là :
Zut, coupure courant, obligé de couper avant que l'onduleur ne soit vide...
/dev/hdd: using_dma = 1 (on) Timing cached reads: 1768 MB in 2.00 seconds = 884.13 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.73 MB/sec
mais bien entendu, pour le sata, quelques erreurs : # hdparm -dtT /dev/sda
/dev/sda: Timing cached reads: 1808 MB in 2.00 seconds = 903.69 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 170 MB in 3.03 seconds = 56.04 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
3) L'ACPI peut créer des perturbations aussi (ajustement vitesse processeur)
Ah, mais je n'ai rien d'activé au niveau de l'acpi, je veux parler de service, daemon etc... Faut-il quand même le désactiver dans le noyau ?
J'avoue ne plus du tout savoir quoi tenter, d'où cet appel à l'aide ici.
Bon courage.
Merci. En tout cas, heureux de pouvoir enfin poster à nouveau sur cette liste, vu le nombre de questions (et parfois même des réponses) que j'avais en suspend et dont je ne trouve de solution nulle part.
