Rendszer:
-sw: Debian Etch
-hw: P4 3GHz CPU, 2GB RAM, SATA hdd-k software RAID1-ben
Probléma:
MS Office dokumentumok megnyitása és mentése, PDF fájlok megnyitása, ill. ezen típusú állományok csatolása mail-hez (Outlook) rettenetesen lassú. A sebesség töredéke ahhoz képest, mint amikor ugyanazt az file-t a helyi hdd-ről olvasom be. Ezen file-ok mozgatása oda-vissza szemvillanás alatt megtörténik, tehát a hálózati sávszélesség, és disk sebesség rendben van. A probléma jelentkezik XP-t és OSX-et futtató klienseknél egyaránt.
Magasabb debug level-t állítva a logokból az derül ki, hogy az alábbi bejegyzések között kb. 1 másodperc várakozás van (tail-lel szépen látható hogy ott áll meg mindig, de a beidézett sorok idején is látszik), ill. mivel ez egy-egy file megnyitásakor 6-8-szor ismétlődik, ezért annyiszor ~1mp wait:
[2007/10/01 17:53:43, 3] smbd/reply.c:send_file_readX(2626)
send_file_readX: sendfile fnum=10228 max=8192 nread=8255
[2007/10/01 17:53:44, 6] smbd/process.c:process_smb(1109)
got message type 0x0 of len 0x3b
Kifogyhatatlan mennyiségű doksit, fórum témát találok ami samba+slow témakört boncolgat, legtöbb esetben lock-olással kapcsolatos állítgtás a javasolt megoldás. Az összes lock-oláshoz köthető opciót állítottam már, minden elképzelhető kombinációban: semmi eredmény, leszámítva hogy egyszer jól működött _kettő_ egész napig. :)
Ezek állításával próbálkoztam eddig:
-
locking
lock spin count
lock spin time
strict locking
posix locking
blocking locks
oplocks
level2 oplocks
fake oplocks
kernel oplocks
use sendfile
Próbáltam továbbá klienst tartományba léptetni, XP-ben meghajtót újramappelni (valahol ez volt a megoldás), kitépkedni a hajam szálanként, stb. - eredmény nulla.
Névfeloldás rendben (reverse is), a samba-t futtató gépen és a klienseken úgyszintén - ezt is láttam több helyen problémaként említve.
Ugyanezzel a samba config-gal 3 másik gép tökéletesen működik.
Találkozott már valaki ilyen hülyeséggel?
smb.conf:
[global]
workgroup = ****
netbios name = ****
server string = Szerver
wins support = yes
dns proxy = no
name resolve order = lmhosts hosts wins bcast
interfaces = lo eth0
bind interfaces only = true
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = user
os level = 34
announce version = 5.0
local master = no
domain master = no
preferred master = no
dos charset = CP852
unix charset = ISO8859-2
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
load printers = no
socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
[homes]
comment = Home Directories
browseable = no
writeable = yes
readonly = no
[shared]
path = /home/shared
writable = yes
browseable = yes
public = yes
read only = no
create mask = 0660
directory mask = 0770
- 2729 megtekintés
Hozzászólások
egyszer hasonlót szívtam, a megoldás az volt, hogy szar volt a switch. nem vitch. izé. nem vicc.
Erősen low-end darab volt: Repotec(R)(C)(WC)
Az, h eccer két napig jó volt, hasonlóra utal. Nálam is volt rossz, aztán jó, aztán rossz, aztán kivágtam. Ha DVD-t kellett áthúzni, repült. Ha XP-t telepíteni hálózatról, akkor a 100MB-es vonalon 10+ óra volt, még átment a 600 MB.
- A hozzászóláshoz be kell jelentkezni
meggondolandó...
bár itt egy linksys cucc van, nem a leggagyibb, de hát nem mondható high-end -nek sem. egy próbát mindenképp megér.
köszi.
- A hozzászóláshoz be kell jelentkezni
valóban hálózati eszköz hibája okozta a galibát, az alaplapi hálókártya volt a hunyó:
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
egy rtl8139-el minden gond nélkül hasít.
köszi a tippeket.
- A hozzászóláshoz be kell jelentkezni
Próbáld meg a socket options sort kivenni és teszteld.
A vicces az, hogy valami teljesen más problémát kerestem fél éve a samba kapcsán és vagy 10 ezzel a problémával foglalkozó oldalba botlottam... most meg nem találom őket :( :)
Azért még nézegetem...
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni