ZFS only file server adott hardwaren negyed olyan lassu mint a win2k8

Fórumok

Sziasztok

Par eve mar nyomkodom a freebsd-t de most olyat egek mint a reichstag. Lecsereltem egy cegnel egy megtort win2k8 file serveren a rendszert 8.1-re es az istennek nem birok kicsavarni belole 30MB/sec-ne tobbet de altalaban csak 10-20 megy, a win meg siman tudott 70et is. A hardware egy ich7es alaplap intel matrixraid satavezerlovel raid nelkul. A storage sata winyok zfs mirrorban, 2db zpool egy a system egy pedig az adatoknak. 3db realtek gigabites kartya van lagg0nak osszefuzve loadbalance modban. Mtu-t nem tudok emelni a kartya tipusa miatt minden mast mar probaltam. A szimptoma: iperfel merve lefele ki tudok huzni 50MB/sec-et ezzel ki is bekulnek de felfele nem megy csak 25 maximum. Illetve a winyo irasi sebessege is eleg gyer.
A raid5 tombot direkt kihagytam a jatekbol mert ugy vettem eszre freebsd-n nem lehet rendesen varialni a zfs blokkmeretet. (tudom -b vagy volblocksize de szarik ra)

Probaltam mar mindent tuningolni, a sysctl.conf:

vfs.read_max=64

kern.ipc.maxsockbuf=2097152
net.inet.tcp.recvspace=262144
net.inet.tcp.sendspace=262144
net.inet.tcp.mssdflt=1452
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=65535
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
vfs.zfs.txg.write_limit_override=1048576000
net.inet.tcp.rfc1323=1
kern.polling.enable=1
kern.ipc.nmbclusters=32768
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.mssdflt=1460
net.inet.udp.maxdgram=57344
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_inc=524288
net.inet.tcp.delayed_ack=0
net.inet.tcp.inflight.enable=0
net.inet.tcp.path_mtu_discovery=0
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.recvbuf_max=16777216
kern.ipc.maxsockbuf=16777216
kern.ipc.somaxconn=32768
kern.maxfiles=65536
kern.maxfilesperproc=32768
kern.maxvnodes=800000

a loader.conf:

kern.maxusers=1024

vfs.root.mountfrom="zfs:rpool"
vfs.zfs.prefetch_disable="0"
vm.kmem_size_max=1536M
vm.kmem_size=1536M
vfs.zfs.arc_max=256M
vfs.zfs.vdev.cache.size=24M
vfs.zfs.vdev.min_pending="4"
vfs.zfs.cache_flush_disable="0"
vfs.zfs.zil_disable="0"

kern.hz="2000"
aio_load="YES"
hw.igb.rxd=4096
hw.igb.txd=4096

vfs.zfs.txg.timeout="5"

vfs.zfs.vdev.min_pending=4
vfs.zfs.vdev.max_pending=8

A sambat aio-ra raktam ez picit segitett bar azt irjak nem tul bolcs dolog ez zfsen.

Van valakinek valami otlete mit erdemes meg vakarni?

Hozzászólások

Sem a Samba, sem a ZFS nem a sebességéről híres.
--
2e845cb4c3a5b5bd6508455b1739a8a2

3db realtek amit az re driver hajt meg

re0: port 0xc000-0xc0ff mem 0xe7410000-0xe7410fff,0xe7400000-0xe740ffff irq 17 at device 0.0 on pci3
re0: Using 1 MSI messages
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
miibus0: on re0
rgephy0: PHY 1 on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

ezek lagg0ban osszefogva:

lagg0: flags=8843 metric 0 mtu 1500
options=38db
ether ab:ab:ab:ab:ab:ab
inet 192.168.1.77 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect
status: active
laggproto loadbalance
laggport: re1 flags=4
laggport: re2 flags=4
laggport: re0 flags=4

Tennék bele egy szem gigás intelt és megnézném mit csinál azzal. Nyilván nem fog csodát tenni, de mi szívtunk alaplapi gigás realtek kártyával. Az történt, hogy valami őrült nagy latency-vel ment a tcp kapcsolat felépítés, ami egészen addig nem derült ki, amíg volt látványos egy távoli SQL eléréssel. Az hogy sw vagy hw bug az nem derült ki, de nem is izgat, mert Intel kártyával rögtön minden álomszerű.

A sebességet érdemes lenne összefogás nélkül is megnézni, mert azt a switchen is fel kell konfigolni.

Az mtu intel gigás kártyánál 16348 byte lehet, broadcomnál (driver miatt) pedig 9000 ha jól emlékszem. Az em helyett pedig már talán az ige vagy milyen drivert ajánlják. A broadcom szintén jó választás, de szerintem nem MTU gondod lesz. Ahogy fentebb írták könnyen lehet, hogy az ICH7 + FreeBSD nem egy csoda, de azért a 20MB-nál bőven többet kéne tudnia.

ha már megállapításokat teszel, mert hallottál valamit, és partíciós táblát meg journalingot hozol szóba, amikor egy ZFS "FS" egyáltalán nem is olyan FS (az a zpool), akkor azért még megtippelnéd, hogy 30000 ext3 mennyi idő alatt mountolódna, ha egyáltalán? ugye az is journaling. :)

amúgy a sok zfs / lassú mount kb 4 éves probléma. upgrade!

Szerintem a filerendszereket nem arra talaltak ki hogy par milliot peldanyositsunk belolluk. De ha mar igy teszunk miert kell egyszere felcsatolni mindet, amikor nincs parmillio user egyszerre belepve.
Ha megis, akkor plane hulyeseg a parmillio FS.

Nem latom emogott a logikat.

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

nem kellenek a beugratós kérdéseid, pontosan tudod, miről beszélek :)

felhívtam a figyelmet, hogy terjengő történetek alapján ne vonjunk le tanulságokat és ennyi. de mondjuk azt, hogy annyi ZFS-nek van racionalitása a gépen, amennyit az alkalmazás megkövetel és ami a hardver méretezésének megfelel. nyilvánvalóan 1-2 millió egy PC-n nem tartozik ide.

amúgy pár ezer ZFS nem gond, ha akarod, majd kipróbálom 100000-rel, a lényeg, hogy a kérdéses bugot jelentős mértékben javították ezer éve.

Eztet találtam:

"
Another MAJOR thing to avoid (and i've seen this come up on quite a few occasions) is samba logging. disable it completely. I've seen it reduce performance 10 fold for each log level.
"

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb

ZFS-re passz, de sambahoz ezek meg nem artanak FreeBSD-n:

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
use sendfile = yes
min receivefile size=16384
aio read size = 16384
aio write size = 16384
aio write behind = true

Persze a buffer mereteket nem art kiegyensulyozni, nekem harom napra igy is megfeleltek. Foleg a sendfile() vicces.

---
pontscho / fresh!mindworkz

A gépen belül mennyivel másol?

Alaplapi vezérlők elég siralmasan teljesítenek freebsdvel.
Ha alaplapi vezérlő akkor inkább linux.
Nekem ez a tapasztalatom.

Hasonló szerverem van nekem is, sajnos csak megerősíteni tudom a tapasztalataidat. Azért leírom, referenciának:

Hardver:
3 SATA drive csücsül alaplapi ICH7-es SATA vezérlőn, egy nagy raidz1 poolba kötve. Egy db. Gb-es alaplapi Realtek kártyám van:
re0: port 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 17 at device 0.0 on pci2
re0: Using 1 MSI messages
re0: Chip rev. 0x28000000
re0: MAC rev. 0x00000000
miibus0: on re0

Rendszer:
FreeBSD ***.***.hu 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

Konfig:

/boot/loader.conf:
zfs_load="YES"
vfs.root.mountfrom="zfs:zroot"
aio_load="YES"
vfs.zfs.prefetch_disable=0

(Nálam a prefetch gyorsított az olvasáson.)

/etc/sysctl.conf: semmi releváns

smb.conf releváns része:
use sendfile = yes
socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072
min receivefile size = 16384
aio read size = 16384
aio write size = 16384
aio write behind = yes

SAMBA teljesítmény:
- nagy fájl letöltés: 55 MB/s
- nagy fájl visszaírás: 20-25 MB/s

Ha lesz szoftveres megoldás, nagyon érdekel (hardver upgrade nem opció, igaz, a userek nem panaszkodnak).

[grammarnazi]
negyed olyan lassu, mint x = 4x olyan gyors, mint x :)
[/grammarnazi]

Hi!

Szerintem szedjük szét a problémát és menjünk sorban...

0. Menj vissza default beállításokra. (OK, polling maradhat)

1. Először 1 db hálókarival juss el oda, hogy TCP szinten jó a sebesség.. iperf, ilyesmi. manapság különösebb tuningolás nélkül mennie kell, default opciókkal. delayed ack, inflight, slow start okozhat prolbémát de azok inkább már rég javított bugok voltak. Ha nem megy, akkor több, mint valószínű, hogy a hardverrel kell csinálni valamit (illetve a hardver/freebsd kombó nem szereti egymást).

2. Több szálon lesz írás olvasás, akkor ezzel a vezérlővel és freebsd-vel a zfs prefetch-t kapcsold ki. egész másképp viselkedik, mint solarison. (szarul) Bár látni iostatban, ha fogy a diszk. Mást nem nagyon kell állítani ZFS témában, max. az ARC-t ízlés szerint.

3. Ha NFS lesz freebsd-n, akkor a ZIL-t még kapcsold ki.

4. Küzdünk páran a Samba teljesítményével...

volblocksize amúgy csak ZVOL-nál számít, ZFS-nél nincs ilyen, hogy állandó blokkméret, illetve a maximumot tudod állítani a recordsize FS paraméterrel, (csak az új fájlokra vonatkozik), de fájlszervernél teljesen jó kell, hogy legyen a default..

Az otlet igazabol csak annyi, hogy ha ZFS akkor Solaris/OpenSolaris. Minden mas esetben nyugod lesz a sebesseggel.
Meg esetleg az, hogy alaplapi vezerlok elfelejt, es venni egy normalis RAID kartyat.
--


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

probalkozz azzal elso korben, hogy a realteket kidobod a budos picsaba, es emberi halokartyakat raksz a helyebe. egy 10K hufos intel gigas tokeletes valasztas peldaul.

sendfile-t kapcsold ki a sambaban. elvileg gyorsit, itt gyakorlatilag nem, mivel valami tervezesi elbaszas folytan a sendfile() tobb szintet jar vegig a cache-ek hierarchiajaban, mintha nem ugy csinalnad, ZFS-en.

remelem legalabb 4G memoriad van, es 64biten vagy, 32bites vicces neha a ZFS. de 8G se art bele.

egyebkent meg ha windows van minden kliensen, akkor egy normalisan konfigolt win2k8 PDC jo otlet, csak nem szabad public IP-t hagyni neki, illetve semmilyen direkt portforwardolt elerest. samba pdc egy szopas, win2k8 alatt normalisan mennek a dolgok.