Un petit défaut des noyaux 2.6 (je pense peut être à tors)
est une augmentation significative des ressources.
je m'explique il y a fort peu, avec un noyau 2.5 ma consommation mémoire était de 200 Mo (un nectar)
maintenant avec les mêmes applications (gnome, openoffice, mozilla...)
elle sature à 500 Mo et consomme parfois de la SWAP
Ma remarque est simple,
soit tous mes applets ont decidé de prendre 20Mo de ram
(pour l'horloge de gnome si si)
(100Mo pour epiphany 5Mo pour bash)
soit le kernel alloue trop de mémoire ou alors "free" me ment ?
--@---:~$ free
total used free shared buffers cached
Mem: 516072 506048 10024 0 36256 330484
-/+ buffers/cache: 139308 376764
Swap: 265032 0 265032
LFS 6.0 (la version pre6.0 reproduit les même symptôme)
kernel 2.6 min 2.6.8.1 (bogus) max 2.6.11-rc3 (x11 crash)
Forum Linux.noyau Consommation mémoire trop importante
28
fév.
2005
# Rien d'anormal
Posté par Edouard Gomez (site web personnel) . Évalué à 6.
total used free shared buffers cached Mem: 516072 506048 10024 0 36256 330484 -/+ buffers/cache: 139308 376764 Swap 265032 0 265032La plus grosse partie de ta memoire est utilisée par le cache FS, ce qui en gros est bon pour toi, puisque ca evite des acces disque par la suite. Puis dans la messure ou tu as 512MB de RAM, pourquoi ne pas laisser le noyau les utiliser à sa guise ? En tout cas je vois rien d'alarmant dans ton free. Le seul truc qui peut etre derangeant c'est le comportement du 2.6 qui tend trop facilement à utiliser la swap même lorsqu'il pourrait vider un peu plus le cache FS. Con Kolivas poste des patchs qui visent à améliorer ce genre de choses sur son site, son patch modifie aussi completement le scheduler au passage, tu peux tester, les con kolivas sont les noyaux les plus stables que j'ai trouvé pour des workstations. http://members.optusnet.com.au/ckolivas/kernel/(...)[^] # Re: Rien d'anormal
Posté par eloi . Évalué à 1.
pour info,j'utilise le 2.6.11-rc5 depuis le post d'hier et:
free
total used free shared buffers cached
Mem: 516072 295188 220884 0 27700 120420
-/+ buffers/cache: 147068 369004
Swap: 265032 0 265032
c'est déja mieux même après 12h d'utilisation
je pense que l'explication est la suivante:
pour la première fois l'UDMA fonctionne "pleinement" avec ce noyau
avant max 15Mo/s maintenant 30-40Mo/s en moyenne
(SiS 5513)
pour les con kolivas je vais voir et voire même essayer...
[^] # Re: Rien d'anormal
Posté par eloi . Évalué à 1.
car j'ai de GROS ploblèmes de gravure (IDE) si <2.6.11-rc3
[^] # Re: Rien d'anormal
Posté par riba . Évalué à 2.
11-rc5-bk4 pour obtenir les super performances que tu affichais (avant: ...2.6.10-1.760, cad un 2.6.10+divers patchs redhat/kernel).
... et ben je reste à 16Mo/s, alors, dis-moi d'ou tu sort ce "30-40" stp?
J'ai peut-être merdé dans une config UDMA, ou faut que je tridure à coup de hdparm et cie...
[^] # 30-40 (si si) j'ai vérifié
Posté par eloi . Évalué à 1.
hdparm -t /dev/hdc (qui lui est en UDMA100)
(en haut niveau système eg init 5)
Mais pour présciser tu es sous une distrib et pas moi
donc l'ensemble de mon système est compiler pour un AMDXP
(sauf l'eternel flex qui ne supporte vraiment pas d'optimisation )
notabene, l'ide passe par le proc donc tout dépend de la charge du système et de sa capacité ...
néanmoins j'ai souvenir qu'avec une Mandrake (8.x)
mes deux seagate 20Go UDMA66 étaient "rapides"
sinon vérifie que tu utilise bien une nappe IDE adaptée (fils fins)
car c'est peut être stupide mais pendant 4 ans je me suis fait avoir
bref dis-je
pour répondre à ta requête,
hdparm -d1 -c1 -X66 -K1 /dev/...
(ça marche aussi avec les CD-DVD-RW )
pas de config particulière pour le kernel si ce n'est
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
et un extrait de hdparm -t /dev/hd[a-c]
/dev/hda:
Timing buffered disk reads: 86 MB in 3.05 seconds =28.22 MB/sec
/dev/hdb:
Timing buffered disk reads: 86 MB in 3.07 seconds =28.04 MB/sec
/dev/hdc:
Timing buffered disk reads: 118 MB in 3.04 seconds =38.82 MB/sec
les hd[a-b] sont en UDMA66
je n'ai pas testé encore le bk4 il se peut que le problème recommence pour moi donc bon courage !
[^] # Re: 30-40 (si si) j'ai vérifié
Posté par riba . Évalué à 2.
c'est ce que je fais pour mesurer
> Mais pour présciser tu es sous une distrib et pas moi
FC3 ici
> donc l'ensemble de mon système est compiler pour un AMDXP
moi pour un PIV
> notabene, l'ide passe par le proc donc tout dépend de la charge du système et de sa capacité ...
oui je vérifie que y'a rien qui tourne et que y'a de la RAM libre.
> sinon vérifie que tu utilise bien une nappe IDE adaptée (fils fins)
c'est sur un portable!
> car c'est peut être stupide mais pendant 4 ans je me suis fait avoir
pas de bol...
hdparm -v /dev/hda
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
donc dma activé
hdparm -t /dev/...
hdparm -d1 -c1 -K1 -t /dev/...
hdparm -d1 -c1 -X66 -K1 -t /dev/...
toujours 17Mo/s
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_SIS5513=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_IDEDMA_AUTO=y
tout bon!
bon finalement ça me suffit ces 17Mo en fait... tant pis
[^] # ah bah là
Posté par eloi . Évalué à 1.
comme tu le dis, je crois aussi que le problème vient du fait que tu utilises un portable:
(sans vouloir en vexer plus d'un)
les hd sont en général plus lents car embarqués (failble conso)
5400 ou 7200 tr/min ?
moi, tous sont en 7200tr/min
comme tu dis tant pis, mais au moins ça marche
au fait hdparm permet de réduire la conso des disque (cf man page)
l'option -M reduit non seulement le bruit mais aussi la conso
[^] # Re: ah bah là
Posté par riba . Évalué à 2.
à mon avis 5400, mais je le trouve pas:
[root@localhost ~]# hdparm -i /dev/hda
/dev/hda:
Model=FUJITSU MHR2030AT D, FwRev=70BC, SerialNo=NJ83T291560F
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=58605120
IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 1:
* signifies the current active mode
D'ailleurs udma5 doit être plus mieux bien que udma2, je vais voir ça
> comme tu dis tant pis, mais au moins ça marche
ouais...
[^] # UDMA5
Posté par eloi . Évalué à 1.
le mien dit:
/dev/hdc:
Model=ST340016A, FwRev=3.10, SerialNo=3HS1FLSB
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=78165360
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:
* signifies the current active mode
donc passe en udma5
option : -X udma5
pas de raison que ça ne marche pas
sinon ton portable c'est quoi (j'en cherche un pour partir en stage)
pas de soucis... (à part ça)
[^] # Re: UDMA5
Posté par riba . Évalué à 2.
> donc passe en udma5
> option : -X udma5
> pas de raison que ça ne marche pas
[root@localhost ~]# hdparm -d1 -c1 -K1 -X udma5 -t /dev/hda
/dev/hda:
setting 32-bit IO_support flag to 1
setting using_dma to 1 (on)
setting drive keep features to 1 (on)
setting xfermode to 69 (UltraDMA mode5)
IO_support = 1 (32-bit)
using_dma = 1 (on)
Timing buffered disk reads: 54 MB in 3.03 seconds = 17.84 MB/sec
ah ben non...
c'est peut-être le AdvancedPM=yes chez moi.
> sinon ton portable c'est quoi (j'en cherche un pour partir en stage)
oula!!! un vieux gericom per4mance je sais pas quoi (une obscure marque autrichienne à-pas-cher), je l'ai acheté en décembre 2002 (pour ma thèse, un peu comme toi), il a:
PIV 2GHz, 256 RAM, 30Go disk, lecteur disquette (et oui), architecture SiS, écran 15', combo lecteur DVD/graveur CD, et tout les trucs classiques (eth RJ45, winmodem RJ11 qui passe sous linux, USB1 (arg!), bidule infrarouge (jamais regardé), divers connecteurs derrières, XP Home (oui mais bon), ...). Je l'avais payé moins de 800¤ à l'époque, ce qui valais le coup (les écrans 15' étaient rares à l'époque). Mais j'ai eu des emmerdes:
- l'écran marche plus car le prelink journalier de FC1 a fait tout chauffer et a grillé l'alim HT de la dalle (j'en ai commandé une autre aux US mais ça a rien changé, il doit y avoir quelque chose d'autre qui a grillé). Je me sert d'un écran externe depuis (pas vraiment portable quoi...);
- la batterie marche quasiment plus (~20 min.) depuis que j'ai eu le malheur de la recharger sur une prise sans terre (ce qui paraît bizarre quand même).
Mais bon, je suis encore dessus et il m'a bien servi (même pour ma soutenance!).
Honnêtement, je me renseigne desfois pour en acheter un autre[1], et je te conseille un minimum de marque (Dell, Sony, ...) ou le must: un ibook: super qualité, solide, pieces standarts construites en grosse quantité, powerPC qui chauffe pas, ... (y'a un bon plan sur l'applestore le mercredi avec le materiel "réemmbalé" où tu peux avoir des grosses réducs: http://promo.euro.apple.com/promo/refurb/fr/(...) )
[1] Mais bon, je suis au chômage là, et pas indemnisé, donc c'est juste pour se tenir au courant.
[^] # vi
Posté par eloi . Évalué à 1.
merci pour ces prescisions,mais finalement pas de sous...
sinon j'ai lu une chose intérressante:
une option du kernel empecherait le passage en UDMA pour VIA82CXX
pourquoi pas avec une sis5513 ?
c'est l'option suivante: CONFIG_BLK_DEV_GENERIC
à voir...
[^] # Re: vi
Posté par riba . Évalué à 2.
c'était à yes, j'ai mis no, et ça change rien. Bon, je crois que j'abandonne là.
[^] # Re: vi
Posté par eloi . Évalué à 1.
# plop
Posté par gnumdk (site web personnel) . Évalué à 6.
C'est celle la la ligne interessante... ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.