Få fart på arbeidet 1s kompleks automatisering. Medlemskrav

Nylig har brukere og administratorer i økende grad begynt å klage over at nye 1C-konfigurasjoner utviklet på grunnlag av en administrert applikasjon er trege, i noen tilfeller uakseptabelt sakte. Det er tydelig at nye konfigurasjoner inneholder nye funksjoner og muligheter, og derfor er mer ressurskrevende, men de fleste brukere har ikke forståelse for hva som primært påvirker driften av 1C i filmodus. La oss prøve å fikse dette gapet.

I vår har vi allerede berørt virkningen av ytelsen til diskdelsystemet på hastigheten til 1C, men denne studien gjaldt lokal bruk av applikasjonen på en separat PC eller terminalserver. Samtidig innebærer de fleste små implementeringer å jobbe med en filbase over et nettverk, hvor en av brukerens PC-er brukes som server, eller en dedikert filserver basert på en vanlig, som oftest også rimelig, datamaskin.

En liten studie av russiskspråklige ressurser på 1C viste at dette problemet omgås flittig; i tilfelle problemer anbefales det vanligvis å bytte til klient-server- eller terminalmodus. Og det har også blitt nesten allment akseptert at konfigurasjoner på en administrert applikasjon fungerer mye tregere enn vanlige. Som regel blir argumenter gitt "jern": "her regnskap 2.0 bare fløy, og" troikaen "beveger seg knapt, selvfølgelig, det er noe sannhet i disse ordene, så la oss prøve å finne ut av det.

Ressursforbruk på et øyeblikk

Før vi starter denne studien, satte vi oss to mål: å finne ut om administrerte applikasjonsbaserte konfigurasjoner faktisk er tregere enn konvensjonelle konfigurasjoner, og hvilke ressurser som har størst innvirkning på ytelsen.

For testing tok vi to virtuelle maskiner som kjører henholdsvis Windows Server 2012 R2 og Windows 8.1 med 2 kjerner av vertens Core i5-4670 og 2 GB RAM, som tilsvarer en gjennomsnittlig kontormaskin. Serveren ble plassert på en RAID 0-array med to, og klienten ble plassert på en lignende rekke generelle disker.

Som eksperimentelle baser har vi valgt flere konfigurasjoner av Accounting 2.0, utgivelse 2.0.64.12 , som deretter ble oppdatert til 3.0.38.52 , ble alle konfigurasjoner kjørt på plattformen 8.3.5.1443 .

Det første som tiltrekker seg oppmerksomhet er den økte størrelsen på informasjonsbasen til troikaen, og den har vokst betydelig, så vel som mye større appetitt på RAM:

Vi er allerede klare til å høre det vanlige: "hva la de til denne trioen", men la oss ikke forhaste oss. I motsetning til brukere av klient-serverversjoner, som krever en mer eller mindre kvalifisert administrator, tenker brukere av filversjoner sjelden på databasevedlikehold. Også ansatte i spesialiserte firmaer som betjener (les - oppdatering) disse basene tenker sjelden på det.

I mellomtiden er 1C-informasjonsbasen en fullverdig DBMS i sitt eget format, som også krever vedlikehold, og for dette er det til og med et verktøy som heter Tester og fikser infobasen. Kanskje spilte navnet en grusom spøk, som ser ut til å antyde at dette er et verktøy for feilsøking, men dårlig ytelse er også et problem, og restrukturering og reindeksering, sammen med tabellkomprimering, er velkjente databaseoptimeringsverktøy for enhver RDBMS-administrator. La oss sjekke?

Etter å ha brukt de valgte handlingene, "gikk databasen dramatisk ned i vekt", og ble enda mindre enn de "to", som ingen noen gang har optimalisert heller, og forbruket av RAM gikk også litt ned.

Deretter, etter å ha lastet nye klassifiserere og kataloger, opprettet indekser, etc. størrelsen på basen vil vokse, generelt er basene til de "tre" større enn basene til de "to". Dette er imidlertid ikke viktigere, hvis den andre versjonen var fornøyd med 150-200 MB RAM, trenger den nye utgaven en halv gigabyte allerede, og denne verdien bør tas i betraktning når du planlegger de nødvendige ressursene for å jobbe med programmet .

Nett

Nettverksbåndbredde er en av de viktigste parameterne for nettverksapplikasjoner, spesielt som 1C i filmodus, som flytter betydelige mengder data over nettverket. De fleste nettverk av små bedrifter er bygget på grunnlag av billig 100 Mbps utstyr, så vi begynte å teste ved å sammenligne ytelsesindikatorene til 1C i 100 Mbps og 1 Gbps nettverk.

Hva skjer når du starter 1C-filbasen over nettverket? Klienten laster ned en ganske stor mengde informasjon til midlertidige mapper, spesielt hvis dette er den første "kalde" lanseringen. Ved 100 Mbps, vi forventes å kjøre inn i båndbredden og nedlasting kan ta en betydelig mengde tid, i vårt tilfelle, omtrent 40 sekunder (prisen på grafdelingen er 4 sekunder).

Den andre lanseringen er raskere, siden noen av dataene er lagret i hurtigbufferen og forblir der til omstart. Overgangen til et gigabit-nettverk kan øke belastningen av programmet betydelig, både "kaldt" og "varmt", og forholdet mellom verdier blir observert. Derfor bestemte vi oss for å uttrykke resultatet i relative termer, og tar den største verdien av hver måling som 100 %:

Som du kan se av grafene, laster Accounting 2.0 dobbelt så raskt ved hvilken som helst nettverkshastighet, overgangen fra 100 Mbps til 1 Gbps lar deg fremskynde nedlastingstiden med fire ganger. Det er ingen forskjell mellom de optimaliserte og ikke-optimaliserte Troika-databasene i denne modusen.

Vi sjekket også innvirkningen av nettverkshastighet på tung drift, for eksempel under gruppe-re-hosting. Resultatet er også uttrykt i relative termer:

Her er det allerede mer interessant, den optimaliserte basen til "troikaen" i et 100 Mbit/s-nettverk fungerer med samme hastighet som de "to", og den uoptimerte viser det dobbelte av det dårligere resultatet. På en gigabit er forholdene bevart, den ikke-optimaliserte "tre" er også dobbelt så treg som de "to", og den optimaliserte henger etter med en tredjedel. I tillegg lar overgangen til 1 Gb/s deg redusere utførelsestiden med en faktor på tre for versjon 2.0 og to ganger for versjon 3.0.

For å evaluere innvirkningen av nettverkshastighet på daglig arbeid brukte vi prestasjonsmåling ved å utføre en sekvens av forhåndsdefinerte handlinger i hver database.

Faktisk, for hverdagslige oppgaver, er ikke nettverksbåndbredden en flaskehals, en uoptimalisert "tre" er bare 20% tregere enn en toer, og etter optimalisering viser det seg å være omtrent det samme raskere - fordelene ved å jobbe i tynnklientmodus påvirker. Overgangen til 1 Gb/s gir ikke den optimaliserte basen noen fordeler, og den ikke-optimaliserte basen og toeren begynner å jobbe raskere, og viser en liten forskjell mellom dem.

Fra testene som er utført, blir det klart at nettverket ikke er en flaskehals for nye konfigurasjoner, og den administrerte applikasjonen fungerer enda raskere enn vanlig. Du kan også anbefale å bytte til 1 Gb/s hvis tunge oppgaver og databaselastehastighet er kritisk for deg, i andre tilfeller lar nye konfigurasjoner deg jobbe effektivt selv i trege 100 Mb/s nettverk.

Så hvorfor bremser 1C farten? Vi vil undersøke nærmere.

Serverdiskundersystem og SSD

I forrige artikkel oppnådde vi en økning i 1C-ytelse ved å plassere databaser på SSD. Kanskje ytelsen til serverdiskundersystemet ikke er nok? Vi målte ytelsen til en diskserver under en gruppekjøring i to databaser samtidig og fikk et ganske optimistisk resultat.

Til tross for det relativt høye antallet input/output-operasjoner per sekund (IOPS) - 913, oversteg ikke kølengden 1,84, noe som er et veldig godt resultat for en to-diskarray. Basert på det kan vi anta at et speil fra vanlige disker vil være nok for normal drift av 8-10 nettverksklienter i tunge moduser.

Så er det nødvendig med en SSD på en server? Det beste svaret på dette spørsmålet vil hjelpe testing, som vi utførte ved hjelp av en lignende metodikk, nettverkstilkoblingen er 1 Gb / s overalt, resultatet er også uttrykt i relative verdier.

La oss starte med databasens lastehastighet.

Det kan virke overraskende for noen, men SSD-basen på serveren påvirker ikke nedlastingshastigheten til databasen. Den viktigste begrensende faktoren her, som vist av forrige test, er nettverksgjennomstrømning og klientytelse.

La oss gå videre til omkobling:

Vi har allerede bemerket ovenfor at diskytelsen er ganske nok selv for kraftig drift, så hastigheten til SSD-en påvirkes heller ikke, bortsett fra den uoptimaliserte basen, som fanget opp med den optimaliserte på SSD-en. Faktisk bekrefter dette nok en gang at optimaliseringsoperasjoner organiserer informasjon i databasen, reduserer antallet tilfeldige I/O-operasjoner og øker tilgangshastigheten til den.

På dagligdagse gjøremål er bildet likt:

Bare den ikke-optimaliserte basen får fordelen av SSD-en. Selvfølgelig kan du kjøpe en SSD, men det ville være mye bedre å tenke på rettidig vedlikehold av basene. Ikke glem å defragmentere infobase-partisjonen på serveren.

Klientdiskundersystem og SSD

Vi analyserte påvirkningen av SSD på hastigheten til lokalt installert 1C i , mye av det som er sagt er også sant for arbeid i nettverksmodus. Faktisk bruker 1C ganske aktivt diskressurser, inkludert for bakgrunnsoppgaver og planlagte oppgaver. I figuren nedenfor kan du se hvordan Accounting 3.0 har ganske aktivt tilgang til disken i omtrent 40 sekunder etter innlasting.

Men samtidig bør man være klar over at for en arbeidsstasjon hvor aktivt arbeid utføres med en eller to informasjonsbaser, er ytelsesressursene til en konvensjonell HDD i en masseserie ganske nok. Å kjøpe en SSD kan fremskynde noen prosesser, men du vil ikke merke en radikal akselerasjon i det daglige arbeidet, siden for eksempel nedlasting vil være begrenset av nettverksbåndbredde.

En treg harddisk kan bremse noen operasjoner, men den kan ikke i seg selv få et program til å tregere.

RAM

Til tross for at RAM nå er uanstendig billig, fortsetter mange arbeidsstasjoner å jobbe med mengden minne som ble installert da de ble kjøpt. Det er her de første problemene venter. Basert på det faktum at den gjennomsnittlige "troikaen" krever omtrent 500 MB minne, kan vi anta at den totale mengden RAM på 1 GB for å jobbe med programmet ikke vil være nok.

Vi reduserte systemminnet til 1 GB og lanserte to infobaser.

Ved første øyekast er ikke alt så ille, programmet har moderert appetitten og holdt seg helt innenfor det tilgjengelige minnet, men la oss ikke glemme at behovet for driftsdata ikke har endret seg, så hvor ble det av? Spylt til disk, cache, swap, etc., er essensen av denne operasjonen at data som ikke er nødvendig for øyeblikket sendes fra rask RAM, hvor mye ikke er nok, til treg disk.

Hvor fører det hen? La oss se hvordan systemressursene brukes i tunge operasjoner, for eksempel, la oss starte en grupperekjøring i to databaser samtidig. Først på et system med 2 GB RAM:

Som du kan se, bruker systemet aktivt nettverket til å motta data og prosessoren til å behandle dem, diskaktivitet er ubetydelig, i prosessen med å behandle vokser den av og til, men er ikke en begrensende faktor.

La oss nå redusere minnet til 1 GB:

Situasjonen endrer seg radikalt, hovedbelastningen faller nå på harddisken, prosessoren og nettverket er inaktive og venter på at systemet skal lese de nødvendige dataene fra disken inn i minnet og sende unødvendige data dit.

Samtidig viste selv subjektivt arbeid med to åpne databaser på et system med 1 GB minne å være ekstremt ubehagelig, kataloger og magasiner åpnet med en betydelig forsinkelse og aktiv disktilgang. Å åpne magasinet Salg av varer og tjenester tok for eksempel omtrent 20 sekunder og ble ledsaget av høy diskaktivitet hele denne tiden (uthevet med en rød linje).

For å objektivt vurdere virkningen av RAM på ytelsen til konfigurasjoner basert på en administrert applikasjon, utførte vi tre målinger: lastehastigheten til den første basen, lastehastigheten til den andre basen og grupperepostering i en av basene. Begge basene er helt identiske og skapt ved å kopiere den optimaliserte basen. Resultatet er uttrykt i relative enheter.

Resultatet taler for seg selv, hvis lastetiden vokser med omtrent en tredjedel, som fortsatt er ganske tolerabel, vokser tiden for å utføre operasjoner i databasen tre ganger, det er ikke nødvendig å snakke om noe komfortabelt arbeid under slike forhold. Forresten, dette er tilfellet når du kjøper en SSD kan forbedre situasjonen, men det er mye enklere (og billigere) å håndtere årsaken, ikke konsekvensene, og bare kjøpe riktig mengde RAM.

Mangelen på RAM er hovedårsaken til at det er ubehagelig å jobbe med nye 1C-konfigurasjoner. Minimum passende konfigurasjoner bør vurderes med 2 GB minne ombord. Samtidig må du huske at i vårt tilfelle ble det opprettet "drivhus"-forhold: et rent system, bare 1C og oppgavelederen ble lansert. I det virkelige liv er en nettleser, en kontorpakke, et antivirus osv. vanligvis åpne på en fungerende datamaskin, så fortsett fra behovet for 500 MB per database pluss en viss margin, slik at du ikke støter på en mangel under tunge operasjoner minne og drastisk ytelsesforringelse.

prosessor

Den sentrale prosessorenheten, uten overdrivelse, kan kalles hjertet til datamaskinen, siden det er han som til slutt behandler alle beregningene. For å evaluere dens rolle, kjørte vi et annet sett med tester, det samme som for RAM, og reduserte antall kjerner tilgjengelig for den virtuelle maskinen fra to til én, mens testen ble kjørt to ganger med minnestørrelser på 1 GB og 2 GB.

Resultatet viste seg å være ganske interessant og uventet, en kraftigere prosessor tok ganske effektivt over belastningen i møte med mangel på ressurser, ellers uten å gi noen konkrete fordeler. 1C Enterprise (i filmodus) kan knapt kalles en applikasjon som aktivt bruker prosessorressurser, heller lite krevende. Og under vanskelige forhold belastes prosessoren ikke så mye ved å beregne dataene til selve applikasjonen, men ved å betjene overheadkostnader: ekstra I/O-operasjoner, etc.

konklusjoner

Så hvorfor bremser 1C farten? Først av alt er dette mangel på RAM, hovedbelastningen i dette tilfellet faller på harddisken og prosessoren. Og hvis de ikke skinner med ytelse, som vanligvis er tilfellet i kontorkonfigurasjoner, får vi situasjonen beskrevet i begynnelsen av artikkelen - de "to" fungerte bra, og de "tre" bremser skamløst ned.

Den andre plassen bør gis til nettverksytelse, en treg 100 Mbps-kanal kan bli en ekte flaskehals, men samtidig er tynnklientmodusen i stand til å opprettholde et ganske komfortabelt driftsnivå selv på trege kanaler.

Da bør du ta hensyn til disken en, å kjøpe en SSD er neppe en god investering, men å erstatte disken med en mer moderne vil ikke være overflødig. Forskjellen mellom generasjoner av harddisker kan estimeres fra følgende materiale: .

Og til slutt prosessoren. En raskere modell vil selvfølgelig ikke være overflødig, men det er liten vits i å øke ytelsen, med mindre denne PC-en brukes til tunge operasjoner: batchbehandling, tunge rapporter, månedsavslutning osv.

Vi håper dette materialet vil hjelpe deg raskt å forstå spørsmålet om "hvorfor 1C bremser" og løse det mest effektivt og uten ekstra kostnad.

• Tagger:

Foto av Alena Tulyakova, IA Clerk.Ru

Artikkelen indikerer hovedfeilene som nybegynnere 1C-administratorer gjør, og viser hvordan de løses ved å bruke eksemplet på Gilev-testen.

Hovedformålet med å skrive artikkelen er ikke å gjenta de åpenbare nyansene for de administratorene (og programmererne) som ennå ikke har fått erfaring med 1C.

Et sekundært mål, hvis jeg har noen mangler, vil Infostart påpeke dette for meg raskest.

V. Gilevs test har allerede blitt en slags "de facto" standard. Forfatteren på nettstedet hans ga ganske forståelige anbefalinger, men jeg vil ganske enkelt gi noen resultater og kommentere de mest sannsynlige feilene. Naturligvis kan testresultatene på utstyret ditt variere, dette er bare en veiledning, hva som bør være og hva du kan strebe etter. Jeg vil merke med en gang at endringer må gjøres trinnvis, og etter hvert trinn, sjekk hvilket resultat det ga.

Det er lignende artikler om Infostart, i de relevante delene vil jeg legge til lenker til dem (hvis jeg savner noe, vennligst fortell meg i kommentarene, jeg vil legge det til). Så, anta at du bremser 1C. Hvordan diagnostisere problemet, og hvordan forstå hvem som har skylden, administratoren eller programmereren?

Opprinnelige data:

Testet datamaskin, hovedforsøkskanin: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. For sammenligning vises sammenlignbare resultater i en enkelt-tråds test av Core i3-2100. Utstyret ble spesielt tatt ikke av det nyeste, på moderne utstyr er resultatene merkbart bedre.

For testing av eksterne 1C- og SQL-servere, SQL-server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

For å teste 10 Gbit-nettverket ble Intel 520-DA2-adaptere brukt.

Filversjon. (basen ligger på serveren i den delte mappen, klientene er koblet til et nettverk, CIFS/SMB-protokollen). Trinn for trinn algoritme:

0. Legg Gilev testdatabase til filserveren i samme mappe som hoveddatabasene. Vi kobler til fra klientdatamaskinen, kjører testen. Vi husker resultatet.

Det antas at selv for gamle datamaskiner for 10 år siden (Pentium on 775 socket), bør tiden fra å klikke på 1C:Enterprise-snarveien til databasevinduet vises, være mindre enn ett minutt. (Celeron = sakte arbeid).

Hvis datamaskinen din er verre enn en 775 socket pentium med 1 GB RAM, så sympatiserer jeg med deg, og det vil være vanskelig for deg å oppnå komfortabelt arbeid på 1C 8.2 i filversjonen. Vurder enten å oppgradere (for lenge siden) eller bytte til en terminal (eller web, i tilfelle av tynne klienter og administrerte skjemaer) server.

Hvis datamaskinen ikke er verre, kan du sparke administratoren. Kontroller som et minimum driften av nettverks-, antivirus- og HASP-beskyttelsesdriveren.

Hvis Gilevs test på dette stadiet viste 30 "papegøyer" og mer, men 1C-arbeidsbasen fortsatt fungerer sakte - er spørsmålene allerede for programmereren.

1. For en veiledning, hvor mye en klientdatamaskin kan "presse ut", kontrollerer vi driften av kun denne datamaskinen, uten nettverk. Vi legger testbasen på den lokale datamaskinen (på en veldig rask disk). Hvis klientdatamaskinen ikke har en vanlig SSD, opprettes en ramdisk. Så langt er den enkleste og gratis Ramdisk enterprise.

For å teste versjon 8.2 er 256 MB av en ramdisk nok, og! Det viktigste. Etter å ha startet datamaskinen på nytt med en fungerende ramdisk, skal den ha 100-200 MB ledig. Følgelig, uten en ramdisk, bør det være 300-400 MB for normal drift av ledig minne.

For å teste versjon 8.3 er en 256 MB ramdisk nok, men det trengs mer ledig RAM.

Når du tester, må du se på prosessorbelastningen. I et tilfelle nær ideell (ramdisk), laster den lokale filen 1c 1 prosessorkjerne under drift. Følgelig, hvis prosessorkjernen ikke er fullastet under testing, se etter svakheter. Litt emosjonell, men generelt korrekt, er påvirkningen fra prosessoren på driften av 1C beskrevet. Bare for referanse, selv på moderne Core i3 med høy frekvens, er tallene 70-80 ganske reelle.

De vanligste feilene på dette stadiet.

• Feil konfigurert antivirus. Det er mange antivirus, innstillingene for hver er forskjellige, jeg kan bare si at med riktig konfigurasjon forstyrrer verken nettet eller Kaspersky 1C. Med "standard"-innstillingene - ca 3-5 papegøyer (10-15%) kan tas bort.
• ytelsesmodus. Av en eller annen grunn er det få som legger merke til dette, og effekten er den viktigste. Hvis du trenger hastighet, må du gjøre det, både på klient- og serverdatamaskiner. (Gilev har en god beskrivelse. Det eneste forbeholdet er at på noen hovedkort, hvis Intel SpeedStep er slått av, kan ikke TurboBoost slås på).

Du kan (og helst) aktivere ytelsesmodus på to steder:

• gjennom BIOS. Deaktiver C1, C1E, Intel C-state (C2, C3, C4) moduser. I forskjellige bios kalles de forskjellig, men betydningen er den samme. Søk lenge, en omstart er nødvendig, men hvis du gjorde det en gang, kan du glemme det. Hvis alt er gjort riktig i BIOS, blir hastigheten lagt til. På noen hovedkort kan BIOS-innstillinger settes slik at Windows ytelsesmodus ikke spiller noen rolle. (Eksempler på BIOS-oppsett av Gilev). Disse innstillingene gjelder hovedsakelig serverprosessorer eller "avansert" BIOS, hvis du ikke har funnet det i systemet ditt, og du ikke har Xeon - det er greit.

• Kontrollpanel - Strøm - Høy ytelse. Minus - hvis datamaskinen ikke har vært betjent på lenge, vil den surre sterkere med en vifte, den vil varmes opp mer og forbruke mer energi. Dette er prisen på ytelse.

Dette er standardinnstillingene. BIOS C-tilstand aktivert, balansert kraftmodus
BIOS C-state-aktivert, høyytelsesmodus For Pentium og Core kan du stoppe der, du kan fortsatt presse noen "papegøyer" ut av Xeon
I BIOS er C-tilstander av, høyytelsesmodus. Hvis du ikke bruker Turbo boost – slik skal det se ut server innstilt for ytelse

Og nå tallene. La meg minne deg på: Intel Xeon 5650, ramdisk. I det første tilfellet viser testen 23,26, i sistnevnte - 49,5. Forskjellen er nesten todelt. Tallene kan variere, men forholdet forblir stort sett det samme for Intel Core.

Kjære administratorer, du kan skjelle ut 1C som du vil, men hvis sluttbrukere trenger hastighet, må du aktivere høyytelsesmodus.

c) Turbo Boost. Først må du forstå om prosessoren din støtter denne funksjonen, for eksempel. Hvis det gjør det, kan du fortsatt ganske lovlig få litt ytelse. (Jeg vil ikke berøre spørsmålene om overklokking, spesielt servere, gjør det på egen risiko og risiko. Men jeg er enig i at å øke busshastigheten fra 133 til 166 gir en veldig merkbar økning i både hastighet og varmespredning)

Hvordan slå på turbo boost står for eksempel skrevet. Men! For 1C er det noen nyanser (ikke de mest åpenbare). Vanskeligheten er at den maksimale effekten av turboboost manifesteres når C-tilstanden er slått på. Og det viser seg noe som dette bildet:

Vær oppmerksom på at multiplikatoren er maksimum, kjernehastigheten er den vakreste, ytelsen er høy. Men hva vil skje som et resultat av 1s?

Men til slutt viser det seg at ifølge CPU-ytelsestester er varianten med en multiplikator på 23 foran, ifølge Gilevs tester i filversjonen er ytelsen med en multiplikator på 22 og 23 den samme, men i klient-server-versjon, varianten med en multiplikator på 23 horror horror horror (selv om C -state satt til nivå 7, er den fortsatt tregere enn med C-state slått av). Derfor, anbefalingen, sjekk begge alternativene for deg selv, og velg den beste fra dem. Uansett er forskjellen mellom 49,5 og 53 papegøyer ganske betydelig, spesielt siden det er uten mye anstrengelse.

Konklusjon - turboboost må være med. La meg minne deg på at det ikke er nok å aktivere Turbo boost-elementet i BIOS, du må også se på andre innstillinger (BIOS: QPI L0s, L1 - deaktiver, kreve skrubbing - deaktiver, Intel SpeedStep - aktiver, Turbo boost - aktiver Kontrollpanel - Strøm - Høy ytelse) . Og jeg ville fortsatt (selv for filversjonen) stoppet ved alternativet der c-state er slått av, selv om multiplikatoren er mindre der. Få deg noe sånt...

Et ganske kontroversielt poeng er minnefrekvensen. For eksempel er minnefrekvensen vist som svært innflytelsesrik. Testene mine avslørte ikke slik avhengighet. Jeg vil ikke sammenligne DDR 2/3/4, jeg vil vise resultatene av å endre frekvensen innenfor samme linje. Minnet er det samme, men i BIOS tvinger vi fram lavere frekvenser.

Og testresultater. 1C 8.2.19.83, for filversjonen lokal ramdisk, for klient-server 1C og SQL på én datamaskin, delt minne. Turbo boost er deaktivert i begge alternativene. 8.3 viser sammenlignbare resultater.

Forskjellen ligger innenfor målefeilen. Jeg trakk spesifikt ut CPU-Z-skjermbildene for å vise at andre parametere endres med frekvensendringen, den samme CAS-latensen og RAS til CAS-forsinkelsen, som jevner ut frekvensendringen. Forskjellen vil være når minnemodulene fysisk endres, fra tregere til raskere, men selv der er ikke tallene særlig signifikante.

2. Når vi fant ut prosessoren og minnet til klientdatamaskinen, går vi videre til det neste veldig viktige stedet - nettverket. Det er skrevet mange bind med bøker om nettverksinnstilling, det er artikler om Infostart ( og andre), her vil jeg ikke fokusere på dette emnet. Før du begynner å teste 1C, vennligst sørg for at iperf mellom to datamaskiner viser hele båndet (for 1 Gbit-kort - vel, minst 850 Mbit, men bedre 950-980), at Gilevs råd blir fulgt. Deretter - den enkleste testen av arbeid vil merkelig nok være å kopiere én stor fil (5-10 gigabyte) over nettverket. Et indirekte tegn på normal drift på et nettverk på 1 Gbps vil være en gjennomsnittlig kopihastighet på 100 Mb/s, godt arbeid - 120 Mb/s. Jeg vil gjøre deg oppmerksom på at prosessorbelastningen også kan være et svakt punkt (inkludert). SMB-protokollen på Linux er ganske dårlig parallellisert, og under drift kan den ganske enkelt "spise" en prosessorkjerne og ikke konsumere den lenger.

Og videre. Med standardinnstillinger fungerer Windows-klienten best med Windows-server (eller til og med Windows-arbeidsstasjon) og SMB / CIFS-protokoll, linux-klient (debian, ubuntu så ikke på resten) fungerer best med linux og NFS (den fungerer også med SMB, men på NFS papegøyer ovenfor). At Win-Linux-serveren på NFS under lineær kopiering kopieres til én strøm raskere, betyr ingenting. Tuning debian for 1C er et tema for en egen artikkel, jeg er ikke klar for det enda, selv om jeg kan si at i filversjonen fikk jeg til og med litt bedre ytelse enn Win-versjonen på samme utstyr, men med postgres med brukere over 50 Jeg har fortsatt alt veldig dårlig.

Det viktigste er hva de «brente» administratorene vet om, men nybegynnere tar ikke hensyn til. Det er mange måter å sette banen til 1c-databasen på. Du kan lage servershare, du kan 192.168.0.1share, du kan netto bruke z: 192.168.0.1share (og i noen tilfeller vil denne metoden også fungere, men ikke alltid) og deretter spesifisere stasjonen Z. Det ser ut til at alle disse banene peker til samme ting samme sted, men for 1C er det kun en måte som gir en ganske stabil ytelse. Så her er det du trenger å gjøre riktig:

På kommandolinjen (eller i policyer, eller hva som passer deg) - bruk nett DriveLetter: servershare. Eksempel: nettbruk m:serverbaser. Jeg understreker spesifikt, IKKE IP-adressen, men servernavnet. Hvis serveren ikke er synlig med navn, legg den til i dns på serveren, eller lokalt i hosts-filen. Men anken må være ved navn. Følgelig, på vei til databasen, få tilgang til denne disken (se bildet).

Og nå skal jeg vise i tall hvorfor slike råd. Opprinnelige data: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169-kort. OS Win 2008 R2, Win 7, Debian 8. Siste drivere, oppdateringer tatt i bruk. Før testing sørget jeg for at Iperf gir full båndbredde (bortsett fra 10 Gbit-kort viste det seg å presse ut kun 7,2 Gbit, senere skal jeg se hvorfor, testserveren er ennå ikke riktig konfigurert). Diskene er forskjellige, men overalt er det en SSD (spesielt satt inn en enkelt disk for testing, ingenting annet er lastet inn) eller et raid fra en SSD. Hastigheten på 100 Mbit ble oppnådd ved å begrense innstillingene til Intel 362-adapteren. Det var ingen forskjell mellom 1 Gbit kobber Intel 350 og 1 Gbit optikk Intel X520-DA2 (oppnådd ved å begrense hastigheten på adapteren). Maksimal ytelse, turboboost er deaktivert (bare for å sammenligne resultatene, gir turboboost litt mindre enn 10 % for gode resultater, for dårlige resultater påvirker det kanskje ikke i det hele tatt). Versjoner 1C 8.2.19.86, 8.3.6.2076. Jeg gir ikke alle tallene, men bare de mest interessante, slik at det er noe å sammenligne med.

Konklusjoner (fra tabellen, og fra personlig erfaring. Gjelder kun filversjonen):

• Over nettverket kan du få ganske normale tall for arbeid hvis dette nettverket er normalt konfigurert og banen er korrekt skrevet i 1C. Selv de første Core i3-ene kan godt gi 40+ papegøyer, noe som er ganske bra, og dette er ikke bare papegøyer, i ekte arbeid er forskjellen også merkbar. Men! begrensningen ved arbeid med flere (mer enn 10) brukere vil ikke lenger være nettverket, her er 1 Gbit fortsatt nok, men blokkering under flerbrukerarbeid (Gilev).
• plattform 1C 8.3 er mange ganger mer krevende for kompetent nettverksoppsett. Grunninnstillinger - se Gilev, men husk at alt kan påvirke. Jeg så akselerasjon fra det faktum at de avinstallerte (og ikke bare slått av) antiviruset, fra å fjerne protokoller som FCoE, fra å endre drivere til en eldre, men Microsoft-sertifisert versjon (spesielt for billige kort som asus og longs), fra å fjerne andre nettverkskort fra serveren. Mange alternativer, konfigurer nettverket med omtanke. Det kan godt være en situasjon når plattform 8.2 gir akseptable tall, og 8.3 - to eller enda flere ganger mindre. Prøv å lek deg med plattformversjoner 8.3, noen ganger får du en veldig stor effekt.
• 1C 8.3.6.2076 (kanskje senere, jeg har ikke sett etter den eksakte versjonen ennå) over nettverket er fortsatt enklere å sette opp enn 8.3.7.2008. Fra 8.3.7.2008 for å oppnå normal nettverksdrift (i sammenlignbare papegøyer) viste det seg bare noen få ganger, jeg kunne ikke gjenta det for et mer generelt tilfelle. Jeg skjønte ikke så mye, men etter fotkledene fra Process Explorer å dømme, går ikke opptaket der slik det gjør i 8.3.6.
• Til tross for det faktum at når du jobber på et 100 Mbps-nettverk, er belastningsplanen liten (vi kan si at nettverket er gratis), er arbeidshastigheten fortsatt mye mindre enn på 1 Gbps. Årsaken er nettverksforsinkelse.
• Ceteris paribus (velfungerende nettverk) for 1C 8.2 er Intel-Realtek-tilkoblingen 10 % tregere enn Intel-Intel. Men realtek-realtek kan generelt gi skarpe innsynkninger ut av det blå. Derfor, hvis det er penger, er det bedre å holde Intel-nettverkskort overalt, hvis det ikke er penger, så legg Intel bare på serveren (din KO). Ja, og det er mange ganger flere instruksjoner for tuning av Intel-nettverkskort.
• Standard antivirusinnstillinger (for eksempel drweb 10-versjon) tar bort omtrent 8-10% av papegøyene. Hvis du konfigurerer det riktig (la 1cv8-prosessen gjøre alt, selv om det ikke er trygt) - hastigheten er den samme som uten antivirus.
• IKKE les Linux-guruer. En server med samba er flott og gratis, men hvis du setter Win XP eller Win7 på serveren (eller enda bedre - server OS), vil i filversjon 1c fungere raskere. Ja, både samba og protokollstabelen og nettverksinnstillingene og mye mer i debian / ubuntu er godt innstilt, men dette anbefales for spesialister. Det gir ingen mening å installere Linux med standardinnstillinger og deretter si at det er tregt.
• Det er en god idé å teste disker koblet til via nettbruk med fio . Det vil i hvert fall være klart om dette er problemer med 1C-plattformen, eller med nettverket/disken.
• For en enkeltbrukervariant kan jeg ikke tenke på tester (eller en situasjon) der forskjellen mellom 1 Gb og 10 Gb vil være synlig. Det eneste stedet hvor 10Gbps for filversjonen ga bedre resultater var å koble til disker via iSCSI, men dette er et emne for en egen artikkel. Likevel tror jeg at 1 Gbit-kort er nok for filversjonen.
• Hvorfor, med et 100 Mbit-nettverk, fungerer 8.3 merkbart raskere enn 8.2 - jeg forstår ikke, men faktum fant sted. Alt annet utstyr, alle andre innstillinger er nøyaktig de samme, bare i ett tilfelle blir 8.2 testet, og i det andre - 8.3.
• Ikke innstilt NFS vinn - vinn eller vinn-lin gir 6 papegøyer, inkluderte det ikke i tabellen. Etter tuning fikk jeg 25, men den er ustabil (oppkjøringen i mål er mer enn 2 enheter). Så langt kan jeg ikke gi anbefalinger om bruk av Windows og NFS-protokollen.

terminalserver. (basen ligger på serveren, klienter er koblet til et nettverk, RDP-protokollen). Trinn for trinn algoritme:

• Vi legger Gilev testdatabase til serveren i samme mappe som hoveddatabasene. Vi kobler til fra samme server og kjører testen. Vi husker resultatet.
• På samme måte som i filversjonen setter vi opp prosessoren. Når det gjelder en terminalserver, spiller prosessoren generelt hovedrollen (det er forstått at det ikke er noen åpenbare svakheter, for eksempel mangel på minne eller en enorm mengde unødvendig programvare).
• Å sette opp nettverkskort i tilfelle av en terminalserver har praktisk talt ingen effekt på driften av 1s. For å gi "spesiell" komfort, hvis serveren din gir ut mer enn 50 papegøyer, kan du leke med nye versjoner av RDP-protokollen, bare for brukernes komfort, raskere respons og rulling.
• Med det aktive arbeidet til et stort antall brukere (og her kan du allerede prøve å koble 30 personer til en base, hvis du prøver), er det veldig ønskelig å installere en SSD-stasjon. Av en eller annen grunn antas det at disken ikke påvirker driften av 1C spesielt, men alle tester utføres med kontrollerbufferen aktivert for skriving, noe som er feil. Testbasen er liten, den får plass i cachen, derav de høye tallene. På ekte (store) databaser vil alt være helt annerledes, så cachen er deaktivert for tester.

• Den inkluderte cachen til RAID-kontrolleren eliminerer all forskjellen mellom diskene, tallene er de samme for både sat og sas. Å teste med det for en liten mengde data er ubrukelig og er ikke en indikator.
• For 8.2-plattformen er ytelsesforskjellen mellom SATA- og SSD-alternativer mer enn dobbel. Dette er ikke en skrivefeil. Hvis du ser på ytelsesmonitoren under testen på SATA-stasjoner. så er det godt synlig "Aktiv disktid (i%)" 80-95. Ja, hvis du aktiverer skrive-cachen til selve diskene, vil hastigheten øke til 35, hvis du aktiverer raid-kontroller-cachen - opptil 49 (uansett hvilke disker som testes for øyeblikket). Men dette er syntetiske papegøyer av cachen, i virkelig arbeid med store databaser vil det aldri være et 100% skrive-cache-treffforhold.
• Hastigheten til selv billige SSD-er (jeg testet på Agility 3) er nok til at filversjonen fungerer. Skriveressursen er en annen sak, her må du se i hvert enkelt tilfelle, det er klart at Intel 3700 vil ha en størrelsesorden høyere, men der er prisen tilsvarende. Og ja, jeg forstår at når jeg tester en SSD-stasjon, tester jeg også cachen til denne stasjonen i større grad, de reelle resultatene blir mindre.
• Den mest korrekte (fra mitt ståsted) løsning vil være å tildele 2 SSD-disker til et speilraid for filbasen (eller flere filbaser), og ikke legge noe annet der. Ja, med et speil slites SSD-er ut på samme måte, og dette er et minus, men de er i det minste på en eller annen måte forsikret mot feil i kontrollerelektronikken.
• Hovedfordelene med SSD-disker for filversjonen vil vises når det er mange databaser, og hver med flere brukere. Hvis det er 1-2 baser, og brukere i området 10, vil SAS-disker være nok. (men i alle fall - se på lasting av disse diskene, i det minste gjennom perfmon).
• Hovedfordelene med en terminalserver er at den kan ha svært svake klienter, og nettverksinnstillingene påvirker terminalserveren mye mindre (din KO igjen).

Hvis Gilev-testen viser små tall, og du har både en prosessor med høy frekvens og raske disker, her må administratoren ta minst perfmon, og registrere alle resultatene et sted, og se, observere, trekke konklusjoner. Det vil ikke være noen definitive råd.

Klient-server-alternativ.

Tester ble utført bare 8.2, tk. På 8.3 avhenger alt ganske seriøst av versjonen.

For testing valgte jeg forskjellige serveralternativer og nettverk mellom dem for å vise hovedtrendene.

Det ser ut til at jeg har vurdert alle de interessante alternativene, hvis du er interessert i noe annet - skriv i kommentarene, jeg vil prøve å gjøre det.

• SAS på lagring er tregere enn lokale SSD-er, selv om lagring har store cache-størrelser. SSD-er og lokale og lagringssystemer for Gilev-testen fungerer med sammenlignbare hastigheter. Jeg kjenner ingen standard flertrådstest (ikke bare poster, men alt utstyr) bortsett fra belastningen 1C fra MCC.
• Å endre 1C-serveren fra 5520 til 5650 ga nesten en dobling av ytelsen. Ja, serverkonfigurasjonene stemmer ikke helt overens, men det viser en trend (ingenting overraskende).
• Å øke frekvensen på SQL-serveren gir selvfølgelig en effekt, men ikke den samme som på 1C-serveren, MS SQL-serveren er perfekt i stand (hvis du blir spurt om det) å bruke multi-core og ledig minne.
• Å endre nettverket mellom 1C og SQL fra 1 Gbps til 10 Gbps gir omtrent 10 % av papegøyene. Forventet mer.
• Aktivering av delt minne gir fortsatt effekten, men ikke 15 %, som beskrevet i artikkelen. Sørg for å gjøre det, det er raskt og enkelt. Hvis noen ga SQL-serveren en navngitt instans under installasjonen, så for at 1C skal fungere, må servernavnet ikke spesifiseres av FQDN (tcp / ip vil fungere), ikke gjennom localhost eller bare ServerName, men gjennom ServerNameInstanceName, for eksempel zz- testzztest. (Ellers vil følgende DBMS-feil oppstå: Microsoft SQL Server Native Client 10.0: Delt minneleverandør: Det delte minnebiblioteket som ble brukt til å koble til SQL Server 2000 ble ikke funnet. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, tilstand=1, alvorlighetsgrad=10, native=126, linje=0).
• for brukere under 100 er det eneste poenget med å dele opp i to separate servere en lisens for Win 2008 Std (og eldre versjoner), som kun støtter 32 GB RAM. I alle andre tilfeller bør 1C og SQL definitivt installeres på samme server og gis mer (minst 64 GB) minne. Å gi MS SQL mindre enn 24-28 GB RAM er uberettiget grådighet (hvis du tror at du har nok minne til det og alt fungerer bra, vil kanskje 1C-filversjonen være nok for deg?)
• Hvor mye verre en haug med 1C og SQL fungerer i en virtuell maskin er temaet i en egen artikkel (hint - merkbart verre). Selv i Hyper-V er ting ikke så klart...
• Balansert ytelsesmodus er dårlig. Resultatene stemmer godt overens med filversjonen.
• Mange kilder sier at feilsøkingsmodusen (ragent.exe -debug) gir en sterk reduksjon i ytelse. Vel, det senker, ja, men jeg vil ikke kalle 2-3% en signifikant effekt.

Hovedformålet med å skrive artikkelen er ikke å gjenta de åpenbare nyansene for de administratorene (og programmererne) som ennå ikke har fått erfaring med 1C.

Et sekundært mål, hvis jeg har noen mangler, vil Infostart påpeke dette for meg raskest.

V. Gilevs test har allerede blitt en slags "de facto" standard. Forfatteren på nettstedet hans ga ganske forståelige anbefalinger, men jeg vil ganske enkelt gi noen resultater og kommentere de mest sannsynlige feilene. Naturligvis kan testresultatene på utstyret ditt variere, dette er bare en veiledning, hva som bør være og hva du kan strebe etter. Jeg vil merke med en gang at endringer må gjøres trinnvis, og etter hvert trinn, sjekk hvilket resultat det ga.

Det er lignende artikler om Infostart, i de relevante delene vil jeg legge til lenker til dem (hvis jeg savner noe, vennligst fortell meg i kommentarene, jeg vil legge det til). Så, anta at du bremser 1C. Hvordan diagnostisere problemet, og hvordan forstå hvem som har skylden, administratoren eller programmereren?

Opprinnelige data:

Testet datamaskin, hovedforsøkskanin: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. For sammenligning vises sammenlignbare resultater i en enkelt-tråds test av Core i3-2100. Utstyret ble spesielt tatt ikke av det nyeste, på moderne utstyr er resultatene merkbart bedre.

For testing av eksterne 1C- og SQL-servere, SQL-server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

For å teste 10 Gbit-nettverket ble Intel 520-DA2-adaptere brukt.

Filversjon. (basen ligger på serveren i den delte mappen, klientene er koblet til et nettverk, CIFS/SMB-protokollen). Trinn for trinn algoritme:

0. Legg Gilev testdatabase til filserveren i samme mappe som hoveddatabasene. Vi kobler til fra klientdatamaskinen, kjører testen. Vi husker resultatet.

Det er forstått at selv for gamle datamaskiner for 10 år siden (Pentium on 775 socket ) tiden fra du klikker på 1C:Enterprise-etiketten til databasevinduet vises, bør være mindre enn ett minutt. ( Celeron = sakte arbeid).

Hvis datamaskinen din er dårligere enn en Pentium på 775 stikkontakt med 1 GB RAM, så sympatiserer jeg med deg, og det vil være vanskelig for deg å oppnå komfortabelt arbeid på 1C 8.2 i filversjonen. Vurder enten å oppgradere (for lenge siden) eller bytte til en terminal (eller web, i tilfelle av tynne klienter og administrerte skjemaer) server.

Hvis datamaskinen ikke er verre, kan du sparke administratoren. Kontroller som et minimum driften av nettverks-, antivirus- og HASP-beskyttelsesdriveren.

Hvis Gilevs test på dette stadiet viste 30 "papegøyer" og mer, men 1C-arbeidsbasen fortsatt fungerer sakte - er spørsmålene allerede for programmereren.

1. For en veiledning, hvor mye en klientdatamaskin kan "presse ut", kontrollerer vi driften av kun denne datamaskinen, uten nettverk. Vi legger testbasen på den lokale datamaskinen (på en veldig rask disk). Hvis klientdatamaskinen ikke har en vanlig SSD, opprettes en ramdisk. Så langt er den enkleste og gratis Ramdisk enterprise.

For å teste versjon 8.2 er 256 MB av en ramdisk nok, og! Det viktigste. Etter å ha startet datamaskinen på nytt med en fungerende ramdisk, skal den ha 100-200 MB ledig. Følgelig, uten en ramdisk, bør det være 300-400 MB for normal drift av ledig minne.

For å teste versjon 8.3 er en 256 MB ramdisk nok, men det trengs mer ledig RAM.

Når du tester, må du se på prosessorbelastningen. I et tilfelle nær ideell (ramdisk), laster den lokale filen 1c 1 prosessorkjerne under drift. Følgelig, hvis prosessorkjernen ikke er fullastet under testing, se etter svakheter. Litt emosjonell, men generelt korrekt, er påvirkningen fra prosessoren på driften av 1C beskrevet. Bare for referanse, selv på moderne Core i3 med høy frekvens, er tallene 70-80 ganske reelle.

De vanligste feilene på dette stadiet.

a) Feilkonfigurert antivirus. Det er mange antivirus, innstillingene for hver er forskjellige, jeg kan bare si at med riktig konfigurasjon forstyrrer verken nettet eller Kaspersky 1C. Med "standard"-innstillingene - ca 3-5 papegøyer (10-15%) kan tas bort.

b) Ytelsesmodus. Av en eller annen grunn er det få som legger merke til dette, og effekten er den viktigste. Hvis du trenger hastighet, må du gjøre det, både på klient- og serverdatamaskiner. (Gilev har en god beskrivelse. Det eneste forbeholdet er at på noen hovedkort, hvis Intel SpeedStep er slått av, kan ikke TurboBoost slås på).

Kort sagt, under 1C-drift er det mye venting på svar fra andre enheter (disk, nettverk, etc.). Mens du venter på svar, hvis ytelsesmodusen er balansert, senker prosessoren frekvensen. En respons kommer fra enheten, 1C (prosessoren) må fungere, men de første syklusene går med redusert frekvens, deretter stiger frekvensen – og 1C venter igjen på svar fra enheten. Og så – mange hundre ganger per sekund.

Du kan (og helst) aktivere ytelsesmodus på to steder:

Gjennom BIOS. Deaktiver C1, C1E, Intel C-state (C2, C3, C4) moduser. I forskjellige bios kalles de forskjellig, men betydningen er den samme. Søk lenge, en omstart er nødvendig, men hvis du gjorde det en gang, kan du glemme det. Hvis alt er gjort riktig i BIOS, blir hastigheten lagt til. På noen hovedkort kan BIOS-innstillinger settes slik at Windows ytelsesmodus ikke spiller noen rolle. (Eksempler på BIOS-oppsett av Gilev). Disse innstillingene gjelder hovedsakelig serverprosessorer eller "avansert" BIOS, hvis du ikke har funnet det i systemet ditt, og du ikke har Xeon - det er greit.

Kontrollpanel - Strøm - Høy ytelse. Minus - hvis datamaskinen ikke har vært betjent på lenge, vil den surre sterkere med en vifte, den vil varmes opp mer og forbruke mer energi. Dette er prisen på ytelse.

Hvordan sjekke at modusen er aktivert. Kjør Oppgavebehandling - Ytelse - Ressursovervåking - CPU. Vi venter til prosessoren er opptatt med ingenting.

Dette er standardinnstillingene. BIOS C-tilstand inkludert, balansert kraftmodus
BIOS C-tilstand inkludert, høyytelsesmodus For Pentium og Core kan du stoppe der, du kan fortsatt presse noen "papegøyer" ut av Xeon
BIOS C-tilstand av, høyytelsesmodus. Hvis du ikke bruker Turbo boost – slik skal det se ut server innstilt for ytelse

Og nå tallene. La meg minne deg på: Intel Xeon 5650, ramdisk. I det første tilfellet viser testen 23,26, i sistnevnte - 49,5. Forskjellen er nesten todelt. Tallene kan variere, men forholdet forblir stort sett det samme for Intel Core.

Kjære administratorer, du kan skjelle ut 1C som du vil, men hvis sluttbrukere trenger hastighet, må du aktivere høyytelsesmodus.

c) Turbo Boost. Først må du forstå om prosessoren din støtter denne funksjonen, for eksempel. Hvis det gjør det, kan du fortsatt ganske lovlig få litt ytelse. (Jeg vil ikke berøre spørsmålene om overklokking, spesielt servere, gjør det på egen risiko og risiko. Men jeg er enig i at å øke busshastigheten fra 133 til 166 gir en veldig merkbar økning i både hastighet og varmespredning)

Hvordan slå på turbo boost står for eksempel skrevet. Men! For 1C er det noen nyanser (ikke de mest åpenbare). Vanskeligheten er at den maksimale effekten av turboboost manifesteres når C-tilstanden er slått på. Og det viser seg noe som dette bildet:

Vær oppmerksom på at multiplikatoren er maksimum, kjernehastigheten er den vakreste, ytelsen er høy. Men hva vil skje som et resultat av 1s?

Men til slutt viser det seg at ifølge CPU-ytelsestester er varianten med en multiplikator på 23 foran, ifølge Gilevs tester i filversjonen er ytelsen med en multiplikator på 22 og 23 den samme, men i klient-server-versjon, varianten med en multiplikator på 23 horror horror horror (selv om C -state satt til nivå 7, er den fortsatt tregere enn med C-state slått av). Derfor, anbefalingen, sjekk begge alternativene for deg selv, og velg den beste fra dem. Uansett er forskjellen mellom 49,5 og 53 papegøyer ganske betydelig, spesielt siden det er uten mye anstrengelse.

Konklusjon - turboboost må være med. La meg minne deg på at det ikke er nok å aktivere Turbo boost-elementet i BIOS, du må også se på andre innstillinger (BIOS: QPI L0s, L1 - deaktiver, kreve skrubbing - deaktiver, Intel SpeedStep - aktiver, Turbo boost - aktiver Kontrollpanel - Strøm - Høy ytelse) . Og jeg ville fortsatt (selv for filversjonen) stoppet ved alternativet der c-state er slått av, selv om multiplikatoren er mindre der. Få deg noe sånt...

Et ganske kontroversielt poeng er minnefrekvensen. For eksempel er minnefrekvensen vist som svært innflytelsesrik. Testene mine avslørte ikke slik avhengighet. Jeg vil ikke sammenligne DDR 2/3/4, jeg vil vise resultatene av å endre frekvensen innenfor samme linje. Minnet er det samme, men i BIOS tvinger vi fram lavere frekvenser.

Og testresultater. 1C 8.2.19.83, for filversjonen lokal ramdisk, for klient-server 1C og SQL på én datamaskin, delt minne. Turbo boost er deaktivert i begge alternativene. 8.3 viser sammenlignbare resultater.

Forskjellen ligger innenfor målefeilen. Jeg trakk spesifikt ut CPU-Z-skjermbildene for å vise at andre parametere endres med frekvensendringen, den samme CAS-latensen og RAS til CAS-forsinkelsen, som jevner ut frekvensendringen. Forskjellen vil være når minnemodulene fysisk endres, fra tregere til raskere, men selv der er ikke tallene særlig signifikante.

2. Når vi fant ut prosessoren og minnet til klientdatamaskinen, går vi videre til det neste veldig viktige stedet - nettverket. Det er skrevet mange bind med bøker om nettverksinnstilling, det er artikler om Infostart ( og andre), her vil jeg ikke fokusere på dette emnet. Før du begynner å teste 1C, vennligst sørg for at iperf mellom to datamaskiner viser hele båndet (for 1 Gbit-kort - vel, minst 850 Mbit, men bedre 950-980), at Gilevs råd blir fulgt. Deretter - den enkleste testen av arbeid vil merkelig nok være å kopiere én stor fil (5-10 gigabyte) over nettverket. Et indirekte tegn på normal drift på et nettverk på 1 Gbps vil være en gjennomsnittlig kopihastighet på 100 Mb/s, godt arbeid - 120 Mb/s. Jeg vil gjøre deg oppmerksom på at prosessorbelastningen også kan være et svakt punkt (inkludert). SMB protokollen på Linux er ganske dårlig parallellisert, og under drift kan den ganske enkelt "spise" en prosessorkjerne og ikke konsumere den lenger.

Og videre. Med standardinnstillinger fungerer Windows-klienten best med Windows-server (eller til og med Windows-arbeidsstasjon) og SMB / CIFS-protokoll, linux-klient (debian, ubuntu så ikke på resten) fungerer best med linux og NFS (den fungerer også med SMB, men på NFS papegøyer ovenfor). At Win-Linux-serveren på NFS under lineær kopiering kopieres til én strøm raskere, betyr ingenting. Tuning debian for 1C er et tema for en egen artikkel, jeg er ikke klar for det enda, selv om jeg kan si at i filversjonen fikk jeg til og med litt bedre ytelse enn Win-versjonen på samme utstyr, men med postgres med brukere over 50 Jeg har fortsatt alt veldig dårlig.

Det viktigste , som er kjent for "brente" administratorer, men nybegynnere tar ikke hensyn til. Det er mange måter å sette banen til 1c-databasen på. Du kan gjøre \\server\share, du kan \\192.168.0.1\share, du kan netto bruke z: \\192.168.0.1\share (og i noen tilfeller vil denne metoden også fungere, men ikke alltid) og deretter spesifisere Z-drevet.Det ser ut til at alle disse stiene peker til samme sted, men for 1C er det bare én måte som gir en ganske stabil ytelse. Så her er det du trenger å gjøre riktig:

På kommandolinjen (eller i policyer, eller hva som passer deg) - bruk nett DriveLetter: \\server\share. Eksempel: nettbruk m:\\server\baser. Jeg understreker spesifikt IKKE en IP-adresse, nemlig Navn server. Hvis serveren ikke er synlig med navn, legg den til i dns på serveren, eller lokalt i hosts-filen. Men anken må være ved navn. Følgelig, på vei til databasen, få tilgang til denne disken (se bildet).

Og nå skal jeg vise i tall hvorfor slike råd. Opprinnelige data: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169-kort. OS Win 2008 R2, Win 7, Debian 8. Siste drivere, oppdateringer tatt i bruk. Før testing sørget jeg for at Iperf gir full båndbredde (bortsett fra 10 Gbit-kort viste det seg å presse ut kun 7,2 Gbit, senere skal jeg se hvorfor, testserveren er ennå ikke riktig konfigurert). Diskene er forskjellige, men overalt er det en SSD (spesielt satt inn en enkelt disk for testing, ingenting annet er lastet inn) eller et raid fra en SSD. Hastigheten på 100 Mbit ble oppnådd ved å begrense innstillingene til Intel 362-adapteren. Det var ingen forskjell mellom 1 Gbit kobber Intel 350 og 1 Gbit optikk Intel X520-DA2 (oppnådd ved å begrense hastigheten på adapteren). Maksimal ytelse, turboboost er deaktivert (bare for å sammenligne resultatene, gir turboboost litt mindre enn 10 % for gode resultater, for dårlige resultater påvirker det kanskje ikke i det hele tatt). Versjoner 1C 8.2.19.86, 8.3.6.2076. Jeg gir ikke alle tallene, men bare de mest interessante, slik at det er noe å sammenligne med.

Konklusjoner (fra tabellen, og fra personlig erfaring. Gjelder kun filversjonen):

Over nettverket kan du få ganske normale tall for arbeid hvis dette nettverket er normalt konfigurert og banen er korrekt skrevet i 1C. Selv de første Core i3-ene kan godt gi 40+ papegøyer, noe som er ganske bra, og dette er ikke bare papegøyer, i ekte arbeid er forskjellen også merkbar. Men! begrensningen ved arbeid med flere (mer enn 10) brukere vil ikke lenger være nettverket, her er 1 Gbit fortsatt nok, men blokkering under flerbrukerarbeid (Gilev).

1C 8.3-plattformen er mange ganger mer krevende for kompetent nettverksoppsett. Grunninnstillinger - se Gilev, men husk at alt kan påvirke. Jeg så akselerasjon fra det faktum at de avinstallerte (og ikke bare slått av) antiviruset, fra å fjerne protokoller som FCoE, fra å endre drivere til en eldre, men Microsoft-sertifisert versjon (spesielt for billige kort som asus og longs), fra å fjerne andre nettverkskort fra serveren. Mange alternativer, konfigurer nettverket med omtanke. Det kan godt være en situasjon når plattform 8.2 gir akseptable tall, og 8.3 - to eller enda flere ganger mindre. Prøv å lek deg med plattformversjoner 8.3, noen ganger får du en veldig stor effekt.

1C 8.3.6.2076 (kanskje senere, jeg har ikke sett etter den eksakte versjonen ennå) over nettverket er fortsatt enklere å sette opp enn 8.3.7.2008. Fra 8.3.7.2008 for å oppnå normal nettverksdrift (i sammenlignbare papegøyer) viste det seg bare noen få ganger, jeg kunne ikke gjenta det for et mer generelt tilfelle. Jeg skjønte ikke så mye, men etter fotkledene fra Process Explorer å dømme, går ikke opptaket der slik det gjør i 8.3.6.

Til tross for det faktum at når du jobber på et 100 Mbps-nettverk, er belastningsplanen liten (vi kan si at nettverket er gratis), er arbeidshastigheten fortsatt mye mindre enn på 1 Gbps. Årsaken er nettverksforsinkelse.

Ceteris paribus (velfungerende nettverk) for 1C 8.2 er Intel-Realtek-tilkoblingen 10 % tregere enn Intel-Intel. Men realtek-realtek kan generelt gi skarpe innsynkninger ut av det blå. Derfor, hvis det er penger, er det bedre å holde Intel-nettverkskort overalt, hvis det ikke er penger, så legg Intel bare på serveren (din KO). Ja, og det er mange ganger flere instruksjoner for tuning av Intel-nettverkskort.

Standard antivirusinnstillinger (for eksempel drweb 10-versjon) tar bort omtrent 8-10% av papegøyene. Hvis du konfigurerer det riktig (la 1cv8-prosessen gjøre alt, selv om det ikke er trygt) - hastigheten er den samme som uten antivirus.

IKKE les Linux-guruer. En server med samba er flott og gratis, men hvis du setter Win XP eller Win7 på serveren (eller enda bedre - server OS), vil i filversjon 1c fungere raskere. Ja, både samba og protokollstabelen og nettverksinnstillingene og mye mer i debian / ubuntu er godt innstilt, men dette anbefales for spesialister. Det gir ingen mening å installere Linux med standardinnstillinger og deretter si at det er tregt.

Det er en god idé å teste disker koblet til via nettbruk med fio . Det vil i hvert fall være klart om dette er problemer med 1C-plattformen, eller med nettverket/disken.

For en enkeltbrukervariant kan jeg ikke tenke på tester (eller en situasjon) der forskjellen mellom 1 Gb og 10 Gb vil være synlig. Det eneste stedet hvor 10Gbps for filversjonen ga bedre resultater var å koble til disker via iSCSI, men dette er et emne for en egen artikkel. Likevel tror jeg at 1 Gbit-kort er nok for filversjonen.

Hvorfor, med et 100 Mbit-nettverk, fungerer 8.3 merkbart raskere enn 8.2 - jeg forstår ikke, men faktum fant sted. Alt annet utstyr, alle andre innstillinger er nøyaktig de samme, bare i ett tilfelle blir 8.2 testet, og i det andre - 8.3.

Ikke innstilt NFS vinn - vinn eller vinn-lin gir 6 papegøyer, inkluderte det ikke i tabellen. Etter tuning fikk jeg 25, men den er ustabil (oppkjøringen i mål er mer enn 2 enheter). Så langt kan jeg ikke gi anbefalinger om bruk av Windows og NFS-protokollen.

Etter alle innstillingene og sjekkene kjører vi testen på nytt fra klientdatamaskinen, gleder oss over det forbedrede resultatet (hvis det gikk). Hvis resultatet har forbedret seg, er det mer enn 30 papegøyer (og spesielt mer enn 40), det er mindre enn 10 brukere som jobber samtidig, og arbeidsdatabasen bremser fortsatt ned - nesten definitivt et programmerers problem (eller du har allerede nådde toppen av filversjonens evner).

terminalserver. (basen ligger på serveren, klienter er koblet til et nettverk, RDP-protokollen). Trinn for trinn algoritme:

0. Legg Gilev testdatabase til serveren i samme mappe som hoveddatabasene. Vi kobler til fra samme server og kjører testen. Vi husker resultatet.

1. På samme måte som i filversjonen setter vi opp arbeidet. Når det gjelder en terminalserver, spiller prosessoren generelt hovedrollen (det er forstått at det ikke er noen åpenbare svakheter, for eksempel mangel på minne eller en enorm mengde unødvendig programvare).

2. Å sette opp nettverkskort i tilfelle av en terminalserver har praktisk talt ingen innvirkning på driften av 1s. For å gi "spesiell" komfort, hvis serveren din gir ut mer enn 50 papegøyer, kan du leke med nye versjoner av RDP-protokollen, bare for brukernes komfort, raskere respons og rulling.

3. Med det aktive arbeidet til et stort antall brukere (og her kan du allerede prøve å koble 30 personer til en base, hvis du prøver), er det veldig ønskelig å installere en SSD-stasjon. Av en eller annen grunn antas det at disken ikke påvirker driften av 1C spesielt, men alle tester utføres med kontrollerbufferen aktivert for skriving, noe som er feil. Testbasen er liten, den får plass i cachen, derav de høye tallene. På ekte (store) databaser vil alt være helt annerledes, så cachen er deaktivert for tester.

For eksempel sjekket jeg arbeidet med Gilev-testen med forskjellige diskalternativer. Jeg la plater fra det som var for hånden, bare for å vise en tendens. Forskjellen mellom 8.3.6.2076 og 8.3.7.2008 er liten (i Ramdisk Turbo boost gir versjon 8.3.6 56.18 og 8.3.7.2008 gir 55.56, i andre tester er forskjellen enda mindre). Strømforbruk - maksimal ytelse, turbo boost deaktivert (med mindre annet er angitt).

Den inkluderte cachen til RAID-kontrolleren eliminerer all forskjellen mellom diskene, tallene er de samme for både sat og sas. Å teste med det for en liten mengde data er ubrukelig og er ikke en indikator.

For 8.2-plattformen er ytelsesforskjellen mellom SATA- og SSD-alternativer mer enn dobbel. Dette er ikke en skrivefeil. Hvis du ser på ytelsesmonitoren under testen på SATA-stasjoner. så er det godt synlig "Aktiv disktid (i%)" 80-95. Ja, hvis du aktiverer skrive-cachen til selve diskene, vil hastigheten øke til 35, hvis du aktiverer raid-kontroller-cachen - opptil 49 (uansett hvilke disker som testes for øyeblikket). Men dette er syntetiske papegøyer av cachen, i virkelig arbeid med store databaser vil det aldri være et 100% skrive-cache-treffforhold.

Hastigheten til selv billige SSD-er (jeg testet på Agility 3) er nok til at filversjonen fungerer. Skriveressursen er en annen sak, her må du se i hvert enkelt tilfelle, det er klart at Intel 3700 vil ha en størrelsesorden høyere, men der er prisen tilsvarende. Og ja, jeg forstår at når jeg tester en SSD-stasjon, tester jeg også cachen til denne stasjonen i større grad, de reelle resultatene blir mindre.

Den mest korrekte (fra mitt ståsted) løsning vil være å tildele 2 SSD-disker til et speilraid for filbasen (eller flere filbaser), og ikke legge noe annet der. Ja, med et speil slites SSD-er ut på samme måte, og dette er et minus, men de er i det minste på en eller annen måte forsikret mot feil i kontrollerelektronikken.

Hovedfordelene med SSD-disker for filversjonen vil vises når det er mange databaser, og hver med flere brukere. Hvis det er 1-2 baser, og brukere i området 10, vil SAS-disker være nok. (men i alle fall - se på lasting av disse diskene, i det minste gjennom perfmon).

Hovedfordelene med en terminalserver er at den kan ha svært svake klienter, og nettverksinnstillingene påvirker terminalserveren mye mindre (din KO igjen).

Konklusjoner: hvis du kjører Gilev-testen på terminalserveren (fra samme disk som arbeidsdatabasene er) og i de øyeblikkene da arbeidsdatabasen bremser ned, og Gilev-testen viser et godt resultat (over 30), så driften av hoveddatabasen er å klandre, mest sannsynlig en programmerer.

Hvis Gilev-testen viser små tall, og du har både en prosessor med høy frekvens og raske disker, her må administratoren ta minst perfmon, og registrere alle resultatene et sted, og se, observere, trekke konklusjoner. Det vil ikke være noen definitive råd.

Klient-server-alternativ.

Tester ble utført bare 8.2, tk. På 8.3 avhenger alt ganske seriøst av versjonen.

For testing valgte jeg forskjellige serveralternativer og nettverk mellom dem for å vise hovedtrendene.

Det ser ut til at jeg har vurdert alle de interessante alternativene, hvis du er interessert i noe annet - skriv i kommentarene, jeg vil prøve å gjøre det.

SAS på lagring er tregere enn lokale SSD-er, selv om lagring har store cache-størrelser. SSD-er og lokale og lagringssystemer for Gilev-testen fungerer med sammenlignbare hastigheter. Jeg kjenner ingen standard flertrådstest (ikke bare poster, men alt utstyr) bortsett fra belastningen 1C fra MCC.

Å endre 1C-serveren fra 5520 til 5650 ga nesten en dobling av ytelsen. Ja, serverkonfigurasjonene stemmer ikke helt overens, men det viser en trend (ingenting overraskende).

Å øke frekvensen på SQL-serveren gir selvfølgelig en effekt, men ikke den samme som på 1C-serveren, MS SQL-serveren er perfekt i stand (hvis du blir spurt om det) å bruke multi-core og ledig minne.

Å endre nettverket mellom 1C og SQL fra 1 Gbps til 10 Gbps gir omtrent 10 % av papegøyene. Forventet mer.

Aktivering av delt minne gir fortsatt effekten, men ikke 15 %, som beskrevet. Sørg for å gjøre det, det er raskt og enkelt. Hvis noen ga SQL-serveren en navngitt instans under installasjonen, så for at 1C skal fungere, må servernavnet ikke spesifiseres av FQDN (tcp / ip vil fungere), ikke gjennom lokalvert eller bare Servernavn, men gjennom Servernavn\Forekomstnavn, for eksempel zz-test\zztest. (Ellers vil følgende DBMS-feil oppstå: Microsoft SQL Server Native Client 10.0: Delt minneleverandør: Det delte minnebiblioteket som ble brukt til å koble til SQL Server 2000 ble ikke funnet. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, tilstand=1, alvorlighetsgrad=10, native=126, linje=0).

For brukere under 100 er det eneste poenget med å dele opp i to separate servere en lisens for Win 2008 Std (og eldre versjoner), som kun støtter 32 GB RAM. I alle andre tilfeller bør 1C og SQL definitivt installeres på samme server og gis mer (minst 64 GB) minne. Å gi MS SQL mindre enn 24-28 GB RAM er uberettiget grådighet (hvis du tror at du har nok minne til det og alt fungerer bra, vil kanskje 1C-filversjonen være nok for deg?)

Hvor mye verre en haug med 1C og SQL fungerer i en virtuell maskin er temaet i en egen artikkel (hint - merkbart verre). Selv i Hyper-V er ting ikke så klart...

Balansert ytelsesmodus er dårlig. Resultatene stemmer godt overens med filversjonen.

Mange kilder sier at feilsøkingsmodusen (ragent.exe -debug) gir en sterk reduksjon i ytelse. Vel, det senker, ja, men jeg vil ikke kalle 2-3% en signifikant effekt.

1C-systemet er et av hovedverktøyene for å drive små og mellomstore bedrifter i dag. Som regel har alle ansatte i organisasjonen tilgang til programmet. Dermed, hvis 1C begynner å bremse eller jobbe sakte, så påvirker dette virksomhetens oppførsel betydelig. Vurder hvordan du kan øke hastigheten på og optimalisere arbeidet i 1C på egen hånd.

Optimalisering med 1C-oppdatering

Nye versjoner av 1C fungerer alltid mer vellykket og raskere, så sørg for å følge oppdateringene. Regnskap anbefales å oppdateres så ofte som mulig. Spesielt når det finnes versjoner av regulert rapportering.

Mange har lenge brukt muligheten til å automatisk oppdatere programmet. Selv om dette problemet enkelt løses manuelt for 1s Enterprise 8.3, vil oppdatering som ikke forårsake problemer.

Det første trinnet er å laste ned den nyeste versjonen av plattformen som er i bruk. Dette gjøres enten ved hjelp av ITS-disken eller gjennom webgrensesnittet, hvor de gir løpende støtte til brukere av et program som 1s Enterprise 8.3, konfigurasjonsoppdateringen som også offisielt leveres.

I sistnevnte tilfelle lastes arkivet med oppdateringsdata ned separat. Utpakkingen skjer i hvilken som helst mappe som anses som den mest praktiske for brukeren. Etter det må du kjøre .exe-filen. I neste vindu klikker du bare på "Neste"-knappen.

En annen side vises. På den velger brukeren banen der installasjonen er fullført. Men dette trinnet anbefales bare for avanserte eiere av en personlig datamaskin. Standardfunksjonene er vanligvis nok til å løse de fleste problemer. Som standard, i dette tilfellet, er én mappe spesifisert, der alle oppdateringer installeres samtidig. Dette er mye mer praktisk enn når de endelige banene er forskjellige. Vi klikker bare på "Neste"-knappene flere ganger i 1s Enterprise 8.3-programmet, hvis konfigurasjonsoppdatering bør skje raskt.

Bare den siste knappen gjenstår, som tilbyr "Installasjon".

Hvordan øke hastigheten 1C hvis plattformen bremser ned

Oftest skyldes problemer det faktum at på et av stadiene reduseres konsentrasjonen av oppmerksomheten til utøveren. Her er det viktig å velge skjemaet for selve oppdateringen riktig, bare i dette tilfellet vil vi ikke støte på et problem når 1s fryser under oppdateringen.

Oppdatering av versjon 7.7

Det finnes flere typer konfigurasjon. Avhengig av dette velges forløpet for ytterligere handlinger.

• Typisk - i dette tilfellet forutsettes det at oppdateringen også utføres for regulert rapportering.
• Typiske bransjekonfigurasjoner - på mange måter ligner de tidligere alternativene. Det er viktig å lese instruksjonene fra utvikleren på forhånd. Ellers vil du ikke kunne finne ut hvorfor 1s 8.3 krasjer under oppdateringen.
• Modifisert standard – brukeren har alltid mulighet til selv å modifisere applikasjonen slik at den møter aktuelle behov. Et annet alternativ for å utvide funksjonaliteten er overgangen til nye plattformer. For eksempel den åttende versjonen.

Om versjon 8.0 og 8.1

Plattform 8.0 trekkes for øyeblikket fra støtte. Nye generiske design vil bare fungere når du bruker de nyeste versjonene. Det er bare nødvendig å ikke glemme at alle mellomliggende utgivelser er bestått uten feil. Ellers er det stor sannsynlighet for å miste informasjon. Eller kommer inn i en situasjon der 1s fryser når du oppdaterer konfigurasjonen.

Det er mulig at en ny standardkonfigurasjon blir introdusert, og deretter overføres restene fra de gamle infobasene til den.

Når det gjelder versjon 8.1, er det flere måter å oppgradere til den på:

1. manuelt;
2. i automatisk modus;
3. appellere til spesialister fra selskaper som leverer tjenester på dette området.

Arbeider med ikke-standardiserte eller modifiserte versjoner

I utgangspunktet refererer enhver konfigurasjon til typiske utviklinger. Det opphører å være slik dersom det gjøres visse endringer ved virksomheten. For eksempel under installasjon. Det er to klasser som skiller seg ut fra atypiske konfigurasjoner:

1. endret;
2. opprettet fra bunnen av, under hensyntagen til behovene til en bestemt bedrift.

Noen ganger distribueres en annenklasses konfigurasjon aktivt til brukere. Da hører det til standarden. Det er bare det at produsenten ikke regnes som 1C selv, men selskapet som har laget den nye versjonen.

Aktualiteten til konfigurasjonene kan opprettholdes ved følgende handlinger:

• Feilretting.
• Funksjonell utvidelse.
• Forbedring.
• Endre 1s 8.3, konfigurasjonen oppdateres ikke ved servicefeil.

Installasjonsprosessen kan ta forskjellig tid avhengig av Internett-hastigheten du bruker for øyeblikket. I et eget vindu velger brukeren om han vil oppdatere ved slutten av arbeidet, eller umiddelbart. Med det siste alternativet må du sørge for at ingen andre jobber med applikasjonen. Selve prosessen involverer bruk av eksklusiv modus i 1s Enterprise 8.3-applikasjonen, den siste oppdateringen er intet unntak.

• Det må huskes at ikke alle utgivelsesversjoner passer til gjeldende konfigurasjon.
• Hvis oppdateringer ikke har blitt gjort på lang tid, kan det hende du må laste ned flere filer eller arkiver samtidig.
• I listen er det lett å forstå hvilken versjon av 1s Enterprise 8.3 som trengs, oppdateringen velges av brukeren selv.

Når prosessen avsluttes, kan selve konfiguratoren lukkes. Det er denne modusen som oftest brukes hvis en oppdatering er nødvendig. Det er praktisk, automatiserer nesten hele prosessen. Neste gang du kjører den for første gang, kan du se en melding om at plattformen er utdatert. Og at det ikke anbefales å bruke det for øyeblikket.

Ytterligere årsaker til bremsing

Hvis programmet er oppdatert riktig og uten noen feil, men 1C bremser fortsatt ned, kan årsaken være som følger:

• Antivirus - hvis konfigurert riktig, vil ikke et eneste antivirus forstyrre systemet, men hvis du bruker fabrikkinnstillingene, kan 1C-ytelsen reduseres med 5–10 %. Du kan optimalisere antivirusprogrammet ved å bruke tilleggsinnstillinger ved å fjerne bakgrunnsmodusen (hvis det er absolutt nødvendig).
• Dataparametere - ofte utilstrekkelig kraftige datamaskiner fører til en sterk reduksjon i 1C-ytelse. Spesiell oppmerksomhet bør rettes mot skjermkortet, operativsystemet og prosessoren.

Slike metoder vil optimalisere og fremskynde arbeidet i 1C betydelig for enhver bedrift eller bedrift, hvoretter ytelsen til programmet vil øke betydelig.

Oppdatert materiale

Kurs registrert på versjon 8.3 ved hjelp av MS SQL Server 2014 Og siste versjoner produktivitetsverktøy, med en detaljert beskrivelse av de nye innstillingene og funksjonene.

Hvori arbeid med 8.2 er også beskrevet i emnet.

To nye seksjoner: "Testing" og "Sikkerhetskopiering"

"Testing"-delen dekker både testing med testsenterkonfigurasjonen og automatisert testing. I tillegg vurderes spørsmål om utstyret for testing.

"Sikkerhetskopiering"-delen diskuterer problemene med å lage sikkerhetskopier fra bunnen av ved å bruke eksemplet med MS SQL Server. Den gir også informasjon om gjenopprettingsmodeller, hvordan de fungerer og hvordan de forholder seg til sikkerhetskopiering.

Materialformat endret

Med den kan du raskt finne informasjon om alle emnene som dekkes i kurset, og også bruke den som referanse når du støter på ytelsesproblemer.

Kurset er blitt mye mer detaljert

Flere detaljer og tekniske detaljer er lagt til om alle emner, noe som vil være svært nyttig for å forberede seg til 1C:Expert-eksamenen og testing for 1C:Professional om teknologiske spørsmål.

• Lagt til leksjoner for håndtering av unntak i en transaksjon
• Lagt til informasjon om hensiktsblokkering
• La til arbeid parallellbord når du bruker PostgreSQL
• Eksempel lagt til analysere en dødlås ved hjelp av teknologiloggen
• Lagt til informasjon om parallell drift av metadataobjekter i forskjellige moduser med forskjellige innstillinger.
• Lagt til informasjon om ny type mutex
• Lagt til detaljert beskrivelse 1C serverklyngeenheter, inkludert en beskrivelse av hovedtjenestefilene
• Oppdatert problemløsning for å forberede seg på 1C:Expert
• Lagt til unik behandling, som lar deg se nøyaktig hvilke poster når det gjelder metadata som for øyeblikket er låst
• Hele lagt til backup-delen
• Lagt til informasjon om mekanisme for å lagre og hente resultater
• Lagt til informasjon om lås levetid i ulike transaksjonsisolasjonsnivåer
• Lagt til informasjon om lasttesting og valg av passende utstyr
• Lagt til informasjon om bruk av mekanismen automatisert testing
• Lagt til informasjon om innvirkning av sortering på ytelsen forespørsler
• Lagt til informasjon om arbeid dynamiske lister
• Lagt til informasjon om anbefalte fremgangsmåter programmering
• La til nyttige skript og dynamiske visninger

Lagt til nye øvingsoppgaver

Mange av de ekstra oppgavene er basert på virkelige situasjoner fra optimaliseringsprosjekter.

Også lagt til oppdatert sluttoppgave som har blitt enda mer kompleks og interessant.

Støtte i Mastergruppen

Støtte er gitt på kursets leksjonssider. Du kan stille alle spørsmål om kursmateriellet.

Også deg få tilgang til hundrevis av spørsmål og svar på dem fra andre kursdeltakere.

Støttevarighet: opptil 4 måneder(avhengig av valgt versjon av kurset).

Du kan aktivere tilgang til mastergruppen i noen praktisk tid innen 100 dager etter kjøpet.

Medlemskrav

Det er ingen spesielle krav til kursdeltakere.

For å fullføre kurset må du ha minst minimal utviklingserfaring i 1C.

Du trenger en datamaskin med 1C 8.3 og Windows

Den sikre videospilleren fungerer bare i Windows-miljøer. Videovisning er ikke mulig i virtuelle miljøer og med fjerntilgangsverktøy.

Kurs- og kostnadsversjoner

Dette kurset har TRE versjoner: LITE, PROF, ULTIMAT.

De er forskjellige i formål, innhold, kostnader og vilkår for støtte i mastergruppen.

For kjøpere av kurset Diagnose Performance Issues

Kostnaden for kurset "Diagnose av 1C ytelsesproblemer: hva som spesifikt bremser systemet" vil være telle ved kjøp av kurset "Akselerasjon og optimalisering av systemer på 1C: Enterprise 8.3".

Du legger ganske enkelt inn en bestilling på den aktuelle versjonen av Optimaliseringskurset, mens du i bestillingen angir rabattkoden som ble sendt til deg etter kjøp av kurset «Diagnostisering av ytelsesproblemer».

For eksempel, med tanke på rabatten, vil LITE-versjonen koste 11 300 9 800 rubler.

Garanti

Vi har trent siden 2008, vi er trygge på kvaliteten på våre kurs og gir vårt standard 60 dagers garanti.

Dette betyr at hvis du begynte å ta kurset vårt, men plutselig ombestemte deg (eller for eksempel ikke har mulighet), så har du en 60-dagers periode til å ta en avgjørelse - og hvis du gjør en retur, refunderer vi 100 % av betalingen.

Avdragsbetaling

Kursene våre kan betales i avdrag eller i avdrag, også uten renter. Hvori du får tilgang til materialene umiddelbart.

Dette er mulig når du betaler fra enkeltpersoner i mengden 3000 rubler. opptil 150 000 rubler.

Alt du trenger å gjøre er å velge betalingsmetoden "Betaling via Yandex.Checkout". Deretter, på nettsiden til betalingssystemet, velg "Betal i avdrag", angi betalingsperioden og beløpet, fyll ut et kort spørreskjema - og i løpet av et par minutter vil du motta en avgjørelse.

Betalingsalternativer

Vi aksepterer alle viktige betalingsformer.

Fra enkeltpersoner- betalinger fra kort, betalinger med elektroniske penger (WebMoney, YandexMoney), betalinger via nettbank, betalinger gjennom kommunikasjonsbutikker og så videre. Det er også mulig å betale for bestillingen i deler (i delbetaling), inkludert uten tilleggsrente.

Begynn å legge inn en bestilling - og i det andre trinnet vil du kunne velge din foretrukne betalingsmetode.

Fra organisasjoner og enkeltentreprenører– ikke-kontant betaling, leveringsdokumenter leveres. Du legger inn en ordre – og du kan umiddelbart skrive ut en faktura for betaling.

Trening med flere ansatte

Våre kurs er laget for individuell læring. Gruppetrening på ett sett er ulovlig distribusjon.

Hvis en bedrift trenger å lære opp flere ansatte, tilbyr vi vanligvis "tilleggssett" som er 40 % billigere.

For å bestille et "ekstra sett" velg 2 eller flere kurssett i skjemaet fra det andre settet Prisen for kurset vil være 40 % billigere.

Det er tre betingelser for bruk av tilleggssett:

• du kan ikke kjøpe bare et ekstra sett hvis minst ett vanlig sett ikke har blitt kjøpt før (eller sammen med det).
• det er ingen andre rabatter for ekstra sett (de er allerede rabattert, det ville ha vist seg å være en "rabatt på rabatt")
• kampanjer (for eksempel kompensasjon på 7000 rubler) gjelder ikke for ekstra sett av samme grunn