Het computernetwerk vertraagt ​​wat te doen. Grote problemen van kleine netwerken, of Waarom vertraagt ​​mijn netwerk? Kort over de standaarden van lokale computernetwerken

/ Grote problemen van kleine netwerken, of Waarom vertraagt ​​mijn netwerk?

Grote problemen van kleine netwerken, of Waarom vertraagt ​​mijn netwerk?

Dat kan met zekerheid gesteld worden computer netwerk vandaag - een van de belangrijkste componenten van elk succesvol bedrijf. De computer is allang van een luxe tot een onmisbaar stuk gereedschap geworden. Maar tegelijkertijd, verrassend genoeg, besteden de meeste bedrijven minimale aandacht aan de kwaliteit van het aanleggen van computernetwerken. Ondernemers geloven dat de prestaties van computersystemen afhangen van de kracht van computers en geven graag geld uit aan dure en snelle modellen, waarbij ze vergeten dat de manier van interactie tussen deze computers niet minder belangrijk is. De bouwkwaliteit van computers begon een belangrijke rol te spelen. Consumenten nemen geen genoegen meer met goedkope modellen die "in de achterkamer op hun knieën" in elkaar zijn gezet, ze kopen liever duurdere computers van bekende merken. Des te verrassender is het dat de uitrol van een lokaal netwerk nog vaak wordt geassocieerd met iets frivools, apenwerk dat elke student met een tool kan doen. Als gevolg hiervan is hij bezig met het leggen van het netwerk. Zolang er slechts 5-10 computers in het netwerk zijn, zijn de nadelen van deze aanpak meestal onzichtbaar, maar zodra het begint te groeien, verschijnen er servers, netwerkdiensten, databases in - dus de schijnbare besparingen blijken meteen te zijn een tijdbom zijn. Netwerkvertragingen en -bevriezingen beginnen, snelle computers blijken nutteloze hardware te zijn, omdat het netwerk niet in staat is om snel de benodigde hoeveelheden informatie over te dragen, wordt het onmogelijk om de tijd op computers te synchroniseren. In alle gevallen blijkt dat storingen en downtime door netwerkstoringen veel duurder zijn dan een kwaliteitsinstallatie. Waarom gebeurt dit en hoe ermee om te gaan?

Kort over de standaarden van lokale computernetwerken

Ontwerp, installatie en bediening van gestructureerde bekabelingssystemen (SCS) zijn al meer dan 15 jaar gestandaardiseerd. Er zijn Amerikaanse (ANSI/TIA/EIA), Europese (EN) en internationale (ISO/IEC) normgroepen. Een lokaal netwerk gebouwd volgens de ISO-standaard verhoogt de waarde van het bedrijf, dus veel grote ondernemingen bouwen hun netwerken in eerste instantie volgens de standaard, of upgraden bestaande netwerken en ontvangen een conformiteitscertificaat - dit is een belangrijke hulp bij het vinden van investeerders. Kleine bedrijven hoeven hun netwerken niet te certificeren, maar in ieder geval moet de implementatie van een lokaal netwerk worden toevertrouwd aan specialisten die bekend zijn met de normen en regels voor het installeren van netwerken - dit zal de betrouwbaarheid aanzienlijk vergroten.

Een beetje over het apparaat van een computernetwerk

De meeste moderne lokale netwerken zijn gebaseerd op Ethernet-technologie (niet verwarren met internet!). In het meest voorkomende geval is het netwerk een set netwerkhubs (ook wel "hub" en "switch" genoemd) - apparaten die kabels van computers in één knooppunt verbinden - en de kabels zelf. Netwerkhubs verschillen in het aantal netwerkconnectoren (poorten), gegevensoverdrachtsnelheden en de mogelijkheid om netwerkverkeer te beheren. Een Ethernet-kabel bestaat uit acht koperen geleiders in één mantel, in paren geweven tot 4 paren. Elk uiteinde van de kabel is ofwel in een stekker (connector) gekrompen of mechanisch bevestigd aan een apparaat met netwerkconnectoren (socket of patchpaneel). Om computers op een Ethernet-netwerk te laten werken, zijn ze uitgerust met netwerkkaarten - een apparaat met een connector voor het aansluiten van een netwerkkabel. De basissnelheid van netwerkgegevens is afhankelijk van netwerkhubs en netwerkkaarten van computers en is 100 Mbps voor 100BaseT-netwerken en 1000 Mbps voor Gigabit Ethernet-netwerken

8 typische netwerkfouten, of waarom 1C langzamer gaat via het netwerk

Dus er zijn krachtige moderne computers gekocht en geïnstalleerd, het lokale netwerk is samengesteld, internet is aangesloten en u kunt werken. En plotseling verschijnen er ergens veel kleine (en soms helemaal niet kleine) problemen: ofwel reageert de server op het netwerk niet meer, dan klagen accountants dat 1C vreselijk traag is, dan verdwijnt het internet, dan zien computers over het algemeen de netwerk. Wat is er gebeurd? Waarschijnlijk zijn er fouten gemaakt tijdens de installatie van het netwerk, waardoor zowel de snelheid als de betrouwbaarheid van de gegevensoverdracht eronder leden. De meest typische daarvan worden hieronder beschreven. Controleer uw netwerk voor een van deze lijst.

  1. De LAN-kabel wordt samen met de elektriciteitskabel gelegd.

    Om kabelkanalen te besparen, worden LAN-kabels soms op elkaar gestapeld met elektriciteitskabels (erger nog - als ze aan elkaar zijn geweven of vastgemaakt). Het elektromagnetische veld rond de elektrische kabel veroorzaakt ruis in de LAN-kabel, het aantal fouten neemt toe en de gegevensoverdrachtsnelheid daalt. In het ergste geval kan netwerkapparatuur uitvallen - een netwerkhub of een netwerkkaart in een computer zal doorbranden.

  2. Eén kabel voor twee stopcontacten.

    Zoals hierboven vermeld, bestaat een twisted-pair kabel uit acht aders die in paren zijn geweven. In gigabit-netwerken (1000 megabit) worden gegevens over alle vier paren verzonden en in netwerken van 100 megabit slechts over twee. Dit wordt een vruchtbare voedingsbodem voor de "briljante" ideeën van sommige specialisten van eigen bodem: waarom in een 100-megabit netwerk twee kabels naar twee stopcontacten trekken als je twee paar voor één en twee voor een ander stopcontact kunt gebruiken? En om geld te besparen, worden kabels genadeloos versnipperd: gedraaide paren worden uit de mantel gehaald, losgedraaid, omwikkeld met isolatietape, enz. Deze manipulaties schenden het belangrijkste principe van het bouwen van informatienetwerken: één apparaat - één kabel. U kunt in geen geval besparen op een kabel - dit leidt altijd tot extra kosten. In dit geval verslechteren de golfkarakteristieken van de kabel, de hoeveelheid ruis in de verbinding neemt toe. Het aantal fouten neemt toe, de werkelijke gegevensoverdrachtsnelheid neemt af. Bovendien wordt het onmogelijk om deze kabel later te gebruiken om te upgraden naar een snellere Gigabit Ethernet-standaard.

  3. Computer- en telefoonnetwerken in één kabel.

    Een flagrant geval van overtreding van de regels voor het aanleggen van kabelnetwerken. Helaas zeer wijdverspreid. "Specialisten" van eigen bodem gebruiken twee van de vier paren om een ​​computernetwerk te organiseren, en via de andere twee verbinden ze telefoons. Aan de gevolgen beschreven in paragraaf 3 worden pickups toegevoegd van "telefoon" -paren, waarvan de nominale spanning 60 V bereikt, en op het moment van de oproep - tot 120 V (in "computer" -paren - tot 5 V). Het effect van interferentie is vooral merkbaar bij lange kabels. Vervorming veroorzaakt door ruis en interferentie zorgt ervoor dat een 100 Mbps-netwerk gegevens verzendt met een snelheid van 10 Mbps. Houd er rekening mee dat de netwerksnelheid die door Windows wordt weergegeven op het moment van verbinding, de standaardsnelheid van de netwerkverbinding is en niet de daadwerkelijke gegevensoverdrachtsnelheid. De exacte waarde kan worden achterhaald met behulp van speciale programma's, bijvoorbeeld SiSoft Sandra. U kunt zelf een grove schatting maken met behulp van Windows Verkenner, door te meten hoe lang het duurt om een ​​groot bestand (meer dan 500 MB) over het netwerk te versturen.

  4. Uitbreiding van de lokale netwerklijn met extra stopcontacten.

    Bij het trekken blijkt dat ze de lengte van de kabel verkeerd berekend hebben, en enkele tientallen centimeters niet genoeg zijn om op de juiste plek te komen. Verschuift hierdoor niet de hele kabel? En de "specialist" vindt een uitweg - hij monteert een stopcontact aan het uiteinde van de kabel, waarop hij een andere kabel aansluit, aan het uiteinde waarvan ook een stopcontact is gemonteerd. Als de computer dan verder wordt verplaatst, dan wordt op dezelfde manier een nieuw stuk kabel met een socket aan de lijn toegevoegd ... De slechtste optie is wanneer de kabel zonder sockets wordt verlengd, de geleiders handmatig worden gesplitst met een soldeerbout of wendingen, wat volkomen onaanvaardbaar is. Houd er rekening mee dat kabelconnectoren de belangrijkste storingsbron zijn, hun aantal op één regel mag niet meer dan vier zijn.

  5. Slecht gekrompen connectoren.

    Een veel voorkomende fout. De Ethernet-connector is zo ontworpen dat niet alleen koperen geleiders, maar ook isolatie veilig worden bevestigd. Getwiste paren mogen niet meer dan 1 cm worden losgedraaid Helaas kan men vaak zien hoe deze vereisten worden genegeerd, de isolatie veel meer wordt afgesneden dan nodig is en de niet-getwiste getwiste paren worden gekrompen door de connector. Zo'n kabel heeft aanzienlijk slechtere golfkarakteristieken en onzorgvuldige mechanische impact kan een breuk in de geleider veroorzaken.

  6. Kabels liggen op de grond.

    U kunt er zeker van zijn dat elke netwerkkabel die op de grond in het gangpad ligt, minstens één keer wordt getrokken. Als er in uw kantoor computernetwerkkabels op de grond liggen (erger nog - aan de andere kant van het gangpad), dan zal vroeg of laat iemand ze te pakken krijgen. Dit betekent in ieder geval een kabel die uit de netwerkkaart is gesprongen, maar er kan ook een kabelbreuk optreden, gevolgd door het uitvallen van de netwerkhub. Indien mogelijk moeten alle LAN-kabels, behalve de kabels van het stopcontact naar de computer, in voorbereide kanalen worden gelegd: ribbelbuizen, plastic dozen, goten achter wand- of plafondpanelen. Als het onmogelijk is om de kabel uit de doorgang te verwijderen, moet deze in ieder geval worden afgedekt met een metalen of plastic beschermhoes.

  7. Kabels in de buurt van tl-lampen.

    Een veel voorkomende optie voor het leggen van netwerkkabels achter een verlaagd plafond is snel, netjes en goedkoop. Het is echter niet voldoende om de kabels achter de plafondpanelen te verbergen, er moet rekening mee worden gehouden dat fluorescentielampen de sterkste bronnen van elektromagnetische interferentie zijn. Kabels moeten zo ver mogelijk uit de buurt van TL-armaturen worden geleid, bij voorkeur in geaarde draadgoten die aan het plafond zijn bevestigd. Helaas wordt dit principe op grote schaal geschonden. Kabels achter het plafond liggen lukraak, vaak direct op de armaturen. Een grote hoeveelheid ruis en een afname van de netwerksnelheid zijn gegarandeerd.

  8. Een groot aantal netwerkknooppunten.

    De lengte van één lijn van een Ethernet-netwerk gebouwd op twisted-pair kabels is niet langer dan 100 meter. Wanneer het nodig is om de netwerklijn over een aanzienlijke afstand uit te rekken, zou de optimale oplossing zijn om glasvezelkabel te gebruiken, maar dit verhoogt de installatiekosten aanzienlijk, dus systeembeheerders gebruiken verschillende trucs. Zo leggen ze een lijn in stukken van 100 meter, waartussen ze de zgn. repeaters (signaalversterkers). Meestal worden gewone, goedkoopste netwerkhubs gebruikt als repeaters. In de regel verbinden ze op deze manier afzonderlijke gebouwen waarin al lokale netwerken zijn aangelegd en er netwerkknooppunten zijn. De bouwregels vereisen dat er niet meer dan 4 hubs tussen twee computers zijn, maar met deze benadering van netwerkuitbreiding zijn ze heel gemakkelijk te doorbreken, wat gepaard gaat met vertragingen en storingen. De volgende veelgemaakte fout is het installeren van een groot aantal netwerkhubs met een klein aantal poorten. Vroeg of laat ontstaat er een situatie waarin vrije poorten in de hub opraken en er nergens nieuwe computers kunnen worden aangesloten. De goedkoopste en snelste manier om de situatie te verhelpen, is door nog een kleine hub te kopen en deze op de oude aan te sluiten. Deze methode is ook het meest verkeerd. Bedenk wel dat één hub met een groot aantal poorten altijd beter werkt dan meerdere kleine. Een andere fout treedt op bij het leggen van een netwerk in verschillende aangrenzende kamers, die elk hun eigen netwerkhub hebben. De beste oplossing voor dergelijke gevallen is om elke hub rechtstreeks op de hoofdhub van het netwerk aan te sluiten, maar systeembeheerders die de hoeveelheid bekabeling willen verminderen, schakelen de hubs naar elkaar toe en zetten ze in een ketting op een rij. Als daarnaast wordt gekozen voor de goedkoopste hubmodellen, die een aanzienlijke hoeveelheid verkeer niet aankunnen, is netwerkvertraging bijna onvermijdelijk.

Hoe het netwerk te repareren en 1C te versnellen

Als een vluchtige inspectie van uw netwerk aantoont dat het ten minste enkele van de genoemde typische fouten bevat, moet u erover nadenken om het netwerk op orde te brengen. In de meeste gevallen kan een gekwalificeerde specialist de situatie corrigeren of oplossingen voorstellen. Maar de meest effectieve en juiste oplossing zal altijd zijn om het werk toe te vertrouwen aan specialisten, zorgvuldig een computernetwerk te ontwerpen voordat het wordt geïmplementeerd en de installatieregels te volgen.

Het doorvoeren van innovaties in de netwerkinfrastructuur is winstgevend. De kosten van een "juist" kabelsysteem bedragen zelden meer dan 5% van de kosten van het gehele computernetwerk, en besparingen op dit gebied kunnen leiden tot ernstige verliezen door storingen en downtime.

Alex Cemic,

partner voor netwerkbeveiliging en serverinfrastructuur

De laatste tijd klagen gebruikers en beheerders steeds vaker dat nieuwe 1C-configuraties die worden ontwikkeld op basis van een beheerde applicatie traag zijn, in sommige gevallen onaanvaardbaar traag. Het is duidelijk dat nieuwe configuraties nieuwe functies en mogelijkheden bevatten en daarom meer middelen vergen, maar de meeste gebruikers hebben geen idee wat de belangrijkste invloed heeft op de werking van 1C in bestandsmodus. Laten we proberen deze kloof te dichten.

In de onze hebben we het al gehad over de impact van de prestaties van het schijfsubsysteem op de snelheid van 1C, maar deze studie had betrekking op het lokale gebruik van de applicatie op een aparte pc of terminalserver. Tegelijkertijd gaat het bij de meeste kleine implementaties om het werken met een bestandsbasis via een netwerk, waarbij een van de pc's van de gebruiker als server wordt gebruikt, of een speciale bestandsserver op basis van een gewone, meestal ook goedkope computer.

Een kleine studie van Russisch-talige bronnen op 1C toonde aan dat dit probleem ijverig wordt omzeild; in geval van problemen wordt meestal geadviseerd om over te schakelen naar client-server- of terminalmodus. En het is ook bijna algemeen geaccepteerd dat configuraties op een beheerde applicatie veel langzamer werken dan normaal. In de regel krijgen argumenten "ijzer": "hier is Accounting 2.0 net gevlogen, en de" trojka "beweegt natuurlijk nauwelijks, er zit enige waarheid in deze woorden, dus laten we proberen het uit te zoeken.

Grondstoffenverbruik in één oogopslag

Voordat we aan dit onderzoek begonnen, hadden we onszelf twee doelen gesteld: uitzoeken of beheerde, op applicaties gebaseerde configuraties daadwerkelijk langzamer zijn dan conventionele configuraties, en welke bronnen de grootste impact hebben op de prestaties.

Voor het testen hebben we twee virtuele machines genomen met respectievelijk Windows Server 2012 R2 en Windows 8.1, met 2 kernen van de host Core i5-4670 en 2 GB RAM, wat overeenkomt met een gemiddelde kantoormachine. De server werd op een RAID 0-array van twee geplaatst en de client op een vergelijkbare array van schijven voor algemeen gebruik.

Als experimentele basis hebben we gekozen voor verschillende configuraties van Accounting 2.0, release 2.0.64.12 , die vervolgens werd bijgewerkt naar 3.0.38.52 , werden alle configuraties op het platform uitgevoerd 8.3.5.1443 .

Het eerste dat de aandacht trekt, is de toegenomen omvang van de informatiebasis van de trojka, en deze is aanzienlijk gegroeid, evenals de veel grotere honger naar RAM:

We zijn al klaar om het gebruikelijke te horen: "wat hebben ze toegevoegd aan dit trio", maar laten we ons niet haasten. In tegenstelling tot gebruikers van client-serverversies, die een min of meer gekwalificeerde beheerder nodig hebben, denken gebruikers van bestandsversies zelden na over het onderhoud van de database. Ook denken werknemers van gespecialiseerde bedrijven die deze bases bedienen (lezen - updaten) er zelden over na.

Ondertussen is de 1C-informatiebank een volwaardig DBMS van zijn eigen formaat, dat ook onderhoud vereist, en hiervoor is er zelfs een tool genaamd Testen en repareren van de infobase. Misschien speelde de naam een ​​wrede grap, wat lijkt te impliceren dat dit een tool is voor het oplossen van problemen, maar slechte prestaties zijn ook een probleem, en herstructurering en herindexering, samen met tabelcompressie, zijn bekende tools voor database-optimalisatie voor elke RDBMS-beheerder. Laten we het controleren?

Na het toepassen van de geselecteerde acties, verloor de database dramatisch "gewicht", werd zelfs kleiner dan de "twee", die ook nog nooit door iemand is geoptimaliseerd, en het RAM-verbruik nam ook iets af.

Vervolgens, na het laden van nieuwe classificaties en mappen, het maken van indexen, etc. de grootte van de basis zal groeien, in het algemeen zijn de basissen van de "drie" groter dan de basissen van de "twee". Dit is echter niet belangrijker, als de tweede versie tevreden was met 150-200 MB RAM, dan heeft de nieuwe editie al een halve gigabyte nodig, en met deze waarde moet rekening worden gehouden bij het plannen van de benodigde bronnen om met het programma te werken .

Netto

Netwerkbandbreedte is een van de belangrijkste parameters voor netwerktoepassingen, vooral omdat 1C in bestandsmodus aanzienlijke hoeveelheden gegevens over het netwerk verplaatst. De meeste netwerken van kleine ondernemingen zijn gebouwd op basis van goedkope 100 Mbps-apparatuur, dus we zijn begonnen met testen door de prestatie-indicatoren van 1C in 100 Mbps- en 1 Gbps-netwerken te vergelijken.

Wat gebeurt er wanneer u de 1C-bestandsbasis via het netwerk start? De client downloadt een vrij grote hoeveelheid informatie in tijdelijke mappen, vooral als dit de eerste "koude" lancering is. Bij 100 Mbps lopen we naar verwachting tegen de bandbreedte aan en kan het downloaden behoorlijk lang duren, in ons geval zo'n 40 seconden (de prijs van de grafiekverdeling is 4 seconden).

De tweede start is sneller, omdat een deel van de gegevens in de cache wordt opgeslagen en daar blijft tot het opnieuw opstarten. De overgang naar een gigabit-netwerk kan het laden van het programma aanzienlijk versnellen, zowel "koud" als "heet", en de verhouding van waarden wordt waargenomen. Daarom hebben we besloten om het resultaat in relatieve termen uit te drukken, waarbij we de grootste waarde van elke meting als 100% nemen:

Zoals u in de grafieken kunt zien, laadt Accounting 2.0 twee keer zo snel bij elke netwerksnelheid, de overgang van 100 Mbps naar 1 Gbps stelt u in staat om de downloadtijd vier keer te versnellen. Er is geen verschil tussen de geoptimaliseerde en niet-geoptimaliseerde Troika-databases in deze modus.

We hebben ook de impact van de netwerksnelheid op de zware werking gecontroleerd, bijvoorbeeld tijdens herhosting van groepen. Het resultaat wordt ook uitgedrukt in relatieve termen:

Hier is het al interessanter, de geoptimaliseerde basis van de "trojka" in een 100 Mbit / s-netwerk werkt met dezelfde snelheid als de "twee", en de niet-geoptimaliseerde laat twee keer het slechtste resultaat zien. Op een gigabit blijven de verhoudingen behouden, de niet-geoptimaliseerde "drie" is ook twee keer zo traag als de "twee", en de geoptimaliseerde loopt een derde achter. Bovendien kunt u met de overgang naar 1 Gb / s de uitvoeringstijd met een factor drie verkorten voor versie 2.0 en twee keer voor versie 3.0.

Om de impact van netwerksnelheid op het dagelijkse werk te evalueren, gebruikten we prestatiemeting door een reeks vooraf gedefinieerde acties in elke database uit te voeren.

Eigenlijk is netwerkbandbreedte voor dagelijkse taken geen bottleneck, een niet-geoptimaliseerde "drie" is slechts 20% langzamer dan een twee, en na optimalisatie blijkt het ongeveer even snel te zijn - de voordelen van werken in de thin client-modus hebben invloed. De overgang naar 1 Gb / s geeft de geoptimaliseerde basis geen voordelen, en de niet-geoptimaliseerde basis en de deuce beginnen sneller te werken, wat een klein verschil tussen beide laat zien.

Uit de uitgevoerde tests blijkt dat het netwerk geen bottleneck is voor nieuwe configuraties en dat de beheerde applicatie nog sneller werkt dan normaal. U kunt ook aanbevelen om over te stappen op 1 Gb/s als zware taken en de laadsnelheid van databases van cruciaal belang voor u zijn. In andere gevallen stellen nieuwe configuraties u in staat effectief te werken, zelfs in langzame 100 Mb/s-netwerken.

Dus waarom vertraagt ​​​​1C? We zullen het verder onderzoeken.

Serverschijfsubsysteem en SSD

In het vorige artikel hebben we een verhoging van de 1C-prestaties bereikt door databases op SSD te plaatsen. Misschien zijn de prestaties van het serverschijfsubsysteem niet voldoende? We hebben de prestaties van een schijfserver gemeten tijdens een groepsrun in twee databases tegelijk en kregen een vrij optimistisch resultaat.

Ondanks het relatief hoge aantal invoer-/uitvoerbewerkingen per seconde (IOPS) - 913, was de wachtrijlengte niet groter dan 1,84, wat een zeer goed resultaat is voor een array met twee schijven. Op basis hiervan kunnen we aannemen dat een spiegel van gewone schijven voldoende zal zijn voor de normale werking van 8-10 netwerkclients in zware modi.

Dus is een SSD nodig op een server? Het beste antwoord op deze vraag helpt bij het testen, dat we hebben uitgevoerd met een vergelijkbare methodologie, de netwerkverbinding is overal 1 Gb / s, het resultaat wordt ook uitgedrukt in relatieve waarden.

Laten we beginnen met de laadsnelheid van de database.

Het lijkt misschien verrassend voor iemand, maar de SSD-basis op de server heeft geen invloed op de downloadsnelheid van de database. De belangrijkste beperkende factor hier, zoals blijkt uit de vorige test, is netwerkdoorvoer en clientprestaties.

Laten we verder gaan met opnieuw bedraden:

We hebben hierboven al opgemerkt dat de schijfprestaties voldoende zijn, zelfs voor intensief gebruik, dus de snelheid van de SSD wordt ook niet beïnvloed, behalve de niet-geoptimaliseerde basis, die de geoptimaliseerde op de SSD inhaalde. Eigenlijk bevestigt dit eens te meer dat optimalisatiebewerkingen informatie in de database organiseren, waardoor het aantal willekeurige I/O-bewerkingen wordt verminderd en de toegangssnelheid wordt verhoogd.

Bij dagelijkse taken is het beeld vergelijkbaar:

Alleen de niet-geoptimaliseerde basis profiteert van de SSD. Je kunt natuurlijk een SSD aanschaffen, maar het is veel beter om na te denken over het tijdige onderhoud van de bases. Vergeet ook niet de infobase-partitie op de server te defragmenteren.

Clientschijfsubsysteem en SSD

We analyseerden de invloed van SSD op de snelheid van lokaal geïnstalleerde 1C in , veel van wat is gezegd, geldt ook voor het werken in netwerkmodus. 1C gebruikt inderdaad vrij actief schijfbronnen, ook voor achtergrond- en geplande taken. In de onderstaande afbeelding kunt u zien hoe Accounting 3.0 gedurende ongeveer 40 seconden na het laden behoorlijk actief toegang heeft tot de schijf.

Maar tegelijkertijd moet men zich ervan bewust zijn dat voor een werkstation waar actief werk wordt uitgevoerd met een of twee informatiebanken, de prestatiebronnen van een conventionele HDD van een massaserie voldoende zijn. Het kopen van een SSD kan sommige processen versnellen, maar u zult geen radicale versnelling merken in het dagelijkse werk, omdat bijvoorbeeld het downloaden wordt beperkt door de netwerkbandbreedte.

Een trage harde schijf kan sommige bewerkingen vertragen, maar kan er op zichzelf niet voor zorgen dat een programma langzamer gaat werken.

RAM

Ondanks het feit dat RAM nu obsceen goedkoop is, blijven veel werkstations werken met de hoeveelheid geheugen die was geïnstalleerd toen ze werden gekocht. Hier liggen de eerste problemen op de loer. Op basis van het feit dat de gemiddelde "trojka" ongeveer 500 MB geheugen nodig heeft, kunnen we aannemen dat de totale hoeveelheid RAM van 1 GB om met het programma te werken niet voldoende zal zijn.

We hebben het systeemgeheugen teruggebracht tot 1 GB en twee infobases gelanceerd.

Op het eerste gezicht valt alles mee, het programma heeft zijn eetlust getemperd en volledig binnen het beschikbare geheugen gehouden, maar laten we niet vergeten dat de behoefte aan operationele gegevens niet is veranderd, dus waar zijn ze gebleven? Doorgespoeld naar schijf, cache, swap, etc., de essentie van deze operatie is dat gegevens die op dit moment niet nodig zijn, worden verzonden van snel RAM, waarvan de hoeveelheid niet voldoende is, naar een trage schijf.

Waar leidt het toe? Laten we eens kijken hoe de systeembronnen worden gebruikt bij zware bewerkingen, laten we bijvoorbeeld een groepsherhaling starten in twee databases tegelijk. Eerst op een systeem met 2 GB RAM:

Zoals u kunt zien, gebruikt het systeem actief het netwerk om gegevens te ontvangen en de processor om ze te verwerken, schijfactiviteit is onbeduidend, tijdens het verwerkingsproces groeit het af en toe, maar dit is geen beperkende factor.

Laten we nu het geheugen terugbrengen tot 1 GB:

De situatie verandert radicaal, de hoofdbelasting valt nu op de harde schijf, de processor en het netwerk zijn inactief, wachtend tot het systeem de benodigde gegevens van de schijf in het geheugen leest en daar onnodige gegevens naartoe stuurt.

Tegelijkertijd bleek zelfs subjectief werk met twee open databases op een systeem met 1 GB geheugen buitengewoon oncomfortabel, mappen en tijdschriften werden met een aanzienlijke vertraging geopend en actieve schijftoegang. Het openen van het tijdschrift Verkoop van goederen en diensten duurde bijvoorbeeld ongeveer 20 seconden en ging al die tijd gepaard met veel schijfactiviteit (gemarkeerd door een rode lijn).

Om de impact van RAM op de prestaties van configuraties op basis van een beheerde applicatie objectief te beoordelen, hebben we drie metingen uitgevoerd: de laadsnelheid van het eerste honk, de laadsnelheid van het tweede honk en groepsreposting in een van de hokken. Beide bases zijn volledig identiek en ontstaan ​​door het kopiëren van de geoptimaliseerde base. Het resultaat wordt uitgedrukt in relatieve eenheden.

Het resultaat spreekt voor zich, als de laadtijd met ongeveer een derde toeneemt, wat nog steeds redelijk draaglijk is, dan groeit de tijd voor het uitvoeren van bewerkingen in de database drie keer, het is niet nodig om onder dergelijke omstandigheden over comfortabel werk te praten. Dit is trouwens het geval wanneer het kopen van een SSD de situatie kan verbeteren, maar het is veel gemakkelijker (en goedkoper) om de oorzaak aan te pakken, niet de gevolgen, en gewoon de juiste hoeveelheid RAM te kopen.

Het ontbreken van RAM is de belangrijkste reden waarom het werken met nieuwe 1C-configuraties oncomfortabel is. Minimaal geschikte configuraties moeten worden overwogen met 2 GB geheugen aan boord. Houd er tegelijkertijd rekening mee dat in ons geval "broeikas"-omstandigheden zijn gecreëerd: een schoon systeem, alleen 1C en de taakbeheerder zijn gelanceerd. In het echte leven staan ​​op een werkende computer meestal een browser, een officepakket, een antivirusprogramma enz. van geheugen en drastische achteruitgang van de prestaties.

CPU

De centrale verwerkingseenheid kan zonder overdrijving het hart van de computer worden genoemd, aangezien hij het is die uiteindelijk alle berekeningen verwerkt. Om zijn rol te evalueren, hebben we nog een reeks tests uitgevoerd, dezelfde als voor RAM, waarbij we het aantal kernen dat beschikbaar is voor de virtuele machine terugbracht van twee naar één, terwijl de test twee keer werd uitgevoerd met geheugengroottes van 1 GB en 2 GB.

Het resultaat bleek behoorlijk interessant en onverwacht te zijn, een krachtigere processor nam behoorlijk effectief de last over bij gebrek aan middelen, anders zonder enige tastbare voordelen op te leveren. 1C Enterprise (in bestandsmodus) kan nauwelijks een applicatie worden genoemd die actief processorbronnen gebruikt, eerder niet veeleisend. En in moeilijke omstandigheden wordt de processor niet zozeer belast door het berekenen van de data van de applicatie zelf, maar door overheadkosten te dekken: extra I/O-bewerkingen, enz.

conclusies

Dus, waarom vertraagt ​​​​1C? Allereerst is dit een gebrek aan RAM, de hoofdbelasting valt in dit geval op de harde schijf en processor. En als ze niet uitblinken in prestaties, zoals meestal het geval is bij kantoorconfiguraties, dan krijgen we de situatie beschreven aan het begin van het artikel - de "twee" werkten prima, en de "drie" vertraagt ​​schaamteloos.

De tweede plaats moet worden gegeven aan netwerkprestaties, een langzaam kanaal van 100 Mbps kan een echt knelpunt worden, maar tegelijkertijd kan de thin client-modus een redelijk comfortabel niveau van werken handhaven, zelfs op langzame kanalen.

Dan moet u op de schijf letten, een SSD kopen is waarschijnlijk geen goede investering, maar het vervangen van de schijf door een modernere is niet overbodig. Het verschil tussen generaties harde schijven kan worden geschat aan de hand van het volgende materiaal: .

En tot slot de processor. Een sneller model zal natuurlijk niet overbodig zijn, maar het heeft weinig zin om de prestaties te verbeteren, tenzij deze pc wordt gebruikt voor zware bewerkingen: batchverwerking, zware rapporten, maandafsluiting, enz.

We hopen dat dit materiaal u zal helpen snel de vraag "waarom 1C vertraagt" te begrijpen en deze zo effectief mogelijk en zonder extra kosten op te lossen.

  • Labels:

Schakel JavaScript in om de

01.04.2004, 19:16

:virus:Ik ben geen erg ervaren admin. Sorry voor de kromme vraag. Er is zo'n vermoeden dat het lokale netwerk (en ook Telnet) trager wordt door broadcasts (de schakelaar staat volledig geknipperd en 25% van de pakketten gaat niet door!!!)! Kent iemand een programma of een manier om bij te houden vanaf welke machine ze zijn verzonden of hoe ze te blokkeren?

-----
pet veranderd
Gebed

01.04.2004, 20:14

Er is zo'n vermoeden dat het lokale netwerk (en ook Telnet) trager wordt door broadcasts (de schakelaar staat volledig geknipperd en 25% van de pakketten gaat niet door!!!)!
Waarom heb je dat besloten vanwege de uitzendingen?
beschrijf wat voor soort netwerk, is er een domein, welke besturingssystemen ...

En het onderwerp had anders moeten heten

01.04.2004, 20:30

slang2005

Probeer te snuffelen - u zult zien welke pakketten over het netwerk lopen. Bovendien, wat voor soort netwerk? Als het LAN normaal is, maar onder belasting, is het nog steeds goed dat slechts 25% verloren gaat.

02.04.2004, 00:25

Oorspronkelijk geplaatst door sky7
slang2005
Het zou leuk zijn om de titel van het topic te veranderen.

Ja, en we hebben een apart gedeelte over netwerken ... Voor nu heb ik het daarheen verplaatst ...

05.04.2004, 18:53

1. Wat voor soort netwerkapparatuur?
2. soorten koppelingen tussen schakelaars?
3. IP statisch of dynamisch?
4. hoeveel schakelaars zitten er in het netwerk en hoe zijn ze aangesloten?

In de vorm waarin u de vraag stelde, is het simpelweg onmogelijk om deze te beantwoorden.
Als u deze vragen beantwoordt - ik zal het volgende vragen, alleen dan zal het mogelijk zijn om te begrijpen wat er aan de hand is.

05.04.2004, 22:47

Positief, kijk naar de originele poppy van uitzendingen (meer precies, verzoeken) en kijk naar wie raar is in arps. Een soortgelijk geval is mogelijk wanneer 2 switchpoorten elkaar kortsluiten (niet allemaal). Of de klant installeerde een switch en sloot een paar poorten af ​​- en Windows-uitzendingen zijn allemaal toegestaan ​​- dus vermenigvuldigen ze zich met hem - en je zult begrijpen wie de schuldige is.

06.04.2004, 11:58

asdus:
en vijgen zul je begrijpen wie de schuldige is

Sorry, vanwege de door u genoemde problemen kan er een uitzendingsstorm optreden, dus u moet weten welke apparatuur de moeite waard is. Dan is duidelijk wat te doen. En met een snuffelaar zie je een broedstorm, maar in de meeste gevallen zul je hem niet kunnen volgen. vooral: een soortgelijk geval is mogelijk wanneer 2 switchpoorten elkaar kortsluiten (helemaal niet). Of de klant heeft een switch geïnstalleerd en een paar poorten kortgesloten

06.04.2004, 13:42

snake2005, welke schakelaar? Je kunt zijn statistieken bekijken. Ook op brodkasta kijk je vanuit welke haven ze vallen.

06.04.2004, 16:18

slang2005
Uh ... nou, dit zou bijvoorbeeld kunnen gebeuren als je een 100 Mbps-netwerk hebt, ongeveer 80-90 computers, groepen zijn verbonden via eenvoudige hubs, het wordt gebruikt in alle DHCP, en dit alles gaat via SSH, met sleuteluitwisseling na elke verbinding = ))))
Beschreef net een soort hel ... =)

Maar serieus, zo'n kano kan gebeuren als sommige computers in het segment met een switch werken met 10 Mbit-kaarten, sommige met 100 ....

06.04.2004, 16:56

Een casus uit mijn praktijk (een maand geleden):
Op de afdeling een netwerk voor 10 machines, een domein op Win2000 en een handvol subnetten, allemaal op switches. De machines zijn oud + take out98, het netwerk werkt prima. Ze veranderen onze machines voor Celerons 2000 (moeder Asus P4S533, ingebouwde netwerkkaarten SiS 900-gebaseerd), tegelijkertijd veranderen we de assen naar WinXP .... en het begon ... de remmen in het netwerk zijn wild ... iets op de grid inhalen naar een andere machine Onmogelijk, de verbinding tussen de machines verbreekt elk moment, de snelheid is extreem laag...
Ze deden er alles aan, het kwam op het punt dat ze het domein op Win2003 ... op de trommel zetten. En ik moet zeggen dat alle IP's constant zijn. We hebben besloten om DHCP te installeren, de situatie is hetzelfde ...
Om de TCP / IP-instellingen op de machines niet te onderbreken, reserveer ik IP op MAC-adres in DHCP, en ik merk dat alle machines hetzelfde MAC-adres hebben !!!

06.04.2004, 17:40

Oefening:
MAC-adres is hetzelfde!!!

Oefening:
brandhout voor netwerkkaart standaard

Het MAC-adres kan programmatisch worden gewijzigd (maar dit verandert het niet fysiek), maar de stuurprogramma's doen dit niet.

MAC-adressen lijken op unieke serienummers die bij fabricage aan elke Ethernet-netwerkadapter worden gegeven.

06.04.2004, 19:53

Appz_newS:
En wat is de relatie tussen de drivers en het MAC-adres van de hardware? MAC hangt af van stuurprogramma's?

Bij zeer oude MAS-kaarten was het nodig om aan de handgrepen te draaien en dit was precies wat het brandhout deed, maar dit zonk ongeveer 10 jaar geleden in de vergetelheid.

En zo'n situatie zou zich kunnen voordoen op Realtek-kaarten en dergelijke als het systeem was geïnstalleerd door de systeemschijf te klonen. Het is mij ook een keer overkomen, helaas weet ik het exacte model van de kaart niet meer, maar het is zeker realtek.
Het probleem is dat bij het installeren van WinXP iedereen de standaard netwerkdrivers uit het WinXP-pakket gebruikte. Dit probleem werd opgelost door brandhout uit de compact voor de moeder te installeren ... Nu vliegt het netwerk ...
Het lijkt mij dat het voldoende was om gewoon te slopen en opnieuw brandhout te plaatsen (waar dan ook).

06.04.2004, 21:13

Helaas (voor mij als netwerker van beroep) kunt u met 99% van de Windows-familiesystemen het MAC-adres van de netwerkkaart wijzigen zonder ver te gaan - alleen in de eigenschappen van de netwerkkaart.
En over het klonen van het systeem - dit hangt weinig af van het model van de netwerkkaart ;-) In principe niets.

06.04.2004, 21:20

Appz_newS
En wat is de relatie tussen de drivers en het MAC-adres van de hardware? MAC hangt af van stuurprogramma's?
Kan je het niet geloven?
Hier is het adres "00-E0-06-09-55-66" dat op alle machines stond. Ik heb gegoogeld en kreeg dit antwoord:
V. Veel Waarom gebruiken al mijn P4S533-VM-moederborden hetzelfde MAC-adres "00-E0-06-09-55-66"? Is er een hulpprogramma om het te herstellen?
A. Het probleem werd veroorzaakt doordat de klant de standaard WinXP-driver gebruikte. Gebruik het bijgewerkte stuurprogramma van de ondersteunings-cd of de downloadsite om dit probleem op te lossen.

Het enige verschil zit in de moeders, ik heb P4S533-MX

Hier is er nog een (http://maryno.net/forum/viewthread.php?tid=1174)

07.04.2004, 00:31

90% komt niet overeen met de snelheden van de switch en netwerkkaarten, dit zal vooral merkbaar zijn bij grote pakketten

08.04.2004, 11:49

titanium:
90% komt niet overeen met de snelheden van de switch en netwerkkaarten, dit zal vooral merkbaar zijn bij grote pakketten
Of de liefde van beginnende beheerders is om 100Mb / full duplex op de kaart te zetten en automatische detectie op de switch te laten staan. Bolezin kwam 30 keer bijeen in verschillende kantoren en met verschillende schakelaars :) :) :). Behandeld door handen te geven.

08.04.2004, 13:23

Alexs-B

08.04.2004, 13:36

STOP:
Wat is het probleem precies? Als de schakelaar honderd houdt?
In het feit dat u in dit geval 100/Full-duplex aan de ene kant en 100/half-duplex aan de andere kant ontvangt, en 80-90% van de verloren pakketten.
Lees hoe Auto werkt bij het bepalen van een poort en waarom deze is ontwikkeld.

08.04.2004, 13:59

En wat zal snake2005 zelf zeggen?
vragen aan hem bleven onbeantwoord, maar het debat aan de ronde tafel ontvouwde zich serieus....
Het is nog steeds onduidelijk of hij zijn problemen heeft opgelost, of dat hij het niet nodig heeft ...

08.04.2004, 14:37

Alexs-B

08.04.2004, 15:41

STOP:
En vanaf waar op de switch zal de half-duplex worden genomen, zo niet een geheim?
Ja, zoals uit de Fast Ethernet-specificatie

08.04.2004, 15:53

Alexs-B
Ik begrijp dat ik het al heb, maar ik zou graag een meer gedetailleerd antwoord zien. Maar waarom zal de switch 100/halfduplex zijn als de netwerkkaart wordt gedwongen tot 100/fullduplex?

08.04.2004, 16:35

Hoe Speed/Duplex correct in te stellen

Stel ________________________ krijgen

Kaart__________Schakelaar____________Kaart____________Schakelaar______ultatt
10/H__________avto/avto__________10/h______________10/h________Ok
10/v_____________-________________10/v_____________10/u______________________ Shit
10/a____________-________________10/v_____________10/v________ Oké
100/u____________-_______________100/u______100/u________Ok
100/f____________-________________100/f______100/u__________________ Shit
100/a_____________-_______________100/f______________100/f________________________________Ok
a/u_____________-_______________100/u______100/u__________Ok
a/f_____________-________________100/f_____________100/f________________________________Ok
a/a_____________-_______________100/f_____________100/f________________________________Ok

De bron van informatie is elk boek over het beheer van netwerken op instapniveau, instructies voor de switch (niet voor enig boek, het wordt beschreven in normale).
De reden is de procedure voor het bepalen van de snelheid en duplexmodus op de interfaces. Bij interesse kan ik u meer in detail vertellen, maar dit is een aparte kwestie.

08.04.2004, 18:03

Alexs-B
ja, misschien geïnteresseerd ... actueel in een apart onderwerp ok?

08.04.2004, 18:15

Alexs-B
Een nogal vreemde berekening, naar mijn mening ... Tsiskovsky "Guide to Unified Networking Technologies" is een redelijk gezaghebbend boek voor jou? Alles is daar nauwkeurig, maar vice versa - bij automatische onderhandeling heeft de duplexmodus een hogere prioriteit dan de half-duplexmodus, dus het wordt niet "100/f_avto/avto_100/f_100/h_Shit", maar "100/f_avto /avto_100/f_100/f_All_bundel". Wat overigens veel logischer is, want waarom zou je natuurlijk niet de beste verbindingsoptie kiezen uit alle echt mogelijke?
PS Vanwege een apart onderwerp vind ik het helemaal niet erg. :)

08.04.2004, 20:38

STOP:
Is Tsisk's "Guide to Unified Networking Technologies" een redelijk gezaghebbend boek voor u?
En voor jou, "Basisconfiguratie van Cisco-routers" - 1 kaart met standaardtraining?
Open uiterlijk maandag een nieuw onderwerp, laten we overleggen!

08.04.2004, 21:53

Alexs-B
Cisco (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm#xtocid29), wat betekent... En het heeft geen zin om een ​​nieuw onderwerp te starten. Het is de moeite waard om naar de originele bron te verwijzen (http://www.ieee802.org/3/ab/public/feb98/an1.pdf) en alles zal op zijn plaats vallen. Je verlamt dus tevergeefs de handen van de beheerders. :)

09.04.2004, 11:55

STOP:
Je verlamt dus tevergeefs de handen van de beheerders.
Waarom tevergeefs. Deze informatie is vrij gebruikelijk, maar hoe de verbinding in welke modus tot stand is gebracht 10 jaar geleden bij het 4e jaar van het instituut is geslaagd, voor 10 netwerken, en het is veel gedetailleerder dan Cisco heeft beschreven.

09.04.2004, 19:22

Alexs-B
Dat wil zeggen, ondanks de gegeven links, sta je erop dat de switch precies half-duplex zal hebben, begrijp ik het goed?

12.04.2004, 12:02

Ik stel voor dat je eerst experimenteert. Neem een ​​switch (liefst beheerd zodat je de status van de poort kunt zien) of 2 computers en een gekruiste kabel, emuleer de situatie en zie het resultaat. Het zal iets sneller gaan dan ruzie maken. En het resultaat zal onmiddellijk zijn.

12.04.2004, 13:19

Alexs-B
Een excentrieke man... Is de officiële standaard niet genoeg voor jou? :)

12.04.2004, 13:39

Is het moeilijk te controleren?

12.04.2004, 13:55

Alexs-B

12.04.2004, 14:22

Ik keek, keek naar je betoog. Dit zijn de resultaten van het experiment: op de automatische kaart, op de automatische schakelaar, is het resultaat een volledige duplex.

12.04.2004, 14:27

Appz_newS
Als auto-auto, dan zijn er geen vragen. We maken ruzie over wat er gebeurt als de NIC wordt gedwongen tot 100/vol en de schakelaar op automatisch wordt gezet.

12.04.2004, 14:38

STOP, oké, ik zal het nu bekijken. Ik zal het resultaat in dit bericht schrijven om niet te overstromen.

Gecontroleerd. Op de kaart 100/vol, op de automatische schakelaar. Computer overbelast. Resultaat: Full duplex op de switch.
Intel netwerkkaart, HP J4813A ProCurve Switch 2524 switch.

12.04.2004, 15:00

STOP:
Van wat? Alsjeblieft - Intel's setevushka, ingebouwd. Switch - 3Com 4300. Op de netwerkkaart zetten we Auto op 100/full, op de switch hebben we 100/full, alles is zoals het hoort.
Ben je vergeten de link opnieuw te starten?;) (fysiek)

12.04.2004, 16:57

Alexs-B
Voor wie word ik hier vastgehouden? :ogen rollen:

12.04.2004, 17:14

Nou, misschien werkt dit op moderne kaarten (vooral geïntegreerde kaarten) (er is een auto geïnstalleerd nog voordat de computer is geladen), het werkt niet op oudere.
En dit is voor fans van SSTOP primaire bronnen: http://www.cisco.com/warp/public/473/46.html#gen_tr_10_100 (ik heb 7 minuten gezocht :))

:koel:
Ik heb het over de klassiekers. Dit uur heb ik de nieuwe Asus gecontroleerd met een geïntegreerde - en echt alles zit in een bundel. Op P II c 3com 905b - een klassieker.
Dit is dus hoogstwaarschijnlijk te wijten aan het feit dat de kaart wordt ingeschakeld voordat het systeem wordt gestart en niet naar de instellingen kijkt.

Toegevoegd na 4 minuten:
Alexs-B:
Voor wie word ik hier vastgehouden?
Ze houden zich aan niemand vast. Het is gewoon dat iedereen zijn mening uit. :), en als het niet overeenkomt, maken ze ruzie!