We run several RH7.2/7.3 servers & recently 2 of them, although still working fine, have started to show kjournald as generally using over 50% cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% now! Both machines are also using software RAID5 EIDE ....... otherwise are standard server installs. Any info on what kjournald is & why it should have recently become so active would be gratefully received. Regards, Nico Morrison Micronicos Limited, London, UK.
Nico Morrison wrote:> > We run several RH7.2/7.3 servers & recently 2 of them, although still > working fine, have started to show kjournald as generally using over 50% > cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% > now! > > Both machines are also using software RAID5 EIDE ....... otherwise are > standard server installs. > > Any info on what kjournald is & why it should have recently become so active > would be gratefully received. >This is usually because the IDE system is running in PIO mode. Check your log messages, test the throughput with `hdparm -t' and if the disks aren't using DMA, have a (cautious) play with `hdparm -d1'.
Thank you Andrew, Is this the same as the checkdma utility that allows turning on & off of DMA on Windows? And as these servers are working linux customer servers - can we change the DMA setting & know we can change it back without problems? Thanks again. Regards, Nico Morrison From: Andrew Morton [mailto:akpm@digeo.com] Sent: 08 December 2002 03:02 To: Nico Morrison Cc: 'ext3-users@redhat.com' Subject: Re: kjournald using up majority cpu%. Nico Morrison wrote:> > We run several RH7.2/7.3 servers & recently 2 of them, although still > working fine, have started to show kjournald as generally using over 50% > cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% > now! > > Both machines are also using software RAID5 EIDE ....... otherwise are > standard server installs. > > Any info on what kjournald is & why it should have recently become soactive> would be gratefully received. >This is usually because the IDE system is running in PIO mode. Check your log messages, test the throughput with `hdparm -t' and if the disks aren't using DMA, have a (cautious) play with `hdparm -d1'.
Administrator wrote:> > Thank you Andrew, > > Is this the same as the checkdma utility that allows turning on & off of DMA > on Windows?What's that? ;)> And as these servers are working linux customer servers - can we change the > DMA setting & know we can change it back without problems?You'll need to read the hdparm manpage, and then familiarise yourself with its usage on a test machine. The testing should happen during a planned outage - making mistakes with hdparm can easily take a machine down. But the first thing which you should do (which is perfectly safe) is to just query the settings without attempting to change anything. mnm:/home/akpm# hdparm -i /dev/hda /dev/hda: Model=Maxtor 5T040H4, FwRev=TAH71DP0, SerialNo=T4J0N9BC Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=80043264 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 AdvancedPM=yes: disabled (255) Drive Supports : ATA/ATAPI-6 T13 1410D revision 0 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6 See that asterisk next to "udma2"? It means this disk is running in UltraDMA mode 2, at 33 megabytes/second. All is well.
Hello Andrew,
I get:
[root@ns5 nico]# /sbin/hdparm -i /dev/hda
/dev/hda:
Model=MAXTOR 6L040J2, FwRev=A93.0500, SerialNo=662240310103
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=78177792
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
AdvancedPM=no
Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-1 ATA-2 ATA-3 ATA-4
ATA-5
??
Thanks again.
Regards,
Nico Morrison
nico.morrison@micronicos.com
___________________________________________
Micronicos Limited - London, UK.
Tel: +44 20 8870 8849 Fax: +44 20 8870 5290
___________________________________________
From: Andrew Morton [mailto:akpm@digeo.com]
Sent: 08 December 2002 10:46
To: Administrator
Cc: 'ext3-users@redhat.com'
Subject: Re: kjournald using up majority cpu%.
Administrator wrote:>
> Thank you Andrew,
>
> Is this the same as the checkdma utility that allows turning on & off
of
DMA> on Windows?
What's that? ;)
> And as these servers are working linux customer servers - can we change
the> DMA setting & know we can change it back without problems?
You'll need to read the hdparm manpage, and then familiarise yourself
with its usage on a test machine.
The testing should happen during a planned outage - making mistakes
with hdparm can easily take a machine down.
But the first thing which you should do (which is perfectly safe) is to
just query the settings without attempting to change anything.
mnm:/home/akpm# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 5T040H4, FwRev=TAH71DP0, SerialNo=T4J0N9BC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=80043264
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255)
Drive Supports : ATA/ATAPI-6 T13 1410D revision 0 : ATA-1 ATA-2 ATA-3 ATA-4
ATA-5 ATA-6
See that asterisk next to "udma2"? It means this disk is running
in UltraDMA mode 2, at 33 megabytes/second. All is well.
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users
Hi, On Sat, 2002-12-07 at 16:45, Nico Morrison wrote:> We run several RH7.2/7.3 servers & recently 2 of them, although still > working fine, have started to show kjournald as generally using over 50% > cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% > now! > > Both machines are also using software RAID5 EIDE ....... otherwise are > standard server installs.Sounds like you may be spending more time in the raid5 or IDE driver layers than in kjournald's own code --- all of the IO's CPU overhead can show up in the context of the process which submitted the IO, and that is kjournald in the case of ext3. Could you try running a profile of this? You need to reboot, unfortunately, to pass in the "profile=2" kernel option; then "readprofile" will extract the profiling information from the kernel. Cheers, Stephen
Hello, Sounds right - and for some reason it is taking a lot less CPU the last 24 hours - will see f it gets busy again. Many thanks. Regards, Nico Morrison nico.morrison@micronicos.com ___________________________________________ Micronicos Limited - London, UK. Tel: +44 20 8870 8849 Fax: +44 20 8870 5290 ___________________________________________ From: Stephen C. Tweedie [mailto:sct@redhat.com] Sent: 09 December 2002 12:52 To: Nico Morrison Cc: 'ext3-users@redhat.com' Subject: Re: kjournald using up majority cpu%. Hi, On Sat, 2002-12-07 at 16:45, Nico Morrison wrote:> We run several RH7.2/7.3 servers & recently 2 of them, although still > working fine, have started to show kjournald as generally using over 50% > cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% > now! > > Both machines are also using software RAID5 EIDE ....... otherwise are > standard server installs.Sounds like you may be spending more time in the raid5 or IDE driver layers than in kjournald's own code --- all of the IO's CPU overhead can show up in the context of the process which submitted the IO, and that is kjournald in the case of ext3. Could you try running a profile of this? You need to reboot, unfortunately, to pass in the "profile=2" kernel option; then "readprofile" will extract the profiling information from the kernel. Cheers, Stephen