Kosa Attila
2005-07-06 13:58:27 UTC
Hello!
2 db Intel Xeon 3,2GHz, 2GB ram, 6 gigabites interfesz (2 tg3, 4 e1000).
Woody, 2.4.31-es vanilla kernel. Minden laban gigabitesen csatlakozik,
az XP fele crosskabellel (de mar probaltuk gigabites switchen keresztul
is). Az XP-kben (tobb is van) 2 db gigabites interfesz van, az egyikkel
a PDC halozatara csatlakoznak, a masikkal pedig a fenti gep gigabites
labaira crosskabellel. Van 1 db Windows NT 4.0 SP6 szerver is, szinten
gigabites labbal.
A kornyezet: windows tartomany, samba-s PDC (2.2.8a), amely ldap-bol
kapja a usereket. A gep tagja a tartomanynak, a libnss-ldap.conf fajlban
meg van adva neki az ldap szerver (a getent passwd latja a usereket), a
samba pedig a security = server, password server = IP.cim opciok
segitsegevel azonositani is tudja oket, ezzel nincs is gond. A samba
verzioja 2.2.3a-15. A sebessege meggyozo, a lentebb emlitett program
140-150.000kbit/s sebesseggel kommunikal a szerverrel (iptraf-fal
merve, Incoming ~90.000, Outgoing ~50.000), a windowsos halozati figyelo
szerint a halozat kihasznaltsaga eleri idonkent a 19%-ot. Ha egy XP-n
levo fajlokra futtatom a lenti programot, akkor a windowsos halozati
figyelo szerint a halozat kihasznaltsaga sosem haladja meg a 15%-ot. Az
XP-n a processzor kihasznaltsaga 50% folotti a program futasa kozben.
Van egy program, amely az XP-n futva a mappelt halozati meghajtorol
olvas, es oda is ir vissza. Bizonyos adatokat beolvas, es kulonbozo
fajlokat general az adatokbol. Ezek a fajlok viszonylag nagy meretuek
(mind az olvasottak, mind az irottak), a legnagyobb jelenleg 400MB. Nem
meghatarozhato idokozonkent azonban a Windowsban a kovetkezo
hibauzenetet kapjuk:
"Nem sikerült a késleltetett írás: A Windows nem tudta menteni a fájl
(\\szerver\elérési_út\fájlnév) összes adatát. Az adat elveszett. A hibát
hardverhiba vagy a hálózati kapcsolat hibája okozhatja. Próbálja máshova
menteni a fájlt."
Ekkor egy bejegyzes kerul az Esemenynaploba is, amelynek az allapotkodja
c000020c (lasd kesobb, hogy ez miert fontos). A Microsoft tudasbazisaban
nyomozgatva ezeket talaltuk, amelyek hasonlitanak erre a hibauzenetre:
http://support.microsoft.com/default.aspx?scid=kb;hu;321733 - itt
megegyezik a hibauzenet, de az allapotkod nem. Ugy tunik, hogy az SP2 az
XP-n megoldja ezt a problemat, atneztuk az emlitett dolgokat, es ugy
van, ahogy mukodnie kell.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q293842 -
hasonlo a hibauzenet, es az allapotkod is megegyezik. Viszont a
Microsoft szerint ez nem erinti az XP-ket...
http://www.tangent-systems.com/support/delayedwrite.html - ez egy jo
osszefoglalo a fenti problemarol. Elemzi, hogy milyen beallitasok
szuksegesek szerver es kliens oldalon, hogy ne lepjen fel ez a hiba
(tehat milyen parositasnal kell ki-, illetve bekapcsolni az SMB
signing-et).
Az utolso link alapjan ellenoriztuk a Windows NT szerver beallitasait
("amelyen" futtatva a programot nem jelentkezik a hibauzenet), es
megfelelnek a cikkben leirtaknak. A 2.2.3-as samba Windows NT
szerverkent viselkedik a halozaton, tehat ebben is ki kellene kapcsolni
az SMB signing-et... viszont ez a verzio nem ismer ilyen opciot! (Azt
nem ertem, hogy ha nem ismeri az SMB signing lehetoseget, akkor hogyan
tudja hasznalni? Ha meg nem tudja hasznalni, akkor nem is lehet
kikapcsolni benne, mert nincs bekapcsolva...) Mindenesetre kiprobaltuk a
2.2.8, 2.2.9-es verziokat is, de a drasztikus lassulason kivul mas
eredmeny nem szuletett, a hibauzenet ugyanugy jelentkezik az XP-n. (A
drasztikus lassulas azt jelenti, hogy 20.000kbit/s-nel nem megy feljebb
a sebesseg - szemben az elozo 150.000kbit/s-sel, Incoming 10.700,
Outgoing ~8.500)
Portoltuk a 3.0.14a, illetve a 3.0.20pre1-1 verziokat is, ezekben mar
van SMB signing opcio (client signing = disabled, server signing =
disabled), es ez megoldja a hiba kerdeset. Ezeket a verziokat hasznalva
nem jelentkezik a hibauzenet az XP-n. Viszont a sebessege gyalazatos!
Keptelenek vagyuk elerni a 30.000kbit/s-ot :( Ha a debug level = 3,
akkor pedig a 20.000kbit/s is atlephetetlen hatar. Az XP-n a processzor
kihasznaltsaga nem megy feljebb 27%-nal! A windowsos halozati figyelo
szerint a halozat kihasznaltsaga sosem haladja meg a 2%-ot!
Ami erdekes, hogy sima masolasnal (tehat a samba-rol masolok az XP-re,
az XP-rol inditva a masolast Intezovel) a sebesseg a windowsos halozati
figyelo szerint fix 11%, az iptraf szerint viszonylag fix 117.000kbit/s
(a 2.2.3a-15-os verzional). Viszont a masolas sem mindig fut le hiba
nelkul! Neha erkezik egy hibauzenet, miszerint "A hálózati név nem
elérhető" (vagy valami hasonlo - nem igazan lehet reprodukalni, neha
sikerul a masolas, neha nem).
Ime a 2.2.3a-15 samba verzio smb.conf fajlja (mint lathato, nem
tuningoltunk rajta szinte semmit, majdnem a default konfig):
[global]
workgroup = DOMAIN
server string = %h server
load printers = no
invalid users = root
log file = /var/log/samba/log.%m
debug level = 3
max log size = 100000
syslog = 0
security = server
password server = 192.168.18.47
encrypt passwords = true
socket options = TCP_NODELAY SO_SNDBUF=8760
local master = no
os level = 20
domain master = no
preferred master = no
wins server = 192.168.18.47
dns proxy = no
name resolve order = lmhosts wins host bcast
coding system = ISO8859-2
client code page = 852
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword
:* %n\n .
obey pam restrictions = yes
[megoszt]
comment = Megosztás
path = /samba
browseable = no
writeable = no
create mask = 0660
directory mask = 0770
share modes = no
write list = @irhat
force group = irhat
preexec = logger "Belepes %u user, %S sharehez, %M geprol"
Es a 3.0.20pre1 samba verzio smb.conf fajlja (ez mar az altalunk
tuningolt verzio, de probaltuk a 2.2.3a-15 konfigjaval is, mindossze a
verziovaltas miatt ervenytelen opciokat kiveve/atirva benne):
[global]
panic action = /usr/share/samba/panic-action %d
workgroup = DOMAIN
server string = %h server
load printers = no
invalid users = root
log file = /var/log/samba/log.%m
max log size = 100000
syslog = 0
security = server
password server = 192.168.18.47
encrypt passwords = true
passdb backend = tdbsam guest
socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY SO_RCVBUF=131072 SO_
SNDBUF=131072
local master = no
os level = 20
domain master = no
preferred master = no
wins server = 192.168.18.47
dns proxy = no
name resolve order = wins host lmhosts bcast
preserve case = no
short preserve case = no
default case = lower
case sensitive = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword
:* %n\n .
obey pam restrictions = yes
dos charset = CP852
unix charset = ISO8859-2
deadtime = 0
keepalive = 300
max open files = 10000
max xmit = 8192
block size = 4096
client signing = disabled
server signing = disabled
use spnego = yes
client use spnego = yes
change notify timeout = 300
mangle prefix = 4
stat cache = 0
lm announce = no
lm interval = 0
wins proxy = no
use sendfile = yes
map archive = no
kernel oplocks = no
[megoszt]
comment = Megosztás
path = /samba
browseable = no
writeable = no
create mask = 0660
directory mask = 0770
share modes = no
write list = @irhat
force group = irhat
preexec = logger "Belepes %u user, %S sharehez, %M geprol"
oplocks = no
level2 oplocks = no
nt acl support = no
csc policy = disable
set directory = no
wide links = no
follow symlinks = no
Az alabbi dolgokkal probaltuk tuningolni a tcp reszt:
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_mem
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_rmem
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_wmem
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 500000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Van, amit meg nem probaltunk ki. Peldaul azt, hogy szamit-e a
sebessegben, hogy az adott megosztasra ugy engedek be irni valakit,
ahogy a fenti konfigokban szerepel, vagy pedig ugy, hogy
writeable = yes
valid users = @irhat
Van valakinek valami otlete?
2 db Intel Xeon 3,2GHz, 2GB ram, 6 gigabites interfesz (2 tg3, 4 e1000).
Woody, 2.4.31-es vanilla kernel. Minden laban gigabitesen csatlakozik,
az XP fele crosskabellel (de mar probaltuk gigabites switchen keresztul
is). Az XP-kben (tobb is van) 2 db gigabites interfesz van, az egyikkel
a PDC halozatara csatlakoznak, a masikkal pedig a fenti gep gigabites
labaira crosskabellel. Van 1 db Windows NT 4.0 SP6 szerver is, szinten
gigabites labbal.
A kornyezet: windows tartomany, samba-s PDC (2.2.8a), amely ldap-bol
kapja a usereket. A gep tagja a tartomanynak, a libnss-ldap.conf fajlban
meg van adva neki az ldap szerver (a getent passwd latja a usereket), a
samba pedig a security = server, password server = IP.cim opciok
segitsegevel azonositani is tudja oket, ezzel nincs is gond. A samba
verzioja 2.2.3a-15. A sebessege meggyozo, a lentebb emlitett program
140-150.000kbit/s sebesseggel kommunikal a szerverrel (iptraf-fal
merve, Incoming ~90.000, Outgoing ~50.000), a windowsos halozati figyelo
szerint a halozat kihasznaltsaga eleri idonkent a 19%-ot. Ha egy XP-n
levo fajlokra futtatom a lenti programot, akkor a windowsos halozati
figyelo szerint a halozat kihasznaltsaga sosem haladja meg a 15%-ot. Az
XP-n a processzor kihasznaltsaga 50% folotti a program futasa kozben.
Van egy program, amely az XP-n futva a mappelt halozati meghajtorol
olvas, es oda is ir vissza. Bizonyos adatokat beolvas, es kulonbozo
fajlokat general az adatokbol. Ezek a fajlok viszonylag nagy meretuek
(mind az olvasottak, mind az irottak), a legnagyobb jelenleg 400MB. Nem
meghatarozhato idokozonkent azonban a Windowsban a kovetkezo
hibauzenetet kapjuk:
"Nem sikerült a késleltetett írás: A Windows nem tudta menteni a fájl
(\\szerver\elérési_út\fájlnév) összes adatát. Az adat elveszett. A hibát
hardverhiba vagy a hálózati kapcsolat hibája okozhatja. Próbálja máshova
menteni a fájlt."
Ekkor egy bejegyzes kerul az Esemenynaploba is, amelynek az allapotkodja
c000020c (lasd kesobb, hogy ez miert fontos). A Microsoft tudasbazisaban
nyomozgatva ezeket talaltuk, amelyek hasonlitanak erre a hibauzenetre:
http://support.microsoft.com/default.aspx?scid=kb;hu;321733 - itt
megegyezik a hibauzenet, de az allapotkod nem. Ugy tunik, hogy az SP2 az
XP-n megoldja ezt a problemat, atneztuk az emlitett dolgokat, es ugy
van, ahogy mukodnie kell.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q293842 -
hasonlo a hibauzenet, es az allapotkod is megegyezik. Viszont a
Microsoft szerint ez nem erinti az XP-ket...
http://www.tangent-systems.com/support/delayedwrite.html - ez egy jo
osszefoglalo a fenti problemarol. Elemzi, hogy milyen beallitasok
szuksegesek szerver es kliens oldalon, hogy ne lepjen fel ez a hiba
(tehat milyen parositasnal kell ki-, illetve bekapcsolni az SMB
signing-et).
Az utolso link alapjan ellenoriztuk a Windows NT szerver beallitasait
("amelyen" futtatva a programot nem jelentkezik a hibauzenet), es
megfelelnek a cikkben leirtaknak. A 2.2.3-as samba Windows NT
szerverkent viselkedik a halozaton, tehat ebben is ki kellene kapcsolni
az SMB signing-et... viszont ez a verzio nem ismer ilyen opciot! (Azt
nem ertem, hogy ha nem ismeri az SMB signing lehetoseget, akkor hogyan
tudja hasznalni? Ha meg nem tudja hasznalni, akkor nem is lehet
kikapcsolni benne, mert nincs bekapcsolva...) Mindenesetre kiprobaltuk a
2.2.8, 2.2.9-es verziokat is, de a drasztikus lassulason kivul mas
eredmeny nem szuletett, a hibauzenet ugyanugy jelentkezik az XP-n. (A
drasztikus lassulas azt jelenti, hogy 20.000kbit/s-nel nem megy feljebb
a sebesseg - szemben az elozo 150.000kbit/s-sel, Incoming 10.700,
Outgoing ~8.500)
Portoltuk a 3.0.14a, illetve a 3.0.20pre1-1 verziokat is, ezekben mar
van SMB signing opcio (client signing = disabled, server signing =
disabled), es ez megoldja a hiba kerdeset. Ezeket a verziokat hasznalva
nem jelentkezik a hibauzenet az XP-n. Viszont a sebessege gyalazatos!
Keptelenek vagyuk elerni a 30.000kbit/s-ot :( Ha a debug level = 3,
akkor pedig a 20.000kbit/s is atlephetetlen hatar. Az XP-n a processzor
kihasznaltsaga nem megy feljebb 27%-nal! A windowsos halozati figyelo
szerint a halozat kihasznaltsaga sosem haladja meg a 2%-ot!
Ami erdekes, hogy sima masolasnal (tehat a samba-rol masolok az XP-re,
az XP-rol inditva a masolast Intezovel) a sebesseg a windowsos halozati
figyelo szerint fix 11%, az iptraf szerint viszonylag fix 117.000kbit/s
(a 2.2.3a-15-os verzional). Viszont a masolas sem mindig fut le hiba
nelkul! Neha erkezik egy hibauzenet, miszerint "A hálózati név nem
elérhető" (vagy valami hasonlo - nem igazan lehet reprodukalni, neha
sikerul a masolas, neha nem).
Ime a 2.2.3a-15 samba verzio smb.conf fajlja (mint lathato, nem
tuningoltunk rajta szinte semmit, majdnem a default konfig):
[global]
workgroup = DOMAIN
server string = %h server
load printers = no
invalid users = root
log file = /var/log/samba/log.%m
debug level = 3
max log size = 100000
syslog = 0
security = server
password server = 192.168.18.47
encrypt passwords = true
socket options = TCP_NODELAY SO_SNDBUF=8760
local master = no
os level = 20
domain master = no
preferred master = no
wins server = 192.168.18.47
dns proxy = no
name resolve order = lmhosts wins host bcast
coding system = ISO8859-2
client code page = 852
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword
:* %n\n .
obey pam restrictions = yes
[megoszt]
comment = Megosztás
path = /samba
browseable = no
writeable = no
create mask = 0660
directory mask = 0770
share modes = no
write list = @irhat
force group = irhat
preexec = logger "Belepes %u user, %S sharehez, %M geprol"
Es a 3.0.20pre1 samba verzio smb.conf fajlja (ez mar az altalunk
tuningolt verzio, de probaltuk a 2.2.3a-15 konfigjaval is, mindossze a
verziovaltas miatt ervenytelen opciokat kiveve/atirva benne):
[global]
panic action = /usr/share/samba/panic-action %d
workgroup = DOMAIN
server string = %h server
load printers = no
invalid users = root
log file = /var/log/samba/log.%m
max log size = 100000
syslog = 0
security = server
password server = 192.168.18.47
encrypt passwords = true
passdb backend = tdbsam guest
socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY SO_RCVBUF=131072 SO_
SNDBUF=131072
local master = no
os level = 20
domain master = no
preferred master = no
wins server = 192.168.18.47
dns proxy = no
name resolve order = wins host lmhosts bcast
preserve case = no
short preserve case = no
default case = lower
case sensitive = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword
:* %n\n .
obey pam restrictions = yes
dos charset = CP852
unix charset = ISO8859-2
deadtime = 0
keepalive = 300
max open files = 10000
max xmit = 8192
block size = 4096
client signing = disabled
server signing = disabled
use spnego = yes
client use spnego = yes
change notify timeout = 300
mangle prefix = 4
stat cache = 0
lm announce = no
lm interval = 0
wins proxy = no
use sendfile = yes
map archive = no
kernel oplocks = no
[megoszt]
comment = Megosztás
path = /samba
browseable = no
writeable = no
create mask = 0660
directory mask = 0770
share modes = no
write list = @irhat
force group = irhat
preexec = logger "Belepes %u user, %S sharehez, %M geprol"
oplocks = no
level2 oplocks = no
nt acl support = no
csc policy = disable
set directory = no
wide links = no
follow symlinks = no
Az alabbi dolgokkal probaltuk tuningolni a tcp reszt:
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_mem
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_rmem
echo 400000 400000 400000 > /proc/sys/net/ipv4/tcp_wmem
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 500000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Van, amit meg nem probaltunk ki. Peldaul azt, hogy szamit-e a
sebessegben, hogy az adott megosztasra ugy engedek be irni valakit,
ahogy a fenti konfigokban szerepel, vagy pedig ugy, hogy
writeable = yes
valid users = @irhat
Van valakinek valami otlete?
--
Udvozlettel
Zsiga
Udvozlettel
Zsiga