Fremskynd arbejdet med 1C kompleks automatisering. Krav til deltagere

For nylig er brugere og administratorer i stigende grad begyndt at klage over, at nye 1C-konfigurationer udviklet på basis af en administreret applikation arbejder langsomt, i nogle tilfælde uacceptabelt langsomt. Det er klart, at nye konfigurationer indeholder nye funktioner og muligheder, og derfor er mere ressourcekrævende, men de fleste brugere forstår ikke, hvad der primært påvirker driften af ​​1C i filtilstand. Lad os prøve at rette op på dette hul.

I vores har vi allerede berørt virkningen af ​​diskundersystems ydeevne på hastigheden af ​​1C, men denne undersøgelse vedrørte den lokale brug af applikationen på en separat pc eller terminalserver. Samtidig involverer de fleste små implementeringer arbejde med en fildatabase over et netværk, hvor en af ​​brugerens pc'er bruges som server, eller en dedikeret filserver baseret på en almindelig, oftest også billig, computer.

En lille undersøgelse af russisksprogede ressourcer på 1C viste, at dette problem omhyggeligt undgås; hvis der opstår problemer, anbefales det normalt at skifte til klient-server- eller terminaltilstand. Det er også blevet næsten generelt accepteret, at konfigurationer på en administreret applikation fungerer meget langsommere end normalt. Som regel er argumenterne "jern": "Regnskab 2.0 fløj bare, og "trojkaen" bevægede sig næsten ikke. Selvfølgelig er der en vis sandhed i disse ord, så lad os prøve at finde ud af det.

Ressourceforbrug, første øjekast

Før vi begyndte denne undersøgelse, satte vi os to mål: at finde ud af, om administrerede applikationsbaserede konfigurationer faktisk er langsommere end konventionelle konfigurationer, og hvilke specifikke ressourcer der har den primære indflydelse på ydeevnen.

Til test tog vi to virtuelle maskiner, der kører henholdsvis Windows Server 2012 R2 og Windows 8.1, hvilket giver dem 2 kerner af værten Core i5-4670 og 2 GB RAM, hvilket svarer til cirka en gennemsnitlig kontormaskine. Serveren blev placeret på et RAID 0-array med to, og klienten blev placeret på et lignende array af almindelige diske.

Som eksperimentelle baser valgte vi flere konfigurationer af Accounting 2.0, udgivelse 2.0.64.12 , som derefter blev opdateret til 3.0.38.52 , blev alle konfigurationer lanceret på platformen 8.3.5.1443 .

Det første, der tiltrækker opmærksomhed, er den øgede størrelse af trojkaens informationsbase, som er vokset betydeligt, samt en meget større appetit på RAM:

Vi er klar til at høre det sædvanlige: "hvorfor føjede de det til disse tre", men lad os ikke skynde os. I modsætning til brugere af klient-server-versioner, som kræver en mere eller mindre kvalificeret administrator, tænker brugere af filversioner sjældent på at vedligeholde databaser. Også ansatte i specialiserede virksomheder, der servicerer (læs opdatering) af disse databaser, tænker sjældent over dette.

I mellemtiden er 1C informationsbasen et fuldgyldigt DBMS af sit eget format, som også kræver vedligeholdelse, og til dette er der endda et værktøj kaldet Test og korrigering af informationsgrundlaget. Måske spillede navnet en grusom joke, som på en eller anden måde antyder, at dette er et værktøj til fejlfinding af problemer, men lav ydeevne er også et problem, og omstrukturering og reindeksering sammen med tabelkomprimering er velkendte værktøjer til at optimere databaser for enhver DBMS-administrator . Skal vi tjekke?

Efter at have anvendt de valgte handlinger "tabte databasen sig kraftigt" og blev endnu mindre end de "to", som ingen nogensinde havde optimeret, og RAM-forbruget faldt også lidt.

Efterfølgende, efter indlæsning af nye klassifikatorer og mapper, oprettelse af indekser osv. størrelsen af ​​basen vil stige; generelt er de "tre" baser større end de "to" baser. Dette er dog ikke vigtigere, hvis den anden version var tilfreds med 150-200 MB RAM, så har den nye udgave brug for en halv gigabyte, og denne værdi skal tages i betragtning, når du planlægger de nødvendige ressourcer til at arbejde med programmet.

Net

Netværksbåndbredde er en af ​​de vigtigste parametre for netværksapplikationer, især som 1C i filtilstand, som flytter betydelige mængder data på tværs af netværket. De fleste netværk af små virksomheder er bygget på basis af billigt 100 Mbit/s udstyr, så vi begyndte at teste ved at sammenligne 1C ydeevneindikatorer i 100 Mbit/s og 1 Gbit/s netværk.

Hvad sker der, når du starter en 1C-fildatabase over netværket? Klienten downloader en ret stor mængde information til midlertidige mapper, især hvis dette er den første "kolde" start. Ved 100 Mbit/s forventes vi at løbe ind i kanalbredde, og downloading kan tage en betydelig mængde tid, i vores tilfælde omkring 40 sekunder (omkostningen ved at dividere grafen er 4 sekunder).

Den anden lancering er hurtigere, da nogle af dataene er gemt i cachen og forbliver der indtil genstart. Skift til et gigabit-netværk kan fremskynde programindlæsningen betydeligt, både "koldt" og "varmt", og forholdet mellem værdier respekteres. Derfor besluttede vi at udtrykke resultatet i relative værdier, idet den største værdi af hver måling blev 100 %:

Som du kan se på graferne, indlæses Accounting 2.0 ved enhver netværkshastighed dobbelt så hurtigt, overgangen fra 100 Mbit/s til 1 Gbit/s giver dig mulighed for at fremskynde downloadtiden fire gange. Der er ingen forskel mellem de optimerede og ikke-optimerede "trojka"-databaser i denne tilstand.

Vi kontrollerede også netværkshastighedens indflydelse på driften i tunge tilstande, for eksempel under gruppeoverførsler. Resultatet er også udtrykt i relative værdier:

Her er det mere interessant, den optimerede base af de "tre" i et 100 Mbit/s netværk arbejder med samme hastighed som de "to", og den ikke-optimerede viser dobbelt så dårlige resultater. På gigabit forbliver forholdet det samme, den uoptimerede "tre" er også halvt så langsom som de "to", og den optimerede halter en tredjedel bagud. Også overgangen til 1 Gbit/s giver dig mulighed for at reducere eksekveringstiden med tre gange for udgave 2.0 og med det halve for udgave 3.0.

For at evaluere effekten af ​​netværkshastighed på det daglige arbejde, brugte vi Præstationsmåling, der udfører en sekvens af forudbestemte handlinger i hver database.

Faktisk er netværksgennemstrømning ikke en flaskehals til daglige opgaver, en uoptimeret "tre" er kun 20 % langsommere end en "to", og efter optimering viser den sig at være omtrent det samme hurtigere - fordelene ved at arbejde i tynd klienttilstand er tydelige. Overgangen til 1 Gbit/s giver ikke den optimerede base nogen fordele, og den uoptimerede og de to begynder at arbejde hurtigere og viser en lille forskel på sig selv.

Ud fra de udførte tests bliver det klart, at netværket ikke er en flaskehals for de nye konfigurationer, og den administrerede applikation kører endnu hurtigere end normalt. Du kan også anbefale at skifte til 1 Gbit/s, hvis tunge opgaver og databaseindlæsningshastighed er kritisk for dig; i andre tilfælde giver nye konfigurationer dig mulighed for at arbejde effektivt selv i langsomme 100 Mbit/s netværk.

Så hvorfor er 1C langsom? Vi vil se nærmere på det.

Serverdiskundersystem og SSD

I den forrige artikel opnåede vi en stigning i 1C-ydeevne ved at placere databaser på en SSD. Måske er ydeevnen af ​​serverens diskundersystem utilstrækkelig? Vi målte ydeevnen af ​​en diskserver under en gruppekørsel i to databaser på én gang og fik et ret optimistisk resultat.

På trods af det relativt store antal input/output operationer per sekund (IOPS) - 913, oversteg kølængden ikke 1,84, hvilket er et meget godt resultat for et to-disk array. Baseret på dette kan vi antage, at et spejl lavet af almindelige diske vil være nok til normal drift af 8-10 netværksklienter i tunge tilstande.

Så er der brug for en SSD på en server? Den bedste måde at besvare dette spørgsmål på vil være gennem test, som vi udførte ved hjælp af en lignende metode, netværksforbindelsen er 1 Gbit/s overalt, resultatet er også udtrykt i relative værdier.

Lad os starte med databasens indlæsningshastighed.

Det kan virke overraskende for nogle, men SSD'en på serveren påvirker ikke databasens indlæsningshastighed. Den vigtigste begrænsende faktor her, som den forrige test viste, er netværksgennemstrømning og klientydelse.

Lad os gå videre til at lave om:

Vi har allerede bemærket ovenfor, at diskens ydeevne er ganske tilstrækkelig selv til at arbejde i tunge tilstande, så hastigheden på SSD'en er heller ikke påvirket, bortset fra den uoptimerede base, som på SSD'en har indhentet den optimerede. Faktisk bekræfter dette endnu en gang, at optimeringsoperationer organiserer information i databasen, hvilket reducerer antallet af tilfældige I/O-operationer og øger adgangshastigheden til den.

I hverdagens opgaver er billedet det samme:

Kun den ikke-optimerede database drager fordel af SSD'en. Du kan selvfølgelig købe en SSD, men det ville være meget bedre at tænke på rettidig vedligeholdelse af databasen. Glem heller ikke at defragmentere sektionen med infobaser på serveren.

Client disk subsystem og SSD

Vi analyserede indflydelsen af ​​SSD på driftshastigheden af ​​lokalt installeret 1C in, meget af det, der blev sagt, er også sandt for arbejde i netværkstilstand. Faktisk bruger 1C ganske aktivt diskressourcer, herunder til baggrunds- og rutineopgaver. På figuren nedenfor kan du se, hvordan Accounting 3.0 ret aktivt tilgår disken i omkring 40 sekunder efter indlæsning.

Men samtidig skal du være opmærksom på, at for en arbejdsstation, hvor der arbejdes aktivt med en eller to informationsdatabaser, er ydeevneressourcerne på en almindelig masseproduceret HDD ganske tilstrækkelige. At købe en SSD kan fremskynde nogle processer, men du vil ikke bemærke en radikal acceleration i det daglige arbejde, da for eksempel downloading vil være begrænset af netværkets båndbredde.

En langsom harddisk kan bremse nogle handlinger, men kan i sig selv ikke få et program til at bremse.

vædder

På trods af at RAM nu er uanstændigt billig, fortsætter mange arbejdsstationer med at arbejde med den mængde hukommelse, der blev installeret, da de blev købt. Det er her de første problemer venter. Baseret på det faktum, at den gennemsnitlige "trojka" kræver omkring 500 MB hukommelse, kan vi antage, at en samlet mængde RAM på 1 GB ikke vil være nok til at arbejde med programmet.

Vi reducerede systemhukommelsen til 1 GB og lancerede to informationsdatabaser.

Ved første øjekast er alt ikke så slemt, programmet har dæmpet sin appetit og passer godt ind i den tilgængelige hukommelse, men lad os ikke glemme, at behovet for driftsdata ikke har ændret sig, så hvor blev det af? Dumpet i disk, cache, swap osv., er essensen af ​​denne operation, at data, der ikke er nødvendige i øjeblikket, sendes fra hurtig RAM, hvis mængde ikke er nok, til langsom diskhukommelse.

Hvor fører det hen? Lad os se, hvordan systemressourcer bruges i tunge operationer, lad os for eksempel starte en gruppegenoverførsel i to databaser på én gang. Først på et system med 2 GB RAM:

Som vi kan se, bruger systemet aktivt netværket til at modtage data og processoren til at behandle dem; diskaktivitet er ubetydelig; under behandlingen øges den lejlighedsvis, men er ikke en begrænsende faktor.

Lad os nu reducere hukommelsen til 1 GB:

Situationen ændrer sig radikalt, hovedbelastningen falder nu på harddisken, processoren og netværket er inaktive og venter på, at systemet læser de nødvendige data fra disken ind i hukommelsen og sender unødvendige data dertil.

På samme tid viste selv subjektivt arbejde med to åbne databaser på et system med 1 GB hukommelse sig at være ekstremt ubehageligt; mapper og magasiner åbnede med en betydelig forsinkelse og aktiv adgang til disken. For eksempel tog åbningen af ​​journalen Salg af varer og tjenester omkring 20 sekunder og blev al denne tid ledsaget af høj diskaktivitet (fremhævet med en rød linje).

For objektivt at vurdere virkningen af ​​RAM på ydeevnen af ​​konfigurationer baseret på en administreret applikation, udførte vi tre målinger: indlæsningshastigheden af ​​den første database, indlæsningshastigheden af ​​den anden database og gruppegenkøring i en af ​​databaserne . Begge databaser er fuldstændig identiske og blev oprettet ved at kopiere den optimerede database. Resultatet er udtrykt i relative enheder.

Resultatet taler for sig selv: Hvis indlæsningstiden stiger med omkring en tredjedel, hvilket stadig er ret acceptabelt, øges tiden til at udføre operationer i databasen tre gange, der er ingen grund til at tale om noget behageligt arbejde under sådanne forhold. Forresten, dette er tilfældet, når køb af en SSD kan forbedre situationen, men det er meget nemmere (og billigere) at håndtere årsagen, ikke konsekvenserne, og bare købe den rigtige mængde RAM.

Mangel på RAM er hovedårsagen til, at arbejdet med nye 1C-konfigurationer viser sig at være ubehageligt. Konfigurationer med 2 GB hukommelse ombord bør betragtes som minimalt egnede. Samtidig skal du huske på, at der i vores tilfælde blev skabt "drivhus"-forhold: et rent system, kun 1C og task manager kørte. I det virkelige liv, på en arbejdscomputer, er som regel en browser, en kontorpakke åbne, et antivirus kører osv. osv., så fortsæt fra behovet for 500 MB pr. database plus noget reserve, så under tunge operationer møder du ikke mangel på hukommelse og et kraftigt fald i produktiviteten.

CPU

Uden overdrivelse kan den centrale processor kaldes computerens hjerte, da det er den, der i sidste ende behandler alle beregninger. For at evaluere dens rolle gennemførte vi et andet sæt test, det samme som for RAM, hvilket reducerede antallet af kerner, der er tilgængelige for den virtuelle maskine fra to til én, og testen blev udført to gange med hukommelsesmængder på 1 GB og 2 GB.

Resultatet viste sig at være ret interessant og uventet: en mere kraftfuld processor påtog sig ganske effektivt belastningen, når der var mangel på ressourcer, resten af ​​tiden uden at give nogen håndgribelige fordele. 1C Enterprise (i filtilstand) kan næppe kaldes en applikation, der aktivt bruger processorressourcer; den er ret krævende. Og under vanskelige forhold belastes processoren ikke så meget ved at beregne dataene i selve applikationen, men ved at servicere overheadomkostninger: yderligere input/outputoperationer osv.

konklusioner

Så hvorfor er 1C langsom? Først og fremmest er dette mangel på RAM; hovedbelastningen i dette tilfælde falder på harddisken og processoren. Og hvis de ikke skinner med ydeevne, som det normalt er tilfældet i kontorkonfigurationer, så får vi situationen beskrevet i begyndelsen af ​​artiklen - de "to" fungerede fint, men de "tre" er ugudeligt langsom.

På andenpladsen er netværkets ydeevne; en langsom 100 Mbit/s kanal kan blive en reel flaskehals, men samtidig er den tynde klienttilstand i stand til at opretholde et ret behageligt driftsniveau selv på langsomme kanaler.

Så skal du være opmærksom på diskdrevet; at købe en SSD er usandsynligt en god investering, men at udskifte drevet med et mere moderne ville være en god idé. Forskellen mellem generationer af harddiske kan vurderes ud fra følgende materiale: .

Og endelig processoren. En hurtigere model vil selvfølgelig ikke være overflødig, men det nytter ikke meget at øge dens ydeevne, medmindre denne pc bruges til tunge operationer: gruppebehandling, tunge rapporter, månedsafslutning osv.

Vi håber, at dette materiale vil hjælpe dig med hurtigt at forstå spørgsmålet "hvorfor 1C er langsom" og løse det mest effektivt og uden ekstra omkostninger.

• Tags:

Foto af Alena Tulyakova, nyhedsbureauet "Clerk.Ru"

Artiklen identificerer de vigtigste fejl, som begyndere 1C-administratorer laver, og viser, hvordan de løses ved at bruge Gilev-testen som eksempel.

Hovedformålet med at skrive denne artikel er at undgå at gentage åbenlyse nuancer for de administratorer (og programmører), der endnu ikke har fået erfaring med 1C.

Det sekundære mål er, at hvis jeg har nogle mangler, vil Infostart være den hurtigste til at påpege dette over for mig.

V. Gilevs test er allerede blevet en slags "de facto" standard. Forfatteren på sin hjemmeside gav ganske klare anbefalinger, men jeg vil blot præsentere nogle resultater og kommentere de mest sandsynlige fejl. Testresultaterne på dit udstyr kan naturligvis være forskellige, det er blot en guide til, hvad der skal være, og hvad du kan stræbe efter. Jeg vil gerne bemærke med det samme, at ændringer skal foretages trin for trin, og efter hvert trin, tjek hvilket resultat det gav.

Der er lignende artikler om Infostart, jeg vil lægge links til dem i de relevante sektioner (hvis jeg savner noget, så foreslå mig venligst i kommentarerne, jeg tilføjer det). Så lad os antage, at din 1C er langsom. Hvordan kan man diagnosticere problemet, og hvordan man forstår, hvem der har skylden, administratoren eller programmøren?

Indledende data:

Testet computer, hovedmarsvin: HP DL180G6, udstyret med 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Til sammenligning viser Core i3-2100 sammenlignelige resultater i den enkelt-trådede test. Det udstyr, jeg bevidst valgte, var ikke det nyeste; med moderne udstyr er resultaterne mærkbart bedre.

Til test af separate 1C- og SQL-servere, SQL-server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

For at teste et 10 Gbit netværk blev der brugt Intel 520-DA2 adaptere.

Fil version. (databasen er på serveren i en delt mappe, klienter forbinder via netværket, CIFS/SMB-protokol). Algoritme trin for trin:

0. Tilføj Gilevs testdatabase til filserveren i samme mappe som hoveddatabaserne. Vi forbinder fra klientcomputeren og kører testen. Vi husker resultatet.

Det er underforstået, at selv for gamle computere fra 10 år siden (Pentium på 775-socket), bør tiden fra klik på 1C:Enterprise-genvejen til databasevinduets udseende tage mindre end et minut. (Celeron = langsom).

Hvis din computer er værre end en Pentium på 775-sokkel med 1 GB RAM, så sympatiserer jeg med dig, og det vil være svært for dig at opnå behageligt arbejde på 1C 8.2 i filversionen. Tænk på enten at opgradere (det er på høje tid) eller skifte til en terminal (eller web, i tilfælde af tynde klienter og administrerede formularer) server.

Hvis computeren ikke er værre, kan du sparke administratoren. Kontroller som minimum driften af ​​netværks-, antivirus- og HASP-beskyttelsesdriveren.

Hvis Gilevs test på dette tidspunkt viste 30 "papegøjer" eller højere, men 1C-arbejdsbasen stadig fungerer langsomt, bør spørgsmålene rettes til programmøren.

1. Som en guide til, hvor meget en klientcomputer kan "klemme", kontrollerer vi kun driften af ​​denne computer, uden et netværk. Vi installerer testdatabasen på en lokal computer (på en meget hurtig disk). Hvis klientcomputeren ikke har en normal SSD, oprettes en ramdisk. Indtil videre er den enkleste og gratis Ramdisk enterprise.

For at teste version 8.2 er en 256 MB ramdisk nok, og! Den vigtigste. Efter genstart af computeren, med ramdisken kørende, skulle der være 100-200 MB ledigt på den. Uden en ramdisk skal der derfor være 300-400 MB ledig hukommelse til normal drift.

For at teste version 8.3 er en 256 MB ramdisk nok, men du har brug for mere ledig RAM.

Når du tester, skal du se på processorbelastningen. I et tilfælde tæt på ideelt (ramdisk) indlæser lokal fil 1c 1 processorkerne, når den kører. Derfor, hvis din processorkerne ikke er fuldt lastet under testen, skal du kigge efter svage punkter. Lidt følelsesladet, men generelt korrekt, er processorens indflydelse på driften af ​​1C beskrevet. Blot til reference, selv på moderne Core i3s med høje frekvenser, er tallene 70-80 ret realistiske.

De mest almindelige fejl på dette stadium.

• Forkert konfigureret antivirus. Der er mange antivirus, indstillingerne for hver er forskellige, jeg vil kun sige, at med korrekt konfiguration forstyrrer hverken nettet eller Kaspersky 1C. Med standardindstillingerne kan cirka 3-5 papegøjer (10-15%) tages væk.
• Performance mode. Af en eller anden grund er de færreste opmærksomme på dette, men effekten er den mest markante. Hvis du har brug for hastighed, så skal du gøre dette, både på klient- og servercomputere. (Gilev har en god beskrivelse. Den eneste advarsel er, at på nogle bundkort, hvis du slår Intel SpeedStep fra, kan du ikke slå TurboBoost til).

Du kan (og helst) aktivere ydeevnetilstand to steder:

• via BIOS. Deaktiver tilstande C1, C1E, Intel C-state (C2, C3, C4). I forskellige bios kaldes de forskelligt, men betydningen er den samme. Det tager lang tid at søge, en genstart er påkrævet, men hvis du gør det én gang, så kan du glemme det. Hvis du gør alt korrekt i BIOS, vil hastigheden stige. På nogle bundkort kan du konfigurere BIOS-indstillingerne, så Windows ydeevnetilstand ikke spiller en rolle. (Eksempler på BIOS-indstillinger fra Gilev). Disse indstillinger vedrører primært serverprocessorer eller "avancerede" BIOS'er, hvis du ikke har fundet dette, og du IKKE har Xeon, er det okay.

• Kontrolpanel - Strømforsyning - Høj ydeevne. Minus - hvis computeren ikke har været serviceret i længere tid, vil den give en højere blæserstøj, varme mere op og forbruge mere energi. Dette er et præstationshonorar.

Disse er standardindstillingerne. BIOS C-tilstand aktiveret, balanceret strømforbrugstilstand
BIOS C-state aktiveret, højtydende tilstand For Pentium og Core kan du stoppe der, Du kan stadig presse lidt "papegøjer" ud af Xeon
I BIOS er C-tilstand deaktiveret, højtydende tilstand. Hvis du ikke bruger Turbo boost, er det sådan, det skal se ud server tunet til ydeevne

Og nu tallene. Lad mig minde dig om: Intel Xeon 5650, ramdisk. I det første tilfælde viser testen 23,26, i det sidste - 49,5. Forskellen er næsten dobbelt. Tallene kan variere, men forholdet forbliver stort set det samme for Intel Core.

Kære administratorer, I kan kritisere 1C så meget, som I vil, men hvis slutbrugere har brug for hastighed, skal I aktivere højtydende tilstand.

c) Turbo Boost. Først skal du forstå, om din processor f.eks. understøtter denne funktion. Hvis det understøtter, så kan du stadig helt lovligt få en vis ydeevne. (Jeg ønsker ikke at røre ved problemerne med frekvensoverclocking, især servere, gør det på egen risiko og risiko. Men jeg er enig i, at øget bushastighed fra 133 til 166 giver en meget mærkbar stigning i både hastighed og varmeafledning)

Hvordan man slår turbo boost til, skrives f.eks. Men! For 1C er der nogle nuancer (ikke de mest indlysende). Vanskeligheden er, at den maksimale effekt af turboboost opstår, når C-tilstand er tændt. Og vi får noget som dette:

Bemærk venligst, at multiplikatoren er den maksimale, kernehastigheden er smuk, og ydeevnen er høj. Men hvad vil der ske som et resultat med 1'ere?

Men i sidste ende viser det sig, at ifølge CPU-ydelsestests er versionen med en multiplikator på 23 foran, ifølge Gilevs test i filversionen er ydeevnen med en multiplikator på 22 og 23 den samme, men i klient-serveren version - versionen med en multiplikator på 23 er forfærdelig frygtelig forfærdelig (selvom C -state sat til niveau 7, er den stadig langsommere end med C-state slået fra). Derfor er anbefalingen selv at tjekke begge muligheder og vælge den bedste. Under alle omstændigheder er forskellen mellem 49,5 og 53 papegøjer ret betydelig, især uden større indsats.

Konklusion - turbo boost skal være slået til. Lad mig minde dig om, at det ikke er nok at aktivere Turbo boost-elementet i BIOS, du skal også se på andre indstillinger (BIOS: QPI L0s, L1 - deaktiver, kræve skrubning - deaktiver, Intel SpeedStep - enable, Turbo boost - aktiver Kontrolpanel - Strømstyring - Høj ydeevne) . Og jeg ville stadig (selv for filversionen) vælge den mulighed, hvor c-state er slået fra, selvom multiplikatoren er mindre. Det vil vise sig noget som dette...

Et ret kontroversielt punkt er hukommelsesfrekvensen. For eksempel har hukommelsesfrekvens vist sig at have en meget stærk indflydelse. Mine tests afslørede ikke en sådan afhængighed. Jeg vil ikke sammenligne DDR 2/3/4, jeg vil vise resultaterne af at ændre frekvensen inden for samme linje. Hukommelsen er den samme, men i BIOS er vi tvunget til at indstille lavere frekvenser.

Og testresultater. 1C 8.2.19.83, for filversionen lokal ramdisk, for klient-server 1C og SQL på én computer, delt hukommelse. Turbo boost er deaktiveret i begge versioner. 8.3 viser sammenlignelige resultater.

Forskellen ligger inden for målefejlen. Jeg trak specifikt skærmbilleder af CPU-Z for at vise, at med en ændring i frekvens, ændres andre parametre også, den samme CAS Latency og RAS til CAS Delay, som neutraliserer ændringen i frekvensen. Forskellen vil være, når hukommelsesmodulerne fysisk ændres, fra langsommere til hurtigere, men selv der er tallene ikke særligt markante.

2. Når vi har sorteret processoren og hukommelsen på klientcomputeren, går vi videre til det næste meget vigtige sted - netværket. Der er skrevet mange bind af bøger om netværksindstilling, der er artikler om Infostart ( og andre), men her vil jeg ikke fokusere på dette emne. Før du begynder at teste 1C, skal du sørge for, at iperf mellem to computere viser hele båndbredden (for 1 Gbit-kort - godt, mindst 850 Mbit, eller endnu bedre 950-980), som Gilevs råd er blevet fulgt. Så - den enkleste test af driften vil mærkeligt nok være at kopiere en stor fil (5-10 gigabyte) over netværket. Et indirekte tegn på normal drift på et 1 Gbit netværk vil være den gennemsnitlige kopieringshastighed på 100 MB/sek., god drift - 120 MB/sek. Jeg vil gerne henlede din opmærksomhed på, at det svage punkt (inklusive) kan være processorbelastningen. SMB-protokollen på Linux er ret dårligt paralleliseret, og under drift kan den ganske nemt "spise" en processorkerne og ikke forbruge mere.

Og videre. Med standardindstillingerne fungerer Windows-klienten bedst med en Windows-server (eller endda en Windows-arbejdsstation) og SMB/CIFS-protokollen, en linux-klient (debian, ubuntu kiggede ikke på de andre) fungerer bedre med linux og NFS ( det virker også med SMB, men på NFS er papegøjer højere). Det faktum, at en Windows Linux-server til NFS under lineær kopiering kopieres til én strøm hurtigere, betyder ikke noget. Debian tuning for 1C er et emne for en separat artikel, jeg er ikke klar til det endnu, selvom jeg kan sige, at i filversionen fik jeg endnu lidt bedre ydeevne end Win-versionen på samme udstyr, men med postgres med over 50 brugere Jeg har stadig alt meget dårligt.

Det vigtigste, som "brændte" administratorer ved, men begyndere tager ikke hensyn til. Der er mange måder at indstille stien til 1c-databasen på. Du kan lave servershare, du kan gøre 192.168.0.1share, du kan nettobruge z: 192.168.0.1share (og i nogle tilfælde vil denne metode også fungere, men ikke altid) og derefter angive drev Z. Det ser ud til, at alle disse stier pege på det samme samme sted, men for 1C er der kun én metode, der giver normal ydeevne ganske pålideligt. Så dette er hvad du skal gøre korrekt:

På kommandolinjen (eller i politikker, eller hvad der er praktisk for dig) - brug net DriveLetter: servershare. Eksempel: netbrug m: serverbaser. Jeg understreger specifikt IKKE IP-adressen, men servernavnet. Hvis servernavnet ikke er synligt, skal du tilføje det til dns på serveren eller lokalt til hosts-filen. Men adressen skal være ved navn. Følgelig, på vej til databasen, få adgang til denne disk (se billede).

Og nu vil jeg vise med tal, hvorfor dette er rådet. Indledende data: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169-kort. OS Win 2008 R2, Win 7, Debian 8. Seneste drivere, opdateringer anvendt. Inden jeg testede, sikrede jeg mig, at Iperf giver den fulde båndbredde (bortset fra 10 Gbit-kort, lykkedes det kun at presse 7,2 Gbit ud, jeg skal se hvorfor senere, testserveren er endnu ikke konfigureret korrekt). Diskene er forskellige, men overalt er der en SSD (jeg indsatte specielt en enkelt disk til test, den er ikke indlæst med andet) eller et raid fra en SSD. Hastigheden på 100 Mbit blev opnået ved at begrænse indstillingerne for Intel 362-adapteren. Der var ingen forskel mellem 1 Gbit kobber Intel 350 og 1 Gbit optisk Intel X520-DA2 (opnået ved at begrænse hastigheden på adapteren). Maksimal ydeevne, turbo boost er slået fra (bare for sammenlignelighed af resultater, turbo boost for gode resultater tilføjer lidt mindre end 10%, for dårlige resultater kan det ikke have nogen effekt overhovedet). Version 1C 8.2.19.86, 8.3.6.2076. Jeg giver ikke alle tallene, men kun de mest interessante, så du har noget at sammenligne med.

Konklusioner (fra tabellen og fra personlig erfaring. Gælder kun for filversionen):

• Over netværket kan du få helt normale tal for arbejde, hvis dette netværk er korrekt konfigureret og stien er indtastet korrekt i 1C. Selv den første Core i3 kan sagtens producere 40+ papegøjer, hvilket er ret godt, og det er ikke kun papegøjer, i rigtigt arbejde er forskellen også mærkbar. Men! Begrænsningen ved arbejde med flere (mere end 10) brugere vil ikke længere være netværket, her er 1 Gbit stadig nok, men blokering under flerbrugerarbejde (Gilev).
• 1C 8.3 platformen er mange gange mere krævende med hensyn til korrekt netværkskonfiguration. Grundindstillinger - se Gilev, men husk at alt kan påvirkes. Jeg så en acceleration fra at afinstallere (og ikke bare slukke) antivirus, fra at fjerne protokoller som FCoE, fra at ændre drivere til en ældre, men Microsoft-certificeret version (især for billige kort som ASUS og DLC), fra at fjerne det andet netværkskort fra serveren. Der er mange muligheder, sæt dit netværk omhyggeligt op. Der kan meget vel være en situation, hvor platform 8.2 giver acceptable tal, og 8.3 - to eller endda flere gange mindre. Prøv at spille med platform version 8.3, nogle gange får du en meget stor effekt.
• 1C 8.3.6.2076 (måske senere, jeg har ikke ledt efter den nøjagtige version endnu) er stadig nemmere at konfigurere over netværket end 8.3.7.2008. Jeg var i stand til at opnå normal drift over netværket fra 8.3.7.2008 (i sammenlignelige papegøjer) kun et par gange; jeg kunne ikke gentage det for et mere generelt tilfælde. Jeg forstod ikke meget, men at dømme efter fodindpakningerne fra Process Explorer er optagelsen der ikke så god som i 8.3.6.
• På trods af det faktum, at når du arbejder på et 100 Mbit-netværk, er dets belastningsplan lille (vi kan sige, at netværket er gratis), er driftshastigheden stadig meget mindre end på 1 Gbit. Årsagen er netværksforsinkelse.
• Alt andet lige (et velfungerende netværk) for 1C 8.2 er Intel-Realtek-forbindelsen 10% langsommere end Intel-Intel. Men realtek-realtek kan generelt give skarpe sætninger ud af det blå. Derfor, hvis du har penge, er det bedre at opbevare Intel-netværkskort overalt; hvis du ikke har penge, så installer kun Intel på serveren (din CO). Og der er mange gange flere instruktioner til tuning af Intel-netværkskort.
• Standard antivirusindstillinger (bruger drweb version 10 som eksempel) fylder omkring 8-10% af papegøjer. Hvis du konfigurerer det som det skal (lader 1cv8-processen gøre alt, selvom det ikke er sikkert), er hastigheden den samme som uden et antivirus.
• Læs IKKE Linux-guruer. En server med samba er fantastisk og gratis, men hvis du installerer Win XP eller Win7 (eller endnu bedre - server OS) på serveren, så fungerer filversionen af ​​1c hurtigere. Ja, samba og protokolstakken og netværksindstillinger og meget, meget mere kan godt indstilles i debian/ubuntu, men dette anbefales til specialister. Det nytter ikke at installere Linux med standardindstillinger og så sige, at det er langsomt.
• Det er en ganske god idé at kontrollere driften af ​​diske, der er tilsluttet via netbrug ved hjælp af fio . Det vil i hvert fald fremgå, om det er problemer med 1C platformen, eller med netværket/disken.
• For enkeltbrugerversionen kan jeg ikke komme i tanke om test (eller en situation), hvor forskellen mellem 1 Gbit og 10 Gbit ville være synlig. Det eneste, hvor 10Gbit til filversionen gav bedre resultater, er tilslutning af diske via iSCSI, men dette er et emne for en separat artikel. Alligevel tror jeg, at til filversionen er 1 Gbit-kort nok.
• Jeg forstår ikke, hvorfor 8.3 med et 100 Mbit-netværk virker mærkbart hurtigere end 8.2, men det var en kendsgerning. Alt andet udstyr, alle andre indstillinger er absolut de samme, det er bare, at i det ene tilfælde er 8.2 testet, og i det andet - 8.3.
• Ikke-tunet NFS win-win eller win-lin giver 6 papegøjer, jeg har ikke inkluderet dem i tabellen. Efter tuning fik jeg 25, men den var ustabil (forskellen i mål var mere end 2 enheder). Jeg kan endnu ikke give anbefalinger om brug af Windows og NFS-protokollen.

Terminal server. (databasen er på serveren, klienter forbinder via netværket, RDP-protokol). Algoritme trin for trin:

• Vi tilføjer Gilevs testdatabase til serveren i samme mappe som hoveddatabaserne. Vi forbinder fra den samme server og kører testen. Vi husker resultatet.
• På nøjagtig samme måde som i filversionen konfigurerer vi processoren. I tilfælde af en terminalserver spiller processoren generelt hovedrollen (det antages, at der ikke er nogen åbenlyse svage punkter, såsom mangel på hukommelse eller en enorm mængde unødvendig software).
• Konfiguration af netværkskort i tilfælde af en terminalserver har stort set ingen indflydelse på driften af ​​1c. For at sikre "særlig" komfort, hvis din server producerer mere end 50 papegøjer, kan du lege med nye versioner af RDP-protokollen, blot for brugernes komfort, hurtigere respons og rulning.
• Når et stort antal brugere aktivt arbejder (og her kan du allerede prøve at forbinde 30 personer til en database, hvis du prøver), er det meget tilrådeligt at installere et SSD-drev. Af en eller anden grund menes det, at disken ikke påvirker driften af ​​1C i særlig grad, men alle test udføres med controller-cachen aktiveret til skrivning, hvilket er forkert. Testbasen er lille, den passer ret godt i cachen, deraf de høje tal. På rigtige (store) databaser vil alt være helt anderledes, så cachen er deaktiveret til test.

• Den aktiverede RAID-controller-cache eliminerer alle forskellene mellem diskene; tallene er de samme for både sat og cas. Test med det på en lille mængde data er nytteløst og er ikke vejledende af nogen art.
• For platform 8.2 er forskellen i ydeevne mellem SATA- og SSD-muligheder mere end det dobbelte. Dette er ikke en tastefejl. Hvis du ser på ydeevnemonitoren under testen på SATA-drev. så kan du tydeligt se "Aktiv diskdriftstid (i%)" 80-95. Ja, hvis du aktiverer cachen på selve diskene til optagelse, vil hastigheden stige til 35, hvis du aktiverer cachen på raid-controlleren - op til 49 (uanset hvilke diske der testes i øjeblikket). Men disse er syntetiske cache-papegøjer; i virkeligt arbejde, med store databaser, vil der aldrig være et 100% skrive-cache-hitforhold.
• Hastigheden på selv billige SSD'er (jeg testede på Agility 3) er ganske nok til at køre filversionen. Optagelsesressourcen er en anden sag, du skal se på den i hvert enkelt tilfælde, det er klart, at Intel 3700 vil have det en størrelsesorden højere, men prisen er tilsvarende. Og ja, jeg forstår, at når jeg tester en SSD-disk, tester jeg også cachen på denne disk i højere grad, de reelle resultater bliver mindre.
• Den mest korrekte (fra mit synspunkt) løsning ville være at allokere 2 SSD-diske i et spejlvendt raid til en fildatabase (eller flere fildatabaser), og ikke placere andet der. Ja, med et spejl slides SSD'er lige meget, og det er et minus, men i det mindste er controllerelektronikken på en eller anden måde beskyttet mod fejl.
• De vigtigste fordele ved SSD-drev til filversionen vises, når der er mange databaser, hver med flere brugere. Hvis der er 1-2 databaser, og der er omkring 10 brugere, så vil SAS-diske være nok. (men under alle omstændigheder, se på at indlæse disse diske, i det mindste gennem perfmon).
• De vigtigste fordele ved en terminalserver er, at den kan have meget svage klienter, og netværksindstillingerne påvirker terminalserveren meget mindre (igen din K.O.).

Hvis Gilevs test viser små tal, og du har en processor med højt ur og hurtige diske, så skal administratoren i det mindste tage perfmon, registrere alle resultaterne et sted og se, observere og drage konklusioner. Der vil ikke være nogen endelig rådgivning.

Klient-server mulighed.

Test blev kun udført den 8.2, fordi på 8.3 afhænger alt ganske alvorligt af versionen.

Til test valgte jeg forskellige serverindstillinger og netværk mellem dem for at vise de vigtigste tendenser.

Det ser ud til, at jeg har overvejet alle de interessante muligheder, hvis der er andet, du er interesseret i, så skriv i kommentarerne, jeg vil prøve at gøre det.

• SAS på lagersystemer er langsommere end lokale SSD'er, selvom lagersystemerne har større cachestørrelser. SSD'er, både lokale og på lagersystemer, fungerer ved sammenlignelige hastigheder til Gilevs test. Jeg kender ikke nogen standard multi-threaded test (ikke kun optagelse, men alt udstyr) bortset fra 1C belastningstesten fra MCC.
• Ændring af 1C-serveren fra 5520 til 5650 fordoblede næsten ydeevnen. Ja, serverkonfigurationerne stemmer ikke helt overens, men det viser en tendens (ingen overraskelse).
• At øge frekvensen på SQL-serveren giver bestemt en effekt, men ikke den samme som på 1C-serveren; MS SQL-serveren er fremragende (hvis du spørger det) til at bruge multi-cores og fri hukommelse.
• Ændring af netværket mellem 1C og SQL fra 1 Gbit til 10 Gbit giver cirka 10 % papegøjer. Jeg forventede mere.
• Aktivering af delt hukommelse giver stadig en effekt, dog ikke 15 %, som beskrevet i artiklen. Sørg for at gøre det, heldigvis er det hurtigt og nemt. Hvis nogen under installationen gav SQL-serveren en navngivet instans, så for at 1C skal fungere, skal servernavnet ikke angives af FQDN (tcp/ip vil fungere), ikke gennem localhost eller kun ServerName, men gennem ServerNameInstanceName, for eksempel zz- testzztest. (Ellers vil der være en DBMS-fejl: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Det delte hukommelsesbibliotek, der blev brugt til at etablere en forbindelse med SQL Server 2000, blev ikke fundet. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSr : SQLSTATE=08001, tilstand=1, Alvor=10, native=126, linje=0).
• For brugere under 100 er det eneste punkt i at opdele det i to separate servere en Win 2008 Std (og ældre) licens, som kun understøtter 32 GB RAM. I alle andre tilfælde skal 1C og SQL helt sikkert installeres på én server og have mere (mindst 64 GB) hukommelse. At give MS SQL mindre end 24-28 GB RAM er uberettiget grådighed (hvis du tror, ​​du har nok hukommelse til det, og alt fungerer fint, ville filversionen af ​​1C måske være nok for dig?)
• Hvor værre kombinationen af ​​1C og SQL virker i en virtuel maskine er emnet i en separat artikel (tip - mærkbart værre). Selv i Hyper-V er alt ikke så klart...
• Afbalanceret ydeevne er dårlig. Resultaterne er helt i overensstemmelse med filversionen.
• Mange kilder siger, at fejlfindingstilstand (ragent.exe -debug) forårsager et betydeligt fald i ydeevnen. Nå, det reducerer, ja, men jeg vil ikke kalde 2-3% en signifikant effekt.

Hovedformålet med at skrive denne artikel er at undgå at gentage åbenlyse nuancer for de administratorer (og programmører), der endnu ikke har fået erfaring med 1C.

Det sekundære mål er, at hvis jeg har nogle mangler, vil Infostart være den hurtigste til at påpege dette over for mig.

V. Gilevs test er allerede blevet en slags "de facto" standard. Forfatteren på sin hjemmeside gav ganske klare anbefalinger, men jeg vil blot præsentere nogle resultater og kommentere de mest sandsynlige fejl. Testresultaterne på dit udstyr kan naturligvis være forskellige, det er blot en guide til, hvad der skal være, og hvad du kan stræbe efter. Jeg vil gerne bemærke med det samme, at ændringer skal foretages trin for trin, og efter hvert trin, tjek hvilket resultat det gav.

Der er lignende artikler om Infostart, jeg vil lægge links til dem i de relevante sektioner (hvis jeg savner noget, så foreslå mig venligst i kommentarerne, jeg tilføjer det). Så lad os antage, at din 1C er langsom. Hvordan kan man diagnosticere problemet, og hvordan man forstår, hvem der har skylden, administratoren eller programmøren?

Indledende data:

Testet computer, hovedmarsvin: HP DL180G6, udstyret med 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Til sammenligning viser Core i3-2100 sammenlignelige resultater i den enkelt-trådede test. Det udstyr, jeg bevidst valgte, var ikke det nyeste; med moderne udstyr er resultaterne mærkbart bedre.

Til test af separate 1C- og SQL-servere, SQL-server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

For at teste et 10 Gbit netværk blev der brugt Intel 520-DA2 adaptere.

Fil version. (databasen er på serveren i en delt mappe, klienter forbinder via netværket, CIFS/SMB-protokol). Algoritme trin for trin:

0. Tilføj Gilevs testdatabase til filserveren i samme mappe som hoveddatabaserne. Vi forbinder fra klientcomputeren og kører testen. Vi husker resultatet.

Det er underforstået, at selv for gamle computere for 10 år siden (Pentium on 775 socket ) tiden fra du klikker på 1C:Enterprise-genvejen til databasevinduets fremkomst bør gå mindre end et minut. ( Celeron = langsom).

Hvis du har en computer, der er værre end en Pentium 775 fatning med 1 GB RAM, så sympatiserer jeg med dig, og det vil være svært for dig at opnå behageligt arbejde på 1C 8.2 i filversionen. Tænk på enten at opgradere (det er på høje tid) eller skifte til en terminal (eller web, i tilfælde af tynde klienter og administrerede formularer) server.

Hvis computeren ikke er værre, kan du sparke administratoren. Kontroller som minimum driften af ​​netværks-, antivirus- og HASP-beskyttelsesdriveren.

Hvis Gilevs test på dette tidspunkt viste 30 "papegøjer" eller højere, men 1C-arbejdsbasen stadig fungerer langsomt, bør spørgsmålene rettes til programmøren.

1. Som en guide til, hvor meget en klientcomputer kan "klemme", kontrollerer vi kun driften af ​​denne computer, uden et netværk. Vi installerer testdatabasen på en lokal computer (på en meget hurtig disk). Hvis klientcomputeren ikke har en normal SSD, oprettes en ramdisk. Indtil videre er den enkleste og gratis Ramdisk enterprise.

For at teste version 8.2 er en 256 MB ramdisk nok, og! Den vigtigste. Efter genstart af computeren, med ramdisken kørende, skulle der være 100-200 MB ledigt på den. Uden en ramdisk skal der derfor være 300-400 MB ledig hukommelse til normal drift.

For at teste version 8.3 er en 256 MB ramdisk nok, men du har brug for mere ledig RAM.

Når du tester, skal du se på processorbelastningen. I et tilfælde tæt på ideelt (ramdisk) indlæser lokal fil 1c 1 processorkerne, når den kører. Derfor, hvis din processorkerne ikke er fuldt lastet under testen, skal du kigge efter svage punkter. Lidt følelsesladet, men generelt korrekt, er processorens indflydelse på driften af ​​1C beskrevet. Blot til reference, selv på moderne Core i3s med høje frekvenser, er tallene 70-80 ret realistiske.

De mest almindelige fejl på dette stadium.

a) Forkert konfigureret antivirus. Der er mange antivirus, indstillingerne for hver er forskellige, jeg vil kun sige, at med korrekt konfiguration forstyrrer hverken nettet eller Kaspersky 1C. Med standardindstillingerne kan cirka 3-5 papegøjer (10-15%) tages væk.

b) Performance mode. Af en eller anden grund er de færreste opmærksomme på dette, men effekten er den mest markante. Hvis du har brug for hastighed, så skal du gøre dette, både på klient- og servercomputere. (Gilev har en god beskrivelse. Den eneste advarsel er, at på nogle bundkort, hvis du slår Intel SpeedStep fra, kan du ikke slå TurboBoost til).

Kort sagt, mens 1C kører, er der meget ventetid på svar fra andre enheder (disk, netværk osv.). Mens du venter på et svar, sænker processoren sin frekvens, hvis ydeevnetilstanden er aktiveret. Et svar kommer fra enheden, 1C (processoren) skal virke, men de første clock-cyklusser er på en reduceret frekvens, derefter stiger frekvensen - og 1C venter igen på et svar fra enheden. Og så - mange hundrede gange i sekundet.

Du kan (og helst) aktivere ydeevnetilstand to steder:

Via BIOS. Deaktiver tilstande C1, C1E, Intel C-state (C2, C3, C4). I forskellige bios kaldes de forskelligt, men betydningen er den samme. Det tager lang tid at søge, en genstart er påkrævet, men hvis du gør det én gang, så kan du glemme det. Hvis du gør alt korrekt i BIOS, vil hastigheden stige. På nogle bundkort kan du konfigurere BIOS-indstillingerne, så Windows ydeevnetilstand ikke spiller en rolle. (Eksempler på BIOS-indstillinger fra Gilev). Disse indstillinger vedrører primært serverprocessorer eller "avancerede" BIOS'er, hvis du ikke har fundet dette, og du IKKE har Xeon, er det okay.

Kontrolpanel - Strømforsyning - Høj ydeevne. Minus - hvis computeren ikke har været serviceret i længere tid, vil den give en højere blæserstøj, varme mere op og forbruge mere energi. Dette er et præstationshonorar.

Sådan kontrolleres, at tilstanden er aktiveret. Start task manager - ydeevne - ressourcemonitor - CPU. Vi venter, indtil processoren er optaget med ingenting.

Disse er standardindstillingerne. I BIOS C-tilstand inkluderet, balanceret strømforbrugstilstand
I BIOS C-tilstand inkluderet, højtydende tilstand For Pentium og Core kan du stoppe der, Du kan stadig presse lidt "papegøjer" ud af Xeon
I BIOS C-tilstand slukket, højtydende tilstand. Hvis du ikke bruger Turbo boost, er det sådan, det skal se ud server tunet til ydeevne

Og nu tallene. Lad mig minde dig om: Intel Xeon 5650, ramdisk. I det første tilfælde viser testen 23,26, i det sidste - 49,5. Forskellen er næsten dobbelt. Tallene kan variere, men forholdet forbliver stort set det samme for Intel Core.

Kære administratorer, I kan kritisere 1C så meget, som I vil, men hvis slutbrugere har brug for hastighed, skal I aktivere højtydende tilstand.

c) Turbo Boost. Først skal du forstå, om din processor f.eks. understøtter denne funktion. Hvis det understøtter, så kan du stadig helt lovligt få en vis ydeevne. (Jeg ønsker ikke at røre ved problemerne med frekvensoverclocking, især servere, gør det på egen risiko og risiko. Men jeg er enig i, at øget bushastighed fra 133 til 166 giver en meget mærkbar stigning i både hastighed og varmeafledning)

Hvordan man slår turbo boost til, skrives f.eks. Men! For 1C er der nogle nuancer (ikke de mest indlysende). Vanskeligheden er, at den maksimale effekt af turboboost opstår, når C-tilstand er tændt. Og vi får noget som dette:

Bemærk venligst, at multiplikatoren er den maksimale, kernehastigheden er smuk, og ydeevnen er høj. Men hvad vil der ske som et resultat med 1'ere?

Men i sidste ende viser det sig, at ifølge CPU-ydelsestests er versionen med en multiplikator på 23 foran, ifølge Gilevs test i filversionen er ydeevnen med en multiplikator på 22 og 23 den samme, men i klient-serveren version - versionen med en multiplikator på 23 er forfærdelig frygtelig forfærdelig (selvom C -state sat til niveau 7, er den stadig langsommere end med C-state slået fra). Derfor er anbefalingen selv at tjekke begge muligheder og vælge den bedste. Under alle omstændigheder er forskellen mellem 49,5 og 53 papegøjer ret betydelig, især uden større indsats.

Konklusion - turbo boost skal være slået til. Lad mig minde dig om, at det ikke er nok at aktivere Turbo boost-elementet i BIOS, du skal også se på andre indstillinger (BIOS: QPI L0s, L1 - deaktiver, kræve skrubning - deaktiver, Intel SpeedStep - enable, Turbo boost - aktiver Kontrolpanel - Strømstyring - Høj ydeevne) . Og jeg ville stadig (selv for filversionen) vælge den mulighed, hvor c-state er slået fra, selvom multiplikatoren er mindre. Det vil vise sig noget som dette...

Et ret kontroversielt punkt er hukommelsesfrekvensen. For eksempel har hukommelsesfrekvens vist sig at have en meget stærk indflydelse. Mine tests afslørede ikke en sådan afhængighed. Jeg vil ikke sammenligne DDR 2/3/4, jeg vil vise resultaterne af at ændre frekvensen inden for samme linje. Hukommelsen er den samme, men i BIOS er vi tvunget til at indstille lavere frekvenser.

Og testresultater. 1C 8.2.19.83, for filversionen lokal ramdisk, for klient-server 1C og SQL på én computer, delt hukommelse. Turbo boost er deaktiveret i begge versioner. 8.3 viser sammenlignelige resultater.

Forskellen ligger inden for målefejlen. Jeg trak specifikt skærmbilleder af CPU-Z for at vise, at med en ændring i frekvens, ændres andre parametre også, den samme CAS Latency og RAS til CAS Delay, som neutraliserer ændringen i frekvensen. Forskellen vil være, når hukommelsesmodulerne fysisk ændres, fra langsommere til hurtigere, men selv der er tallene ikke særligt markante.

2. Når vi har sorteret processoren og hukommelsen på klientcomputeren, går vi videre til det næste meget vigtige sted - netværket. Der er skrevet mange bind af bøger om netværksindstilling, der er artikler om Infostart ( og andre), men her vil jeg ikke fokusere på dette emne. Før du begynder at teste 1C, skal du sørge for, at iperf mellem to computere viser hele båndbredden (for 1 Gbit-kort - godt, mindst 850 Mbit, eller endnu bedre 950-980), som Gilevs råd er blevet fulgt. Så - den enkleste test af driften vil mærkeligt nok være at kopiere en stor fil (5-10 gigabyte) over netværket. Et indirekte tegn på normal drift på et 1 Gbit netværk vil være den gennemsnitlige kopieringshastighed på 100 MB/sek., god drift - 120 MB/sek. Jeg vil gerne henlede din opmærksomhed på, at det svage punkt (inklusive) kan være processorbelastningen. SMB Protokollen på Linux er ret dårligt paralleliseret, og under drift kan den ganske let "spise" en processorkerne og ikke forbruge mere.

Og videre. Med standardindstillingerne fungerer Windows-klienten bedst med en Windows-server (eller endda en Windows-arbejdsstation) og SMB/CIFS-protokollen, en linux-klient (debian, ubuntu kiggede ikke på de andre) fungerer bedre med linux og NFS ( det virker også med SMB, men på NFS er papegøjer højere). Det faktum, at en Windows Linux-server til NFS under lineær kopiering kopieres til én strøm hurtigere, betyder ikke noget. Debian tuning for 1C er et emne for en separat artikel, jeg er ikke klar til det endnu, selvom jeg kan sige, at i filversionen fik jeg endnu lidt bedre ydeevne end Win-versionen på samme udstyr, men med postgres med over 50 brugere Jeg har stadig alt meget dårligt.

Den vigtigste , som "brændte" administratorer kender, men begyndere tager ikke hensyn til. Der er mange måder at indstille stien til 1c-databasen på. Du kan gøre \\server\share, du kan gøre \\192.168.0.1\share, du kan nettobruge z: \\192.168.0.1\share (og i nogle tilfælde vil denne metode også fungere, men ikke altid) og derefter specificer Z-drevet. Det ser ud til, at alle disse stier peger til det samme sted, men for 1C er der kun én måde, der giver normal ydeevne ganske pålideligt. Så dette er hvad du skal gøre korrekt:

På kommandolinjen (eller i politikker, eller hvad der er praktisk for dig) - brug net DriveLetter: \\server\share. Eksempel: netbrug m: \\server\baser. Jeg fremhæver specifikt IKKE IP-adressen, nemlig Navn server. Hvis servernavnet ikke er synligt, skal du tilføje det til dns på serveren eller lokalt til hosts-filen. Men adressen skal være ved navn. Følgelig, på vej til databasen, få adgang til denne disk (se billede).

Og nu vil jeg vise med tal, hvorfor dette er rådet. Indledende data: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169-kort. OS Win 2008 R2, Win 7, Debian 8. Seneste drivere, opdateringer anvendt. Inden jeg testede, sikrede jeg mig, at Iperf giver den fulde båndbredde (bortset fra 10 Gbit-kort, lykkedes det kun at presse 7,2 Gbit ud, jeg skal se hvorfor senere, testserveren er endnu ikke konfigureret korrekt). Diskene er forskellige, men overalt er der en SSD (jeg indsatte specielt en enkelt disk til test, den er ikke indlæst med andet) eller et raid fra en SSD. Hastigheden på 100 Mbit blev opnået ved at begrænse indstillingerne for Intel 362-adapteren. Der var ingen forskel mellem 1 Gbit kobber Intel 350 og 1 Gbit optisk Intel X520-DA2 (opnået ved at begrænse hastigheden på adapteren). Maksimal ydeevne, turbo boost er slået fra (bare for sammenlignelighed af resultater, turbo boost for gode resultater tilføjer lidt mindre end 10%, for dårlige resultater kan det ikke have nogen effekt overhovedet). Version 1C 8.2.19.86, 8.3.6.2076. Jeg giver ikke alle tallene, men kun de mest interessante, så du har noget at sammenligne med.

Konklusioner (fra tabellen og fra personlig erfaring. Gælder kun for filversionen):

Over netværket kan du få helt normale tal for arbejde, hvis dette netværk er korrekt konfigureret og stien er indtastet korrekt i 1C. Selv den første Core i3 kan sagtens producere 40+ papegøjer, hvilket er ret godt, og det er ikke kun papegøjer, i rigtigt arbejde er forskellen også mærkbar. Men! Begrænsningen ved arbejde med flere (mere end 10) brugere vil ikke længere være netværket, her er 1 Gbit stadig nok, men blokering under flerbrugerarbejde (Gilev).

1C 8.3 platformen er mange gange mere krævende med hensyn til korrekt netværkskonfiguration. Grundindstillinger - se Gilev, men husk at alt kan påvirkes. Jeg så en acceleration fra at afinstallere (og ikke bare slukke) antivirus, fra at fjerne protokoller som FCoE, fra at ændre drivere til en ældre, men Microsoft-certificeret version (især for billige kort som ASUS og DLC), fra at fjerne det andet netværkskort fra serveren. Der er mange muligheder, sæt dit netværk omhyggeligt op. Der kan meget vel være en situation, hvor platform 8.2 giver acceptable tal, og 8.3 - to eller endda flere gange mindre. Prøv at spille med platform version 8.3, nogle gange får du en meget stor effekt.

1C 8.3.6.2076 (måske senere, jeg har ikke ledt efter den nøjagtige version endnu) er stadig nemmere at konfigurere over netværket end 8.3.7.2008. Jeg var i stand til at opnå normal drift over netværket fra 8.3.7.2008 (i sammenlignelige papegøjer) kun et par gange; jeg kunne ikke gentage det for et mere generelt tilfælde. Jeg forstod ikke meget, men at dømme efter fodindpakningerne fra Process Explorer er optagelsen der ikke så god som i 8.3.6.

På trods af det faktum, at når du arbejder på et 100 Mbit-netværk, er dets belastningsplan lille (vi kan sige, at netværket er gratis), er driftshastigheden stadig meget mindre end på 1 Gbit. Årsagen er netværksforsinkelse.

Alt andet lige (et velfungerende netværk) for 1C 8.2 er Intel-Realtek-forbindelsen 10% langsommere end Intel-Intel. Men realtek-realtek kan generelt give skarpe sætninger ud af det blå. Derfor, hvis du har penge, er det bedre at opbevare Intel-netværkskort overalt; hvis du ikke har penge, så installer kun Intel på serveren (din CO). Og der er mange gange flere instruktioner til tuning af Intel-netværkskort.

Standard antivirusindstillinger (bruger drweb version 10 som eksempel) fylder omkring 8-10% af papegøjer. Hvis du konfigurerer det som det skal (lader 1cv8-processen gøre alt, selvom det ikke er sikkert), er hastigheden den samme som uden et antivirus.

Læs IKKE Linux-guruer. En server med samba er fantastisk og gratis, men hvis du installerer Win XP eller Win7 (eller endnu bedre - server OS) på serveren, så fungerer filversionen af ​​1c hurtigere. Ja, samba og protokolstakken og netværksindstillinger og meget, meget mere kan godt indstilles i debian/ubuntu, men dette anbefales til specialister. Det nytter ikke at installere Linux med standardindstillinger og så sige, at det er langsomt.

Det er en ganske god idé at kontrollere driften af ​​diske, der er tilsluttet via netbrug ved hjælp af fio . Det vil i hvert fald fremgå, om det er problemer med 1C platformen, eller med netværket/disken.

For enkeltbrugerversionen kan jeg ikke komme i tanke om test (eller en situation), hvor forskellen mellem 1 Gbit og 10 Gbit ville være synlig. Det eneste, hvor 10Gbit til filversionen gav bedre resultater, er tilslutning af diske via iSCSI, men dette er et emne for en separat artikel. Alligevel tror jeg, at til filversionen er 1 Gbit-kort nok.

Jeg forstår ikke, hvorfor 8.3 med et 100 Mbit-netværk virker mærkbart hurtigere end 8.2, men det var en kendsgerning. Alt andet udstyr, alle andre indstillinger er absolut de samme, det er bare, at i det ene tilfælde er 8.2 testet, og i det andet - 8.3.

Ikke-tunet NFS win-win eller win-lin giver 6 papegøjer, jeg har ikke inkluderet dem i tabellen. Efter tuning fik jeg 25, men den var ustabil (forskellen i mål var mere end 2 enheder). Jeg kan endnu ikke give anbefalinger om brug af Windows og NFS-protokollen.

Efter alle indstillinger og kontroller kører vi testen igen fra klientcomputeren og glæder os over det forbedrede resultat (hvis det virker). Hvis resultatet er forbedret, er der mere end 30 papegøjer (og især mere end 40), færre end 10 brugere arbejder på samme tid, og arbejdsdatabasen er stadig langsom - næsten helt sikkert et problem med programmøren (eller du har allerede nået topkapaciteten af ​​filversionen).

Terminal server. (databasen er på serveren, klienter forbinder via netværket, RDP-protokol). Algoritme trin for trin:

0. Tilføj Gilevs testdatabase til serveren i samme mappe som hoveddatabaserne. Vi forbinder fra den samme server og kører testen. Vi husker resultatet.

1. På samme måde som i filversionen sætter vi værket op. I tilfælde af en terminalserver spiller processoren generelt hovedrollen (det antages, at der ikke er nogen åbenlyse svage punkter, såsom mangel på hukommelse eller en enorm mængde unødvendig software).

2. Opsætning af netværkskort i tilfælde af en terminalserver har stort set ingen indflydelse på driften af ​​1c. For at sikre "særlig" komfort, hvis din server producerer mere end 50 papegøjer, kan du lege med nye versioner af RDP-protokollen, blot for brugernes komfort, hurtigere respons og rulning.

3. Hvis et stort antal brugere aktivt arbejder (og her kan du allerede prøve at forbinde 30 personer til én database, hvis du prøver), er det meget tilrådeligt at installere et SSD-drev. Af en eller anden grund menes det, at disken ikke påvirker driften af ​​1C i særlig grad, men alle test udføres med controller-cachen aktiveret til skrivning, hvilket er forkert. Testbasen er lille, den passer ret godt i cachen, deraf de høje tal. På rigtige (store) databaser vil alt være helt anderledes, så cachen er deaktiveret til test.

For eksempel tjekkede jeg driften af ​​Gilev-testen med forskellige diskmuligheder. Jeg installerede skiverne fra det, der var ved hånden, bare for at vise tendensen. Forskellen mellem 8.3.6.2076 og 8.3.7.2008 er lille (i Ramdisk Turbo boost version 8.3.6 producerer 56.18 og 8.3.7.2008 producerer 55.56, i andre test er forskellen endnu mindre). Strømforbrug - maksimal ydeevne, turbo boost deaktiveret (medmindre andet er angivet).

Den aktiverede RAID-controller-cache eliminerer alle forskellene mellem diskene; tallene er de samme for både sat og cas. Test med det på en lille mængde data er nytteløst og er ikke vejledende af nogen art.

For platform 8.2 er forskellen i ydeevne mellem SATA- og SSD-muligheder mere end det dobbelte. Dette er ikke en tastefejl. Hvis du ser på ydeevnemonitoren under testen på SATA-drev. så kan du tydeligt se "Aktiv diskdriftstid (i%)" 80-95. Ja, hvis du aktiverer cachen på selve diskene til optagelse, vil hastigheden stige til 35, hvis du aktiverer cachen på raid-controlleren - op til 49 (uanset hvilke diske der testes i øjeblikket). Men disse er syntetiske cache-papegøjer; i virkeligt arbejde, med store databaser, vil der aldrig være et 100% skrive-cache-hitforhold.

Hastigheden på selv billige SSD'er (jeg testede på Agility 3) er ganske nok til at køre filversionen. Optagelsesressourcen er en anden sag, du skal se på den i hvert enkelt tilfælde, det er klart, at Intel 3700 vil have det en størrelsesorden højere, men prisen er tilsvarende. Og ja, jeg forstår, at når jeg tester en SSD-disk, tester jeg også cachen på denne disk i højere grad, de reelle resultater bliver mindre.

Den mest korrekte (fra mit synspunkt) løsning ville være at allokere 2 SSD-diske i et spejlvendt raid til en fildatabase (eller flere fildatabaser), og ikke placere andet der. Ja, med et spejl slides SSD'er lige meget, og det er et minus, men i det mindste er controllerelektronikken på en eller anden måde beskyttet mod fejl.

De vigtigste fordele ved SSD-drev til filversionen vises, når der er mange databaser, hver med flere brugere. Hvis der er 1-2 databaser, og der er omkring 10 brugere, så vil SAS-diske være nok. (men under alle omstændigheder, se på at indlæse disse diske, i det mindste gennem perfmon).

De vigtigste fordele ved en terminalserver er, at den kan have meget svage klienter, og netværksindstillingerne påvirker terminalserveren meget mindre (igen din K.O.).

Konklusioner: hvis du kører Gilev-testen på en terminalserver (fra den samme disk, hvor arbejdsdatabaserne er placeret), og på de tidspunkter, hvor arbejdsdatabasen sænker farten, og Gilev-testen viser et godt resultat (over 30), så langsom drift af den vigtigste arbejdsdatabase er sandsynligvis skylden for en programmør.

Hvis Gilevs test viser små tal, og du har en processor med højt ur og hurtige diske, så skal administratoren i det mindste tage perfmon, registrere alle resultaterne et sted og se, observere og drage konklusioner. Der vil ikke være nogen endelig rådgivning.

Klient-server mulighed.

Test blev kun udført den 8.2, fordi på 8.3 afhænger alt ganske alvorligt af versionen.

Til test valgte jeg forskellige serverindstillinger og netværk mellem dem for at vise de vigtigste tendenser.

Det ser ud til, at jeg har overvejet alle de interessante muligheder, hvis der er andet, du er interesseret i, så skriv i kommentarerne, jeg vil prøve at gøre det.

SAS på lagersystemer er langsommere end lokale SSD'er, selvom lagersystemerne har større cachestørrelser. SSD'er, både lokale og på lagersystemer, fungerer ved sammenlignelige hastigheder til Gilevs test. Jeg kender ikke nogen standard multi-threaded test (ikke kun optagelse, men alt udstyr) bortset fra 1C belastningstesten fra MCC.

Ændring af 1C-serveren fra 5520 til 5650 fordoblede næsten ydeevnen. Ja, serverkonfigurationerne stemmer ikke helt overens, men det viser en tendens (ingen overraskelse).

At øge frekvensen på SQL-serveren giver bestemt en effekt, men ikke den samme som på 1C-serveren; MS SQL-serveren er fremragende (hvis du spørger det) til at bruge multi-cores og fri hukommelse.

Ændring af netværket mellem 1C og SQL fra 1 Gbit til 10 Gbit giver cirka 10 % papegøjer. Jeg forventede mere.

Aktivering af delt hukommelse giver stadig en effekt, dog ikke 15 %, som beskrevet. Sørg for at gøre det, heldigvis er det hurtigt og nemt. Hvis nogen under installationen gav SQL-serveren en navngivet instans, så for at 1C skal virke, skal servernavnet ikke angives af FQDN (tcp/ip vil fungere), ikke gennem localhost eller kun ServerName, men gennem ServerName\InstanceName, for eksempel zz-test\zztest. (Ellers vil der være en DBMS-fejl: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Det delte hukommelsesbibliotek, der blev brugt til at etablere en forbindelse med SQL Server 2000, blev ikke fundet. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSr : SQLSTATE=08001, tilstand=1, Alvor=10, native=126, linje=0).

For mindre end 100 brugere er det eneste punkt i at opdele det i to separate servere en Win 2008 Std (og ældre) licens, som kun understøtter 32 GB RAM. I alle andre tilfælde skal 1C og SQL helt sikkert installeres på én server og have mere (mindst 64 GB) hukommelse. At give MS SQL mindre end 24-28 GB RAM er uberettiget grådighed (hvis du tror, ​​du har nok hukommelse til det, og alt fungerer fint, ville filversionen af ​​1C måske være nok for dig?)

Hvor værre kombinationen af ​​1C og SQL virker i en virtuel maskine er emnet i en separat artikel (tip - mærkbart værre). Selv i Hyper-V er alt ikke så klart...

Afbalanceret ydeevne er dårlig. Resultaterne er helt i overensstemmelse med filversionen.

Mange kilder siger, at fejlfindingstilstand (ragent.exe -debug) forårsager et betydeligt fald i ydeevnen. Nå, det reducerer, ja, men jeg vil ikke kalde 2-3% en signifikant effekt.

1C-systemet er i dag et af de vigtigste værktøjer til at drive små og mellemstore virksomheder. Som regel har alle medarbejdere i organisationen adgang til programmet. Hvis 1C begynder at sænke farten eller arbejde langsomt, så påvirker dette i høj grad forretningsførelsen. Lad os se på, hvordan du selv kan fremskynde og optimere arbejdet i 1C.

Optimering ved hjælp af 1C-opdatering

Nye versioner af 1C fungerer altid mere vellykket og hurtigere, så det er bydende nødvendigt at følge opdateringerne. Det anbefales at opdatere dit regnskab så ofte som muligt. Især når versioner af reguleret rapportering frigives.

Mange mennesker har brugt muligheden for automatisk at opdatere programmet i lang tid. Selvom dette problem nemt kan løses manuelt for 1C Enterprise 8.3, vil en opdatering ikke forårsage nogen problemer.

Det første trin er at downloade den seneste version af den platform, du bruger i øjeblikket. Dette gøres enten ved hjælp af ITS-disken, eller via webgrænsefladen, hvor de yder løbende support til brugere af et program som 1c Enterprise 8.3, en konfigurationsopdatering, som der også leveres officielt til.

I sidstnævnte tilfælde downloades arkivet med opdateringsdata separat. Den pakkes ud i enhver mappe, der anses for at være mest bekvem for brugeren. Derefter skal du køre .exe-filen. I det næste vindue skal du blot klikke på knappen "Næste".

En anden side vises. På den vælger brugeren stien, hvor installationen er fuldført. Men dette trin anbefales kun til avancerede personlige computerejere. Standardfunktionerne er normalt tilstrækkelige til at løse de fleste problemer. Som standard er der i dette tilfælde angivet én mappe, hvor alle opdateringer installeres på én gang. Dette er meget mere bekvemt, end når de endelige veje er anderledes. Vi klikker blot på "Næste"-knapperne flere gange i 1c Enterprise 8.3-programmet, hvis konfiguration skal opdateres hurtigt.

Tilbage er den sidste knap, som tilbyder "Installer".

Sådan øger du 1C, hvis platformen er langsom

Problemer skyldes oftest det faktum, at kunstnerens koncentration af opmærksomhed falder på et af stadierne. Her er det vigtigt at vælge det rigtige opdateringsskema, kun i dette tilfælde vil vi ikke støde på et problem, når 1c fryser under opdateringen.

Opdatering til version 7.7

Der er flere typer konfiguration. Afhængigt af dette vælges forløbet for yderligere handlinger.

• Standard – i dette tilfælde forudsættes opdateringen også for reguleret indberetning.
• Typiske industrikonfigurationer minder i høj grad om tidligere muligheder. Det er vigtigt at læse instruktionerne fra udvikleren på forhånd. Ellers vil du ikke kunne finde ud af, hvorfor 1C 8.3 går ned under opdateringen.
• Ændret standard - brugeren har altid mulighed for selv at ændre applikationen, så den opfylder aktuelle behov. En anden mulighed for at udvide funktionaliteten er at flytte til nye platforme. For eksempel version 8.

Om version 8.0 og 8.1

I øjeblikket er platform 8.0 allerede trukket tilbage fra support. Nye standardudviklinger fungerer kun, når de nyeste versioner bruges. Du skal bare huske, at alle mellemliggende udgivelser er gennemført uden fejl. Ellers er der stor sandsynlighed for blot at miste information. Eller støder på en situation, hvor 1c fryser, når konfigurationen opdateres.

En mulighed er mulig, når en ny standardkonfiguration implementeres, og derefter overføres resterne fra de gamle informationsdatabaser til den.

Hvad angår version 8.1, kan du opdatere til den på flere måder:

1. manuelt;
2. i automatisk tilstand;
3. kontakte specialister fra virksomheder, der leverer tjenester på dette område.

Arbejder med ikke-standardiserede eller modificerede versioner

I første omgang refererer enhver konfiguration til standardudviklinger. Det ophører med at være sådan, hvis der foretages visse ændringer i virksomheden. For eksempel under installationen. Der er to klasser, der skiller sig ud blandt ikke-standardkonfigurationer:

1. ændret;
2. skabt fra bunden under hensyntagen til en specifik virksomheds behov.

Nogle gange distribueres en andenklasses konfiguration aktivt blandt brugerne. Så betragtes det som typisk. Det er bare, at producenten ikke anses for at være 1C selv, men det firma, der har skabt den nye version.

Konfigurationer kan holdes ajour med følgende handlinger:

• Fejlretning.
• Udvidelse af funktionalitet.
• Forbedring.
• Ændring i 1C 8.3, konfigurationen opdateres ikke i tilfælde af vedligeholdelsesfejl.

Installationsprocessen kan tage forskellige tider, afhængigt af den internethastighed, du bruger den med i øjeblikket. I et separat vindue vælger brugeren, om der skal opdateres efter endt arbejde eller med det samme. Med sidstnævnte mulighed skal du sikre dig, at ingen andre arbejder med applikationen. Selve processen involverer brugen af ​​eksklusiv tilstand i 1c Enterprise 8.3-applikationen, den seneste opdatering er ingen undtagelse.

• Vi skal huske, at ikke alle udgivelsesversioner er egnede til den aktuelle konfiguration.
• Hvis opdateringer ikke er blevet udført i lang tid, skal du muligvis downloade flere filer eller arkiver på én gang.
• På listen er det let at forstå, hvilken version af 1C Enterprise 8.3 der er behov for, opdateringen vælges af brugeren.

Når processen er afsluttet, kan selve konfiguratoren lukkes. Denne tilstand bruges oftest, hvis en opdatering er nødvendig. Det er praktisk og automatiserer næsten hele processen. Når du starter den for første gang, vises der muligvis en meddelelse, der indikerer, at platformen er forældet. Og at det ikke anbefales at bruge det på nuværende tidspunkt.

Yderligere årsager til bremsning

Hvis programmet er opdateret korrekt og uden fejl, sænker 1C dog stadig farten, så kan årsagen være følgende:

• Antivirus - hvis det er konfigureret korrekt, vil ingen antivirus forstyrre systemet, men hvis du bruger fabriksindstillingerne, kan 1C-ydeevnen falde med 5-10 %. Du kan optimere dit antivirus ved at bruge yderligere indstillinger ved at fjerne baggrundstilstanden (hvis det er absolut nødvendigt).
• Computerparametre - ofte utilstrækkeligt kraftige computere fører til et betydeligt fald i 1C-ydeevne. Der skal lægges særlig vægt på videokortet, operativsystemet og processoren.

Sådanne metoder vil væsentligt optimere og fremskynde arbejdet i 1C for enhver virksomhed eller virksomhed, hvorefter programmets ydeevne vil stige betydeligt.

Materiale opdateret

Kursus optaget på version 8.3 ved brug af MS SQL Server 2014 Og seneste versioner produktivitetsværktøjer med en detaljeret beskrivelse af nye indstillinger og muligheder.

Hvori arbejde med 8.2 er også beskrevet i kurset.

To nye sektioner: "Test" og "Backup"

Afsnittet "Test" dækker både test ved hjælp af Test Center-konfigurationen og automatiseret test. Derudover overvejes spørgsmål vedrørende testudstyr.

Afsnittet "Sikkerhedskopiering" diskuterer problemerne med at oprette sikkerhedskopier fra bunden ved hjælp af MS SQL Server som eksempel. Det giver også oplysninger om gendannelsesmodeller, hvordan de fungerer, og hvordan de relaterer til backup.

Materialeformatet har ændret sig

Den kan bruges til hurtigt at finde information om et hvilket som helst af de emner, der er behandlet på kurset, og kan også bruges som reference, hvis du støder på præstationsproblemer.

Kurset er blevet meget mere detaljeret

Flere detaljer og tekniske detaljer er blevet tilføjet om alle emner, hvilket vil være meget nyttigt til forberedelse til 1C: Eksperteksamen og test for 1C: Professional om teknologiske spørgsmål.

• Tilføjet lektioner på håndtering af undtagelser i en transaktion
• Tilføjet information vedr hensigtslåse
• Tilføjet parallelitetstabel når du bruger PostgreeSQL
• Eksempel tilføjet rydde dødvande ved hjælp af en teknologilog
• Tilføjet information om parallel drift af metadataobjekter i forskellige tilstande med forskellige indstillinger.
• Tilføjet information om ny type dødvande
• Tilføjet detaljeret beskrivelse 1C serverklyngeenheder, herunder en beskrivelse af de vigtigste servicefiler
• Opdateret løse problemer for at forberede sig til 1C:Expert
• Tilføjet unik behandling, som giver dig mulighed for at se, hvilke poster mht. metadata der i øjeblikket er blokeret
• Tilføjet hel backup sektion
• Tilføjet information vedr mekanisme til lagring og genfinding af resultater
• Tilføjet information om låsens levetid i forskellige transaktionsisolationsniveauer
• Tilføjet information om udførelse belastningstest og valg af passende udstyr
• Tilføjet information om brug af mekanismen automatiseret test
• Tilføjet information om sorterings indflydelse på ydeevnen anmodninger
• Tilføjet information om arbejde dynamiske lister
• Tilføjet information vedr anbefalede teknikker programmering
• Tilføjet nyttige scripts og dynamiske visninger

Tilføjet nye praktiske opgaver

Mange af de tilføjede opgaver er baseret på virkelige situationer fra optimeringsprojekter.

Også tilføjet opdateret afsluttende opgave, som er blevet endnu mere kompleks og interessant.

Master gruppe støtte

Support ydes på kursusaktivitetssiderne. Du kan stille ethvert spørgsmål om kursusmaterialerne.

Også dig få adgang til hundredvis af spørgsmål og svar på dem fra andre kursister.

Varighed af støtte: op til 4 måneder(afhængig af den valgte version af kurset).

Du kan aktivere adgang til mastergruppen i nogen bekvemt tidspunkt inden for 100 dage fra købsdatoen.

Krav til deltagere

Der er ingen særlige krav til kursister.

For at gennemføre kurset med succes skal du have mindst minimal erfaring med 1C-udvikling.

Du skal bruge en computer med 1C 8.3 og Windows

Den beskyttede afspiller til visning af videomaterialer fungerer kun i Windows-miljøer. Videovisning er ikke mulig i virtuelle miljøer eller med fjernadgangsværktøjer.

Kursus- og omkostningsversioner

Dette kursus har TRE versioner: LITE, PROF, ULTIMAT.

De adskiller sig i formål, indhold, omkostninger og vilkår for støtte i Master Group.

For købere af kurset Diagnosticering af præstationsproblemer

Prisen for kurset "Diagnostik af 1C ydeevneproblemer: hvad er det præcist, der bremser systemet" vil være tælle ved køb af kurset “Acceleration og optimering af systemer på 1C:Enterprise 8.3”.

Du afgiver blot en bestilling på den relevante version af Optimeringskurset, og i rækkefølgen angiver du den rabatkode, der blev sendt til dig efter køb af kurset “Diagnostik af præstationsproblemer”.

For eksempel, under hensyntagen til rabatten, vil LITE-versionen koste 11.300 9.800 rubler.

Garanti

Vi har undervist siden 2008, vi er sikre på kvaliteten af ​​vores kurser og giver vores standard 60 dages garanti.

Det betyder, at hvis du er begyndt at tage vores kursus, men pludselig ombestemmer dig (eller f.eks. ikke har mulighed), så har du 60 dages frist til at træffe en beslutning – og hvis du vender tilbage, returnerer vi 100,- % af betalingen.

Ratebetaling

Vores kurser kan betales i rater eller i rater, herunder uden renter. Hvori Du får øjeblikkelig adgang til materialer.

Dette er muligt med betalinger fra enkeltpersoner på et beløb på 3.000 RUB eller mere. op til 150.000 gnid.

Alt du skal gøre er at vælge betalingsmetoden "Betaling via Yandex.Checkout". Dernæst, på betalingssystemets hjemmeside, vælg "Betal i rater", angiv betalingsperioden og beløbet, udfyld en kort formular - og om et par minutter vil du modtage en afgørelse.

Betalingsmuligheder

Vi accepterer alle større betalingsformer.

Fra enkeltpersoner– betalinger fra kort, betalinger med elektroniske penge (WebMoney, YandexMoney), betalinger via internetbank, betalinger via kommunikationsbutikker og så videre. Det er også muligt at betale for ordren i rater (i rater), herunder uden yderligere renter.

Begynd at afgive din ordre – og i andet trin kan du vælge din foretrukne betalingsmetode.

Fra organisationer og individuelle iværksættere– kontantfri betaling, leveringsdokumenter leveres. Du indtaster en ordre, og du kan straks printe en faktura til betaling.

Uddannelse af flere medarbejdere

Vores kurser er designet til individuel læring. Gruppetræning på ét sæt er ulovlig distribution.

Hvis en virksomhed har brug for at uddanne flere medarbejdere, tilbyder vi typisk "tillægssæt", der koster 40 % mindre.

For at bestille et "ekstra sæt" vælg 2 eller flere kursussæt i formularen, startende fra andet sæt prisen for kurset vil være 40% billigere.

Der er tre betingelser for at bruge yderligere sæt:

• Du kan ikke kun købe et ekstra sæt, hvis mindst ét ​​almindeligt sæt ikke er købt før (eller sammen med det)
• Der er ingen andre rabatter for yderligere sæt (de er allerede nedsat, det ville være en "rabat på en rabat")
• kampagner er ikke gyldige for yderligere sæt (for eksempel kompensation på 7.000 rubler) af samme grund