24. marts 2004 - 22:34Der er
20 kommentarer og 1 løsning
Netværk kager (Linux clienter/NFS)
Nu har jeg prøvet at rode og læse med alt jeg har kunnet finde på nettet omkring netværk/NFS, men jeg er ikke blevet klogere.
Jeg har et lokalnetværk bestående af 3 linux maskiner og en windows maskine, som er forbundet til en 100mbit hub (mener jeg, kan være switch), det er en D-link dfe 908, som er forbundet til et Zyxel modem fra cybercity (adsl).
Problemet er at når jeg overfører filer over NFS så hænger hele netværket, både localnetværket og det eksterne, altså clienterne bliver smidt af MSN og IRC og browse websites tager en krig, hvis de da ikke bare timer ud med det samme.
Hvis jeg f.eks åbner en fil med en tekst editor til et mountet NFS share, så hænger editoren når jeg prøver at gemme og jeg er nødt til at dræbe den.
Jeg har læst en masse med Duplex og har således prøvet at sætte alle clienterne til FULL og HALF duplex uden held. Og jeg har prøvet 2 andre hubs + forskellige netkort i maskinerne, samme problem.
Enviderende kan jeg se i "ifconfig" på maskinerne at der er rigtig mange collissons, og på 2 af af clienterne viser den også mange TX errors.
Spørgsmålet er så, hvordan får jeg fixet mit netværk, så jeg kan overføre filer localt uden at alting hænger ?
Der skal lige siges at det har virkert stråelende på et tidspunkt, på samme hardware (dog ikke med Zyxel modemet), kan det være modemet der gør et eller andet ?
Alle råd modtages varmt, for jeg er ved at få grå hår. =)
Large values of rsize and wsize may inhibit performance when using UDP. UDP datagrams must be separated into fragments that fit within your network's Maximum Transfer Unit. The loss of any of these fragments requires retransmission of the whole datagram. This may have a particularly adverse impact on client performance if your network is congested. TCP is considerably better at recovering one or two lost segments and managing network congestion, so larger I/O operations are usually more effective at reliably boosting performance when using NFS over TCP.
Men ellers.. Kan du finde nogle clues i /var/log måske?
Hvordan finder jeg ud af om jeg kører NFS over UDP eller TCP? .. Sad lige og tænkte på om mine NFS servere måske er konfigureret forskelligt med hensyn til TCP/UDP, hmmm.
Jeg har skimmet alle de logs jeg har, det eneste relevante har været NFS timeout og noget med reset. Men det ik sket i den senere tid. Og da jeg rodede med et andet netkort, så tvang den kortet til at køre med HALF duplex stod der.
Er meget på bar bund hvad jeg ellers skulle kigge efter og jeg synes Gentoo er meget sparsom med log oplysninger.
Men tak for oplysningen, jeg tror jeg vil prøve det der rsize og wsize, har set det flere steder, men jeg var næsten sikker på det var en netværks fejl og ikke NFS i sig selv da det har virket før på samme opsætning.
In summary, "timeo=600,retrans=2" is appropriate for TCP mounts. When using NFS over UDP, "timeo=4,retrans=5" is a better choice. Using "timeo=600" with NFS over UDP will result in very poor performance in the event of network or server problems. Using a very short timeout with TCP could cause network congestion or, in rare cases, data corruption.
Jeg ved ikke hvor du finder de her conf filer. Prøv quick and dirty metoden og grep efter det i alt der ligger i /etc =) Du bruger vel forresten ikke gentoo kernel til det her? Det er nok bedst med vanilla sources, og så vær opmærksom på at kernel sagtens kan have bugs i forbindelse med NFS. Især hvis du har kastet dig ud i at bruge den seneste version af NFS... Hvilken version bruger du egentlig?
Jeg bruger vanilla sources på alle mine 3 maskiner, den ene kører Gentoo (vanilla 2.6.4) og de andre 2 kører debian unstable (vanilla 2.6.3).
I ebuilden på Gentoo maskinen står der:
<snip> einfo "NFS V2 and V3 servers now default to \"sync\" IO if ${P}" einfo "(or later) is installed." einfo "More info at ${HOMEPAGE} (see questions 5, 12, 13, and 14)." echo ewarn "PLEASE note: Since the latest NFS utils has changed the server" ewarn "default to \"sync\" IO, then if no behavior is specified in the" ewarn "export list, thus assuming the default behavior, a warning will" ewarn "be generated at export time." echo </snip>
Det må man gå ud fra er NFS 3 ? ..
Men hvis jeg laver en:
/usr/sbin/rpc.nfsd --version
på Debian maskinerne, så får jeg:
Universal NFS Server 2.2beta47
Måske det har en betydning?
Hvis det du skrev er default, så vil det sige det kører over UDP nu, skal jeg så prøve at mounte mine shares over TCP og forhøje rsize og wsize + timeo=600,retrans=2 ?
NFS skal jo compiles ind i kernel. Den er under "filesystems" i xconfig. Du kan selvfølgelig bare compile support ind for NFS 1, 2 og 3 uden problemer og så vælge hvilken du vil bruge med userspace utils (mount). Jeg tror indtil videre at du skal søge at bruge NFS2. Mener at implementeringen af v3 stadig har status af eksperimentel. Det havde den i hvert fald sidste gang jeg kiggede.
Du kan jo prøve dig frem med de der options. Det kan selvfølgelig både bliver værre og bedre, men værd at prøve hvis du har tålmodigheden. Noget som
ah ja, hvis v3 ikke er experimental længere så er der 99.9% chance for at den virker og ikke mindst at implementeringen er komplet nu. Så prøv i hvert fald at få følgende ind:
Provide NFSv3 Support Provide NFSv3 Server support Provide NFS Server over TCP support (experimental)
Den der med allow direct I/O er jeg lidt uklar på. Lyder ikke som noget du har brug for.
Nu har jeg compilet NFS3 med TCP på alle computerne, men jeg har problemer med min gentoo, den ville lade mig mounte med vers=3, jeg har prøvet at recompile nfs-utils og den pakke der indeholder mount, men alt jeg få er:
mount: RPC: Program/version mismatch; low version = 1, high version = 2
Den anden maskine ser fin ud, jeg har ingen ide om hvad det betyder, måske noget med driveren? Måske er det en del af problemet?
Jeg prøver lige at opdatere til 2.6.4 på begge debian maskinerne og compiler driveren som module (på den med fejl) og ser om det hjælper, vender tilbage så snart jeg har fået det oppe at køre og får testet filoverførselen. =)
Frames er det der ligger dybere end TCP/IP pakker. Før noget bliver sendt ud gennem kablet bliver det wrappet i en frame. Grunden er de forskellige medie typer man benytter til TCP/IP traffik. En IP pakke kan ikke bare sendes råt ud på et ethernet, så derfor laves de om til ethernet frames. På samme måde er der token ring frames, wlan frames osv. Frames er linket mellem det fysiske netværk og TCP/IP, og deres form afhænger af det fysiske netværks type. Kernel og device driver er de ting der omsætter en pakke til en frame før de bliver sendt ud. Som du nok kan forstå kan en fejl her betyde alverden for effektiviteten af dit netværk. Fejlen har ikke direkte noget med NFS at gøre. Hvis nogle etherframes der er for store virkelig er fejlen så vil overførsel af store filer med ftp og http og alt andet medføre de samme fejl på netværk. Det synes jeg lyder meget sandsynligt. Frame fejl forekommer ikke særlig ofte, så derfor var det godt nok ikke den første ting jeg tænkte på her, men du skal i hvert fald af med dem. Skal være ærlig og sige at jeg ikke lige ved på stående fod om man kan sætte frame størrelse i forbindelsen med modprobe/insmod. Måske er der hjælp at hente med mii tool..
Hm, jeg kan ikke huske om problemet var sådan inden jeg satte den maskine til, men jeg har også prøvet andre netkort i den, så er ik sikker på om det er problemet.
Var det en ide at pille den fra netværket og prøve at overføre? Eller måske prøve at pille alle af på skift og se om der måske er en kombination der virker også indskrenke fejlen til en maskine?
Dog bliver det med NFS v2 pga af Gentoo maskinen :/
mii tool er et util til at justere ting der ligger dybere end tcp/ip. Feks kan man skifte et netkort fra 100mbit til 10mbit med det og skifte duplex. Det er meget muligt at det kan ændre frame størrelser også. Det ville være praktisk hvis du kunne isolere problemet til een maskine ja. Måske også prøve at overføre en stor fil med noget andet end NFS.
Gentoo -> Debian1 nfs - hænger Gentoo -> Debian2 nfs - hænger Debian1 -> Debian2 nfs - hænger Gentoo -> Debian1 ftp - hænger Gentoo -> Debian2 ftp - Den ser ik umiddelbart ud til at hænge der, hm ?
Debian2 er den maskine med Oversized Ethernet frame, den viser stadig tonsvis af dem, ligeså snart jeg starter en overførsel.
Iøvrigt har begge debian maskinerne tonsvis af collisions og errors i ifconfig hvorimod min gentoo kun har collisons.
Kan det tænkes at alle mine netkort (foruden det der sidder i min Gentoo) har en fejl af en eller anden art? Det er gamle netkort, men synes stadig det virker underligt.
Måske skulle jeg prøve at gå ud og købe 2 nye VEL supportede kort, og se om det stadig giver problemer og måske nogen nye netkabler? .. iallefald et af mine kabler er "godt brugt".
Jeg er desværre ikke overbevist om at det hjælper =(
Jeg tror dog at du kan ignorere collisions. De sker simpelthen fordi du bruger en hub frem for en switch. Måske kan det i det hele taget hjælpe hvis du anskaffer en switch..
Overførsel mellem gentoo og debian2 med ftp giver stadig ikke problemer?
Jeg har lige kørt en række tests, med ftp fra Gentoo og Debian2 og den hænger, bare ik på samme måde, det er som om den hænger i ryk istedet for en laaaang hæng. Jeg tester det ved at pinge et externt site og reloaede websites.
Men jeg bliver dog ik smidt af MSN/IRC som jeg gør ved alt andet, meget mystiskt.
Grunden til jeg ville prøve nye (og vel supportede) netkort, er at det kort der sider i Debian2 nu viser de der frame fejl, det der sidder i Debian1 kan ikke genkendes af mii-tool og jeg har lige (igen) prøvet 2 andre netkort i Debian1, det ene gav eth0 reset og timeout konstakt, og hvis jeg prøver at overføre filer med det, så dør maskinen simpelthen, og det andet kort kunne jeg ik engang få maskinen på netværket, selv om ifconfig viser den har fået ip osv. Den kan ikke pinges og jeg kan ikke få kontakt til omverden.
Netkort koster jo ingen ting idag, så måske prøve som en udelukkelses metode?
Jeg fik at vide af nogen guruer i #Gentoo kanalen på irc.freenode.net for noget tid siden at collisions skyldes at alle kort/hub ik kører med samme duplex, men de kan jo tage fejl =)
Ellers er jeg helt ude at ideer om hvad det kan være :/
Nu siger du at det måske hjælper med en switch, men jeg har jo overført gigabytes af data på hub før, imellem 2 af maskinerne (Gentoo og Debian1) uden problemer. Jeg har haft sat den hub til flere gange (i senere tid), med samme resultat dog.
Hvis jeg bare kunne huske hvad (og hvornår) jeg har ændret siden det holdte op med at virke :<
hmm.. der findes jo selvfølgelig nogle netkorts chipset derude som bare er 100% skod. Jeg har selv haft kæmpeproblemer med et der havde et National Semiconductors (natsemi) chipset på. Der er iøvrigt i kernel config et eller andet "natsemi workaround" man kan vælge, og som du også bør vælge hvis dine netkort er natsemi baserede. Sagen er at jeg benyttede det workaround, men det virkede stadig ikke. Blev nødt til at bruge kernel workaround + mii tool, fordi kortet hele tiden stod og skiftede umotiveret mellem 10 og 100mbit.
Konklusion: NatSemi = lort
Men til gengæld virker mine 3com kort upåklageligt i Linux. Du kan kigge i kernel config hvilke modeller der er direkte support for. Hvis du ikke kan få mii tool til at virke er det en meget god grund til at skifte. Når man har servere til at køre skal de helst have låst hastighed og duplex fast med mii tool. Ellers forsøger de selv at finde ud af hvad hastighed de skal køre.. og det er ufedt hvis ens server pludselig opfører sig underligt tilsyneladende uden grund og man flere timer senere finder ud af at det er fordi netkortet pludselig gik ned på 10 mbit. I enhver installation hvor oppetid tæller skal de faktisk låses.
Så får jeg lige fat i 2x3Com kort i næste uge, det er også 3com jeg har i min desktop.
Du har under alle omstændigheder gjort dig velfortjent til 100 points ;)
Men tak for hjælpen for nu, vender sikkert tilbage med et nyt spørgsmål hvis det ik hjælper med nye netkort, jeg vil også forsøge at låne en switch et sted, for at udelukke det også.
=)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
