Josef.Fuchs@leykam.com
2005-May-24 10:07 UTC
AW: [Samba] Performance problem when writing large files!
> -----Urspr?ngliche Nachricht----- > Von: Fabio Muzzi [mailto:liste@kurgan.org] > Gesendet: Dienstag, 24. Mai 2005 11:33 > Cc: samba@lists.samba.org > Betreff: Re: [Samba] Performance problem when writing large files! > > > Hello Josef, > > Tuesday, May 24, 2005, 8:39:27 AM, you wrote: > > JFlc> We encounter following problem. If somebody on the > network writes > JFlc> big files from windows clients to a samba shared > directory, the > JFlc> performance of the server will be as much degraded, > that, using top, > JFlc> on all CPUs 'idle 0.0%' will be shown and the > complete system > JFlc> freezes, up to minutes after stopping the copying > process. After a > JFlc> while the system returns to its normal state, where > mostly ideltimes > JFlc> from 50.0% up to 99.9% are shown. This behavior can > be reproduced > JFlc> and will always happen. > > Maybe it's a HDD controller / driver issue. You should try > and set up a > minimal FTP server on the Samba server, and try to upload > a big file by > FTP. If it hangs, it's not samba. If it works, then maybe > it's samba. In > top, what's the process that uses up the most CPU time, > when the system > hangs? > >First thanks for your fast replay, I'll going to check with FTP tomorrow in the early morning because there are less peoples online. You'll hear from me tomorrow. regards Josef
<quote who="Josef.Fuchs@leykam.com">> First thanks for your fast replay, I'll going to check with FTP tomorrow > in the early morning because there are less peoples online. > > You'll hear from me tomorrow.Are you using a newer distro? The format of top has changed. Are you noticing high HI and/or LO values? On older versions of top, I believe both HI and LO are rolled into the iowait state. If those values are high (above 30% if you ask me), then you could have a problem with your IRQs. The usual cause is UDMA not being enabled but I think it could also be caused by the BIOS assigning multiple devices to the same IRQ (in the case of add-on cards such as SCSI or RAID).
Josef.Fuchs@leykam.com
2005-May-25 04:36 UTC
AW: [Samba] Performance problem when writing large files!
> -----Urspr?ngliche Nachricht----- > Von: AragonX [mailto:aragonx@dcsnow.com] > Gesendet: Dienstag, 24. Mai 2005 15:42 > An: samba@lists.samba.org > Betreff: Re: AW: [Samba] Performance problem when writing large files! > > > <quote who="Josef.Fuchs@leykam.com"> > > First thanks for your fast replay, I'll going to check with > FTP tomorrow > > in the early morning because there are less peoples online. > > > > You'll hear from me tomorrow. > > Are you using a newer distro? The format of top has changed. Are you > noticing high HI and/or LO values? On older versions of top, > I believe > both HI and LO are rolled into the iowait state. > > If those values are high (above 30% if you ask me), then you > could have a > problem with your IRQs. The usual cause is UDMA not being > enabled but I > think it could also be caused by the BIOS assigning multiple > devices to > the same IRQ (in the case of add-on cards such as SCSI or RAID). > > --So, now I have checked to transfer a big amount of data using FTP. My server shows the same behaviour. So I think I'll have a general problem which is not related to Samba. I've checked my 'top' version and also the allocation of the interrupts but I don't see something suspect there. [root@hiflex proc]# top --version top (procps version 2.0.7) This is what top saying with FTP and also when I use Samba. The job thats consuming the most CPU time is the FTP or the SMBD. CPU0 states: 0.1% user, 99.9% system, 0.0% nice, 0.0% idle CPU1 states: 0.1% user, 99.9% system, 0.0% nice, 0.0% idle CPU2 states: 0.4% user, 99.6% system, 0.0% nice, 0.0% idle CPU3 states: 9.3% user, 90.7% system, 0.0% nice, 0.0% idle Mem: 11869796K av, 11615152K used, 254644K free, 0K shrd, 18748K buff Swap: 2048276K av, 0K used, 2048276K free 9701696K cached Thats the printout of the allocated Interrupts. [root@hiflex proc]# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 245 7836882 0 0 IO-APIC-edge timer 1: 0 187 0 0 IO-APIC-edge keyboard 2: 0 0 0 0 XT-PIC cascade 4: 0 98044 0 0 IO-APIC-edge serial 8: 0 1 0 0 IO-APIC-edge rtc 12: 0 28 0 0 IO-APIC-edge PS/2 Mouse 15: 0 1 0 0 IO-APIC-edge ide1 18: 0 11215596 0 0 IO-APIC-level eth1 19: 0 784552 0 0 IO-APIC-level eth2 20: 0 21851043 0 0 IO-APIC-level eth0 24: 0 7290152 0 0 IO-APIC-level Mylex eXtremeRAID 2000 28: 0 2714670 0 0 IO-APIC-level dpti0 NMI: 0 0 0 0 LOC: 7836410 7836536 7836536 7836534 ERR: 0 MIS: 0 Because we don't use ATA harddiscs, I think the UDMA setting can't be the problem. Alle the discs are mounted on the Mylex RAID controller. Just the TAPE drive uses the Adaptec SCSI (dptio) controller. I think, with this knowledge, that this list is no longer responsible for this problem and I don't want to flood lists with off topic messages. Maybe you can recommend me a list, where you think that I can ask about the problem. Thanks for any help. If you were interrested, I'll post the (hopefully found) solution to the problem when I have one. kind regards Josef> To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/samba >