PDA

View Full Version : Samba e utilizzo CPU


Devil!
30-05-2007, 20:02
Da quando ho sostituito l'hardware sul muletto (prima avevo un Athlon XP@1100MHz, ora un VIA C3@600MHz) su cui gira Debian ho un problema che mi affligge: quando trasferisco un file in LAN il processo relativo a Samba (smbd) tende ad occupare il 100% della CPU e il trasferimento di file risulta molto lento (max 2MB/s) pur essendo la rete a 100Mbit.

E' chiaro dunque come sia l'occupazione della CPU il collo di bottiglia e non credo dipenda dall'hardware in sè, perchè, anche se è vero che il mio è stato un downgrade in termini di prestazioni, ho confrontato le prestazioni ottenute con sistemi analoghi al mio non riscontrando questi problemi.

Non riesco quindi a capire a cosa sia dovuta questa eccessiva occupazione della cpu e relativa lentezza durante il trasferimento di file.

Potrebbe essere dovuto al fatto che l'HDD (250GB 7200rpm) sia al 90% pieno? (anche se mi suonerebbe strano, poichè spesso è quasi pieno e non ho mai avuto questi problemi prima del cambio di piattaforma.

Preciso che durante il cambio di piattaforma ho semplicemente ricompilato il kernel per la nuova architettura, selezionando i driver (spero) adeguati

Allego parte della config di samba

[global]
log file = /var/log/samba/log.%m
smb passwd file = /etc/samba/passwd
encrypt passwords = false
public = yes
server string = Debian
writeable = yes
workgroup = LOGICSTORM
security = share
syslog = 0
max log size = 1000
interfaces = 127.0.0.0/8 eth1

[storage]
comment = storage
path = /storage/
public = yes
writable = yes
printable = no
create mask = 0777

Cosa potrebbe essere? qualche conflitto? qualche driver non opportuno?

stefanoxjx
30-05-2007, 20:29
Non ti posso aiutare più di tanto, però sul mio serverino che è un C3 600Mhz, copiando una cartella di 190Mb ho questa occupazione di cpu:


Server:/home/root# top | grep smbd
23069 stefano 15 0 10504 3076 2220 S 0.3 0.6 1:35.06 smbd
23069 stefano 15 0 10504 3076 2220 R 17.5 0.6 1:35.59 smbd
23069 stefano 15 0 10504 3076 2220 R 23.8 0.6 1:36.31 smbd
23069 stefano 16 0 10504 3076 2220 R 30.1 0.6 1:37.22 smbd
23069 stefano 15 0 10504 3076 2220 R 25.8 0.6 1:38.00 smbd
23069 stefano 15 0 10504 3076 2220 R 24.4 0.6 1:38.74 smbd
23069 stefano 15 0 10504 3076 2220 R 25.5 0.6 1:39.51 smbd
23069 stefano 16 0 10504 3076 2220 R 20.2 0.6 1:40.12 smbd
23069 stefano 15 0 10504 3076 2220 R 18.5 0.6 1:40.68 smbd
23069 stefano 15 0 10504 3076 2220 R 23.7 0.6 1:41.40 smbd
23069 stefano 16 0 10504 3076 2220 S 5.9 0.6 1:41.58 smbd


e il trasferimento dati si aggira attorno ai 7Mb/sec.
Ho una debian con kernel non ricompilato:

Linux Server 2.6.18-4-486 #1 Mon Mar 26 16:39:10 UTC 2007 i686 GNU/Linux


Ciao.

Devil!
30-05-2007, 21:00
Grazie, posto pure io qualche info aggiuntiva

Linux server 2.6.21.1-fix #1 Mon May 7 11:39:18 CEST 2007 i686 GNU/Linux

> dpkg -l|grep samba
ii samba 3.0.24-6 a Lan
Manager-like file and printer server fo
ii samba-common 3.0.24-6 Samba
common files used by both the server a
ii samba-doc 3.0.24-6 Samba
documentation
ii webmin-samba 1.200-1 samba
control module for webmin

00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev
22)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AG
P]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 12)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/
C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 08)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 20)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139
C+ (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139
C+ (rev 10)
00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)

vizzz
30-05-2007, 22:26
dma è attivo sui dischi?

Tasslehoff
30-05-2007, 22:38
Giusto per informazione ti posto i dati del mio Epia 5000A con Debian Etch

Concordo con la verifica sul dma, prova a fare un hdparm -tT /dev/devicedisco e vedi che risultati ti da

Al massimo proverei a installare samba dai sorgenti per verificare

> dpkg -l | grep -i samba
ii samba 3.0.24-6etch2 a LanManager-like file and printer server fo
ii samba-common 3.0.24-6etch2 Samba common files used by both the server a

> uname -a
Linux ritz 2.6.16-2-486 #1 Sat Jul 15 21:23:01 UTC 2006 i686 GNU/Linux

*-pci
description: Host bridge
product: VT8601 [Apollo ProMedia]
vendor: VIA Technologies, Inc.
physical id: d0000000
bus info: pci@00:00.0
version: 05
width: 32 bits
clock: 33MHz
configuration: latency=8
resources: iomemory:d0000000-dfffffff
*-pci
description: PCI bridge
product: VT8601 [Apollo ProMedia AGP]
vendor: VIA Technologies, Inc.
physical id: 1
bus info: pci@00:01.0
version: 00
width: 32 bits
clock: 66MHz
capabilities: pci normal_decode bus_master cap_list
*-display
description: VGA compatible controller
product: CyberBlade/i1
vendor: Trident Microsystems
physical id: 0
bus info: pci@01:00.0
version: 6a
size: 8MB
width: 32 bits
clock: 66MHz
capabilities: vga bus_master cap_list
configuration: latency=32
resources: iomemory:e1800000-e1ffffff iomemory:e2000000-e201ffff iomemory:e1000000-e17fffff irq:11
*-isa
description: ISA bridge
product: VT8231 [PCI-to-ISA Bridge]
vendor: VIA Technologies, Inc.
physical id: 11
bus info: pci@00:11.0
version: 10
width: 32 bits
clock: 33MHz
capabilities: isa bus_master cap_list
configuration: driver=parport_pc latency=0
*-ide
description: IDE interface
product: VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE
vendor: VIA Technologies, Inc.
physical id: 11.1
bus info: pci@00:11.1
version: 06
width: 32 bits
clock: 33MHz
capabilities: ide bus_master cap_list
configuration: driver=VIA_IDE latency=32
resources: ioport:e000-e00f

Devil!
30-05-2007, 22:49
dma è attivo sui dischi?

in effetti non è attivato

> hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30515/255/63, sectors = 490234752, start = 0

però se provo ad attivarlo mi dà:

> hdparm -d1 /dev/hda

/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

sbaglio comando?

Devil!
30-05-2007, 22:51
Concordo con la verifica sul dma, prova a fare un hdparm -tT /dev/devicedisco e vedi che risultati ti da


> hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 62 MB in 2.05 seconds = 30.25 MB/sec
Timing buffered disk reads: 10 MB in 3.35 seconds = 2.98 MB/se

come sono?

AnonimoVeneziano
30-05-2007, 22:57
Per eseguire modifiche devi lanciare "hdparm" da root

Ciao

Devil!
30-05-2007, 22:59
Per eseguire modifiche devi lanciare "hdparm" da root

Ciao

sì, i comandi li do sempre da root

AnonimoVeneziano
30-05-2007, 23:06
sì, i comandi li do sempre da root

Strano, avevi ricompilato il kernel togliendo qualche driver IDE per caso?

Che chipset monta la scheda madre?

Ciao

stefanoxjx
30-05-2007, 23:12
Io proverei ad installare il kernel precompilato debian e secondo me il problema sparisce!
Nel caso con il kernel precompilato debian funzioni tutto bene, basterà solo verificare la configurazione del kernel che hai compilato tu!

Devil!
30-05-2007, 23:21
Strano, avevi ricompilato il kernel togliendo qualche driver IDE per caso?

Che chipset monta la scheda madre?

Ciao

Monta chipset VIA e fra le opzioni ATA/ATAPI/MFM/RLL support del kernel ho abilitato come modulo (M) quello relativo a via82cxxx chipset support; dando lsmod risulta infatti caricato

se fosse un problema di driver ATA non dovrei avere basse performance in lettura/scrittura locale ?

vizzz
30-05-2007, 23:25
magari l'opzione nel bios per dma è disabilitata, prova a dare un occhiata.

/dev/hdc:
Timing cached reads: 1102 MB in 2.00 seconds = 551.02 MB/sec
Timing buffered disk reads: 160 MB in 3.02 seconds = 53.00 MB/sec

Devil!
30-05-2007, 23:44
leggendo l'help durante la configurazione del kernel del modulo via82cxxx:

"This driver adds explicit support for VIA BusMastering IDE chips.
This allows the kernel to change PIO, DMA and UDMA speeds and to configure the chip to optimum performance."

quindi non dovrebbe essere sufficiente?

la sezione relativa ai chipset è così configurata


#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=m
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set


forse mi conviene attuare il metodo empirico "abilito tutto così son sicuro che vada" :stordita:

googlando: http://www.linuxquestions.org/questions/showthread.php?p=1374133#post1374133

ma in pratica è quello che ho fatto io, a parte compilare come modulo invece che staticamente

vizzz
30-05-2007, 23:52
io proverei a compilare staticamente, alcuni parti del kernel hanno controidicazioni ad essere usate come modulo (vedi fs).

Devil!
31-05-2007, 00:00
io proverei a compilare staticamente, alcuni parti del kernel hanno controidicazioni ad essere usate come modulo (vedi fs).

Già, domani proverò a ricompilare staticamente e se non funziona ancora proverò un qualche kernel standard

Grazie per il supporto

Tasslehoff
31-05-2007, 09:13
A me era successa una cosa simile con un serverino al lavoro, in quel caso il kernel era stato compilato con il supporto per il chipset della mainboard corretto, purtroppo però il kernel (era ancora un 2.4.18) non supportava ancora la versione del chipset via che stavo utilizzando.
Mi è bastato cambiare kernel e ricompilarlo per far filare hdparm a razzo con l'udma attivato.

Cmq confermo che i valori del test di hdparm sono molto bassi, nel Timing buffered disk reads dovresti ottenere come minimo un 20 MB/s con un disco da 3.5" poi dovresti ottenere almeno 40-50 MB/s

flapane
31-05-2007, 18:56
credo che il problema sia proprio il compilarlo statico piuttosto che modulare, sul pc ottengo circa 65MB/s ed andando a controllare, il modulo per il dma dell'nforce4 è built-in nel mio kernel (evidentemente così mi consigliarono all'epoca):D

Devil!
31-05-2007, 19:14
Avevate ragione, ho ricompilato il kernel (in pausa pranzo all'uni :D) e ora esce questo

> hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30515/255/63, sectors = 490234752, start = 0

Quindi il DMA ora è attivo e infatti i dati lo confermano: durante lo scambio di un file in LAN la velocità si attesta sui 7,5MB/s pur continuando a riscontrare un elevato utilizzo di CPU ( > 90%)

flapane
31-05-2007, 19:31
forse ci può stare, perchè quando sul 200mmx passavo un file a 100mbit via l'hag, il pc si impallava, la cpu andava al 100% e la velocità non superava i 5 6 Mbit.

Devil!
31-05-2007, 20:37
forse ci può stare

sì, credo pure io; d'altronde la cpu è quella che è e per quel che consuma mi va più che bene

Tasslehoff
31-05-2007, 21:35
Quindi il DMA ora è attivo e infatti i dati lo confermano: durante lo scambio di un file in LAN la velocità si attesta sui 7,5MB/s pur continuando a riscontrare un elevato utilizzo di CPU ( > 90%)ottimo direi, io cmq proverei a controllare un po' in rete se c'è un modo per ridurre l'occupazione di cpu.
Io col il mio C3 da 533MHz ottengo transfer rate tra i 5 e i 7 MB/s ma ho una occupazione cpu tra il 15 e il 35%

Prova ora a fare un hdparm -tT /devicedisco

Devil!
31-05-2007, 21:39
Prova ora a fare un hdparm -tT /devicedisco


> hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 66 MB in 2.04 seconds = 32.41 MB/sec
Timing buffered disk reads: 46 MB in 3.07 seconds = 14.98 MB/se

Tasslehoff
31-05-2007, 21:50
> hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 66 MB in 2.04 seconds = 32.41 MB/sec
Timing buffered disk reads: 46 MB in 3.07 seconds = 14.98 MB/seDecisamente meglio, ma migliorabile ancora, devi risolvere il problema dell'occupazione cpu e imho non può che salire.

Tieni presente che con il mio Epia e un disco da 2.5" e 5400rpm i miei risultati sono questi

/dev/hda:
Timing cached reads: 122 MB in 2.03 seconds = 60.02 MB/sec
Timing buffered disk reads: 86 MB in 3.06 seconds = 28.13 MB/sec

stefanoxjx
31-05-2007, 22:45
> hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 66 MB in 2.04 seconds = 32.41 MB/sec
Timing buffered disk reads: 46 MB in 3.07 seconds = 14.98 MB/se

Sulla mia scheda Epia C3 da 600 Mhz, ottengo questo:


/dev/hda:
Timing cached reads: 132 MB in 2.03 seconds = 65.14 MB/sec
Timing buffered disk reads: 118 MB in 3.05 seconds = 38.70 MB/sec


e nel trasferimento di un file da 160Mb ho avuto punte massime di occupazio cpu del 25.8%.

Devil!
01-06-2007, 08:07
In sostanza ora, rispetto ai vostri valori:

- le prestazioni della LAN sono adeguate
- il carico della cpu è ancora elevato
- le performance su disco sono praticamente la metà

qualche idea?

stefanoxjx
01-06-2007, 08:38
In sostanza ora, rispetto ai vostri valori:

- le prestazioni della LAN sono adeguate
- il carico della cpu è ancora elevato
- le performance su disco sono praticamente la metà

qualche idea?

E' abbastanza ovvio che dipende dalla configurazione del kernel.
Però per togliermi ogni dubbio, proverei ad installare per un attimo il kernel pre compilato debian.
Se così i valori si allineano ai nostri, allora sai che devi concentrarti solo sulla configurazione del kernel, altrimenti so c@zzi :D

vampirodolce1
01-06-2007, 10:24
Non sottovalutare l'FTP, che rispetto a SMB effettua minori controlli sui pacchetti e il risultato e' che le conferme (ACK) occupano molta meno banda e meno CPU rispetto a Samba.
Nel caso non mi fossi spiegato, voglio dire che se trasferisci 1GB via SMB avrai 1GB da una parte e diciamo 400MB di ritorno, se invece fai la stessa cosa via FTP avrai 1GB da una parte e 200 di ritorno, con risparmio sia in termini di bandwidth che di processore.

Tasslehoff
01-06-2007, 10:29
Non sottovalutare l'FTP, che rispetto a SMB effettua minori controlli sui pacchetti e il risultato e' che le conferme (ACK) occupano molta meno banda e meno CPU rispetto a Samba.
Nel caso non mi fossi spiegato, voglio dire che se trasferisci 1GB via SMB avrai 1GB da una parte e diciamo 400MB di ritorno, se invece fai la stessa cosa via FTP avrai 1GB da una parte e 200 di ritorno, con risparmio sia in termini di bandwidth che di processore.Può essere, però ci sono anche aspetti negativi, ad es nel caso di trasferimenti di tanti file con l'ftp ci metti una vita e mezza a causa delle millemila connessioni che faresti utilizzando questo protocollo

Io sto valutando NFS