Samba a pomalé FoxPro účetnictví

[Petr Bartel]

Zdravim,

rad bych se zeptal na Vase zkusenosti, pripadne rady ohledne zrychleni pristupu na sambu a prenosu dat. Mam server s ucetnictvim Premier, ktera hrde proklamuje ze jejich produkt na linuxu(sambe) pracuje. Bohuzel diky jejich "upgradum" je vykonnost stale nizsi a nizsi a odezva aplikace klesa pod miru unosnosti.

- samotna aplikace je ve visual foxpro (tedy soubory dbf, fpt, dst, ...), velke mnozstvi malych souboru, caste zapisy i cteni

- relevantni nastaveni samby takto

jedna se o verzi 3.2.5

...

smb ports = 139

level2 oplocks = no
oplocks = no
kernel oplocks = no

max connections = 20
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=16384
SO_SNDBUF=16384

...

[premier]
   path = /samba/premier
   public = yes
   browsable = yes
   writable = yes
   create mode = 0664
   create mask = 0664
   directory mask = 0775
   read list = @users
   write list = @users


pokud byste meli jakekoli navrhy na nastaveni samby, linuxu na kterem to
bezi, ci windowsich stanic, budu opravdu rad

dekuji

S pozdravem
    Petr Bartel

[Reklama]

[ET]

Zdar,
nekolik rad:

* ucetnictvi Premier neznam, ale nejdriv bych proveril, jestli je to opravdu sambou - jestli treba neni problem ve foxce [ktera uz ma IMHO pravdepodobne odzvoneno] - jednoduchym kopirovanim souboru za provozu - jinejch nez *.dbf !!! dek si tam treba naky iso bokem

* problem v sambe by se dal vyloucit nakopirovanim fox databaze [*.dbf...] nekam na local disk, kde normalne hrajou ucetnictvi - pokud to bude pomaly i na localnim pc, problem je ve foxce

* problem ve foxce vyloucis prechodem na ucto s lepsim backendem :] joke - foxka nezvalda hodne paralelnich pristupu - zalezi kolik lidi se na ty fajle sape

good luck a podel se jestli a jak se to ne/povedlo...

[James_Scott]

Se zrychlenim samotne samby moc nepomuzu, ale rekl bych ze v tom bude hrat roli i souborovy system. Treba by to chtelo Filesystem,ktery je zamereny na velke mnozstvi malych souboru,nebo si ten stavajici alespon upravit.

[Petr Bartel]

koukam, ze dle odpovedi jsem pozapomel nektere veci

- na lokalnim pc ci na vzdalenych windows program funguje naprosto normalne a rychle
- filesystem je XFS
- kopirovani ze/na samby je pomerne rychle

osobne vidim problem nekde v tom zamykani, at uz na linuxu/sambe nebo windows

v logu obcas hlasky typu

[2010/06/21 06:48:29,  0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected

ovsem jen na nekterych pocitacich (bohuzel ted nejsem schopen zjistit co verzi windows tam bezi, ale neco >= XP

[x]

Tady mas pocteni na dlouhe vecery - Samba performance tuning

http://oreilly.com/catalog/samba/chapter/book/appb.pdf

[Reklama]

[Fantomas]

Pouzivam reiserfs na smb serverech a bezi to jak vitr. Nicmene zkus vzit nekde treba tisic fotek, nakopcit na server a pak ze serveru a napis sem rychlost. Foxka je prasarna, nicmene pokud otevira soubor najednou par uzivatelu, tak to celkem jde prezit. Mozna taky muze byt prehlcena sit a nastavaji velke prodlevy nebo muze blbnout sitovka. A prover rychlost disku pres hdparm.

[ET]

- kopirovani ze/na samby je pomerne rychle
- pokud nejmensi prenosova rychlost mezi sambou a klientem je 100Mb - videl bych "normalni" rychlost nekde kolem 7-10MB/s pri kopirovani - pokud to svisti priblizne touhle rychlosti pri zatezi, vyloucil bych z toho sambu/fs/sit a zacal bych nekde tady http://msdn.microsoft.com/en-us/library/0b2ab467%28VS.71%29.aspx

[Petr Bartel]

co se tyce hdparmu

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   2220 MB in  2.00 seconds = 1110.37 MB/sec
 Timing buffered disk reads:  218 MB in  3.00 seconds =  72.58 MB/sec

tam problem nevidim

sitovka je

Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express

ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes

koukam musim vypnout autovyjednavani a zjistit jestli ma switch gigovej port, ovsem to neresi ze pres stejnej switch to na woknech jede normalne

[ET]

jestli myslis ze to je siti, zcheckuj vsude po ceste ze nikde neni half-duplex..

[Neuro]

Kuk,
  mám stejný problém ale s ÚČTO2010. V HW bych chybu nehledal, zkusil jsem na svém serveru (hodně výkonná mašina) rozjet KVM s win7 (tj. síťovka v bridge pro tu virtuálku a v ní i eth1 pro CentOS pod kterým to vše běží), tam nasdílet adresář s ÚČTO a to šlape naprosto v pohodě (některé náročnější úkony v účtu až 15x rychlejší než když ze stanice přistupuji k účtu na sambě). Ještě zvažuji nahodit v tom KVM virtuálku CentOS a nahodit sambu tam. Když jsem se probíral různým nastavením samby atd. a všude četl o zlepšení v rámci procent, tak v tom logicky zakopaný pes nebude.

Mimochodem, Premiér tu nějaký čas fungoval také a u toho jsem to vzdal, na té samé mašině pak běžely WinXP a naprosto v pohodě. Teď se mi to vzdát nechce, tak budu laborovat dál ale je to občas za trest se sambou

Neuro

[brk]

Kolega aktuálně u jednoho zákazníka řeší takřka identický problém, akorát že to tam to mají nasdílené na servříku s Windows. Možná to teď "v rámci optimalizace" opravdu tak funguje.

Co to zkusit nasdílet někde přes okna, jestli se to změní, ať nehledáš problém tam, kde není.

[janforman]

tak to jsem kdysi taky řešil (je to velmi dávno) problém je v zamykání souborů,
FoxPro nejlépe běželo pod Novell Netware o něco hůře pod Windows a pod Sambou
velký problém.
Aktivováním kompatibilních zámků s Windows se dal běh velmi dobře zrychlit,
bohužel ale docházelo k občasnému poškozování dat...
Zámky si pak řešily stanice mezi sebou. Poznáte to snadno, jeden klient funguje naprosto bezchybně.
Jakmile jich je víc trpně čekají až se uvolní zámek. Koukněte do oplock dokumentace v sambě,
ale opravdu doporučuju zazálohovat data.

[elf]

zdravim vsechny,

Chci reagovat na posledni prispevek od janforman. Mohu se te zeptat na podrobnejsi info ohledne zamykani souboru?

Nemam s tim prakticky zadne zkusenosti, orientuji se spise na Windy. Mam v praci ovsem jeden server, kde mi puvodne bezel LINUX Debian v4.0, ale reinstaloval jsem na openSUSE v11.3 "Teal". Mam zde nejake shary, kde mi bezi ucetnictvi unisw a pristupuje na nej prostrednictvim samby nekolik uzivatelu. Na stare verzi Linuxu a Samby vse bezelo OK, ale s novou verzi mam jiste problemy. Zjistil jsem, ze adresar, ktery ma zustat prazdny, neni prazdny a visi tam nejaky jeden soubor. Proto unisw zahlasi chybu. Ten ovsem muzu smazat pres "mc" jen jako "root" kdyz se prihlasim pres putty. Mozna mi chybi s "sharu" nastavit nejaky paramet ohledne zamku nebo pristupu, ale nevim presne co.

Pokud s tim mate nekdo zkusenosti poradte prosim.

Dekuji za jakouli pomoc.