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
A poen kedveert ideirom, hogy az ftp fele olyan lassu mint a samba. nem vicc! KTHX DIE
Milyen hálókártya van ebben a gépben?
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.
A switchen nem lehet beallitani mert nem mangelheto :-)
A regi alaplapban volt egy em driver altal hajtott intel azzal sem volt alomszeru a dolog :-(
Bar most uj alaplapot vadaszunk broadcom kartyaval mert annal lehet mtut emelni rendesen
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.
+1. Hallottam, hogy az egyik helyen ZFS-en külön fs-t ajánlottak ki minden usernek, mert az milyen jó. Nem is volt semmi baj, míg nem kellett a szervert rebootolni. A boot time több, mint 1 nap volt a ZFS miatt... :-)
najo de az 30ezer fs volt es a szie-n tortent a sunray servernel ha jol tevedek
na és? Meddig tart felolvasni egy "partíciós" táblát 30ezer rekorddal (ellenőrizni ugye nem kell az fs-eket, hisz journaling van)? Legyen mondjuk 256 byte adat per fs, az sincs 8 mega. Nehogymá :-)
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!
Honnantól kezdve nem probléma, és mennyivel gyorsult/eszik kevesebb erőforrást?
Egy mai PC-n van racionalitása 1-2 millió zfs-nek?
suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.
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
A zfs fs-hez köthető feature-jei jelentik a logikát mögötte (per user snapshotolás, kvóta -tudom, hogy erre van egy gagyi workaround-, send, receive).
suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.
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.
Nem azért, mert az jó, hanem csak így lehetett rendesen kvótázni. Most már belekerült a feature, ezért nem kell minden usernek külön fs.
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
thx ezt megprobalom
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
thx ez mar megvan nalam igy nez ki:
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY IPTOS_LOWDELAY
min receivefile size=16384
use sendfile=true
aio read size = 16384
aio write size = 16384
aio write behind = true
A nagy recv()/send() buffer ahogy probalgattam anno eleg problemas volt, nem emlekszem mar pontosan, de eleg valoszinu, h ezert nott oda inkabb az a 8k-s buffer.
---
pontscho / fresh!mindworkz
Ja igen es ZFS storage pool version 15
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.
ICH7 van. lehet hogy erdemesebb volna ich10el probalkoznom? vagy csak a raid kartya segit? Valakinek van ich7es gepe 8.1-el?
Igaza van az előző postolonak.
Gépen belül mennyit tud?
### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb
Van, de még 6.4-el. :) Nem egy nagyműtét várományos gép, cserébe 430 nap már az uptime-ja a Broadcom kártya beépítés óta. :) (Csak az egyik alaplapi integrált kártya intel, másik a Yukon Marvell csoda és ezért kapott használható kártyát.)
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).
A hiba gyökere:
Intel HBA
Non-Intel LAN.
A megoldás:
Non-Intel HBA
Intel LAN.
A zfs és a sendfile sem feltétlenül barátok jelenleg, erre is érdemes figyelni...
suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.
Köszi szépen mindkettőtöknek!
[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.
--
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.
Kés,villa,olló gyerek kezébe nem való. ;)
--------------------------------------------
http://www.youtube.com/watch?v=Aj1n2_qEq5k