Brukere klager ofte over at "1C 8.3 er treg": dokumentskjemaer åpnes sakte, dokumenter tar lang tid å behandle, programmet starter, rapporter tar lang tid å generere, og så videre.

Dessuten kan slike "feil" oppstå i forskjellige programmer:

Årsakene kan være forskjellige. Dette er ikke gjenopprettede dokumenter, en svak datamaskin eller server, 1C-serveren er feilkonfigurert.

I denne artikkelen vil jeg se på en av de enkleste og vanligste årsakene sakte arbeid programmer -. Denne instruksen vil være relevant for brukere av fildatabaser for 1-2 brukere, hvor det ikke er konkurranse om ressurser.

Hvis du er interessert i mer seriøs optimalisering av klient-server-alternativer for systemdrift, besøk delen av nettstedet.

Hvor er de planlagte oppgavene i 1C 8.3?

Før jeg rakk å laste programmet, utførte 1C mange bakgrunnsjobber. Du kan se dem ved å gå til "Administrasjon"-menyen, deretter "Støtte og vedlikehold":

Få 267 videotimer på 1C gratis:

Slik ser vinduet med fullførte oppgaver ut:

Og så full liste alle rutineoppgaver, som lanseres:

Blant disse oppgavene er som "", laste inn forskjellige klassifiseringer, sjekke relevansen til programversjonen og så videre. Jeg har for eksempel ikke bruk for nesten alle disse oppgavene. Jeg fører ikke valutaposter, jeg kontrollerer versjonene selv, og laster klassifiserere etter behov.

Følgelig er det i min (og i de fleste tilfeller i din) interesse å deaktivere unødvendige oppgaver.

Deaktivering av rutine- og bakgrunnsoppgaver i 1C 8.3

1) se på mengden minne som er tildelt av rphost på 1C-serveren. Hvis du har en x32-versjon av serveren, kan prosessen bruke maksimalt 1,75 GB RAM
Hvis det ikke er nok minne, kan ikke serveren godta nye tilkoblinger eller henger når den gjeldende økten krever ekstra minne
www.viva64.com/ru/k/0036
2) Se på "Working server settings"-innstillingene. innstillingene kan være feil. Jeg hadde dette problemet og serveren fortsatte å fryse. Mine innstillinger er vedlagt. Serveren er tildelt 11 GB.
3) Det kan være problemer med å sette opp Postgressql.

Oppgi egenskapene til serveren din, databasestørrelser, Postgressql-konfigurasjoner. Det er vanskelig å si uten informasjon.

Min PostgreSQL-konfigurasjon: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Denne konfigurasjonen er valgt for den tilgjengelige mengden RAM.
PostgreSQL installert på Linux, 3 GB RAM, 3 CPU-kjerner.
Server 1C8: 11 GB RAM, 5 CPU-kjerner
4 databaser, omtrent 1 GB hver (lastet opp til dt)

Gi alle egenskapene til serveren din: 1C8 server og database, fysisk eller virtuell, operativsystem, mengde RAM på hver server, hva slags CPU, hvor mye RAM tar rphost-prosesser opp, hvor mange er det? Bruker du et RAID-array?

Tidligere brukte jeg PostgreSQL selv, men under prosessen møtte jeg noen problemer når jeg kjørte en database på PostgreSQL og byttet nylig til MS SQL.

Serveren din er ikke dårlig for disse databasene. For å bruke PostgreSQL må du ha en veldig god forståelse av konfigurasjonen. Når databasene er små, tilgis mange konfigurasjonsfeil. Da vi nettopp begynte å implementere 1C + PostgreSQL, hadde vi også svært hyppige problemer med driften av databasen (det var hyppige fryser, det fungerte sakte). PostgreSQL er bedre brukt på Linux, ikke på Windows. Selv er jeg ikke databasespesialist for å sette opp databaseserveren, vi hyret inn en spesialist fra 1Sbit og han satte den opp for oss og det var ingen problemer i driften etter det.

Råd:
Du har store databaser, ikke spar, ansett en databasespesialist som kan sette opp for deg. Én person kan ikke være ekspert på alt.

1) hvor lenge siden har du sjekket selve databasen og indeksert den på nytt? VAKUUM og REINDEKS
2) hvor lenge siden testet og korrigerte du databasen ved hjelp av 1C-verktøy?
3) er databaseloggfilen plassert på en separat harddisk?
4) er harddisken tungt lastet?

Vurder å bytte til MS Sql ofte krever det "praktisk talt" ingen konfigurasjon og er enklere å bruke. I motsetning til PostgreSQL, er MS Sql klar til å fungere ut av esken, men PostgreSQL må konfigureres.

Hvis du har spørsmål, skriv, kanskje jeg kan hjelpe med noe på Skype: tisartisar

Ansett en databaseoppsettspesialist

Hvorfor vi byttet til MS SQL:
Vi bruker UT-konfigurasjonen og ved månedsavslutning oppsto det noen ganger feil som ikke kunne løses. Hvis du overførte databasen til filmodus og begynte å lukke måneden, lukket alt normalt, den samme databasen ble lastet inn i PostgreSQL-server Det oppsto feil ved beregning av kostnaden. På den tiden lå vi et halvt år etter i siste måneder på grunn av flytefeil. Vi opprettet en testdatabase på MS SQL og måneden som ikke kunne lukkes på PostgreSQL på MS SQL ble stengt. Prisavrunding i prislisten fungerer heller ikke riktig på PostgreSQL. Faktisk støttes det å kjøre 1C på PostgreSQL, men det anbefales fortsatt å bruke MS SQL.
På grunn av dette ble det besluttet å bytte til MS SQL fordi... driftsstabilitet 1C er dyrere.

Jeg er glad jeg kunne hjelpe, vennligst kontakt meg hvis du har spørsmål eller problemer.

1) hvor mye minne er allokert til MS SQL server? dette er konfigurert i selve MS SQL-serveren.
2) Test databasen med 1C regelmessig
3) artikkel om hvordan du setter opp backup og vedlikehold. Dette er viktig og må gjøres regelmessig. Jeg gjør det hver dag. Sjekk ut alle 3 delene av veiledningen.

I I det siste Brukere og administratorer begynner i økende grad å klage over at nye 1C-konfigurasjoner utviklet basert på en administrert applikasjon er trege, i noen tilfeller uakseptabelt trege. Det er tydelig at nye konfigurasjoner inneholder nye funksjoner og muligheter, og derfor er mer ressurskrevende, men de fleste brukere forstår ikke hva som først og fremst påvirker driften av 1C i filmodus. La oss prøve å rette opp dette gapet.

I vår har vi allerede vært inne på virkningen av produktivitet disk undersystem med en hastighet på 1C, derimot denne studien gjaldt lokal bruk av applikasjonen på en egen PC eller terminalserver. Samtidig innebærer de fleste små implementeringer å jobbe med en fildatabase 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 1C-ressurser viste det dette spørsmålet unngår det flittig hvis det oppstår problemer, anbefales det vanligvis å bytte til klient-server eller terminalmodus. Det har også blitt nesten allment akseptert at konfigurasjoner på en administrert applikasjon fungerer mye tregere enn vanlig. Som regel er argumentene "jern": "Regnskap 2.0 fløy bare, og "troikaen" beveget seg knapt, selvfølgelig er det noe sannhet i disse ordene, så la oss prøve å finne ut av det.

Ressursforbruk, første øyekast

Før vi startet denne studien satte vi oss to mål: å finne ut om administrerte applikasjonsbaserte konfigurasjoner faktisk er tregere enn konvensjonelle konfigurasjoner, og hvilke spesifikke ressurser som har den primære innvirkningen på ytelsen.

For testing tok vi to virtuelle maskiner som kjører henholdsvis Windows Server 2012 R2 og Windows 8.1, og allokerte dem med 2 kjerner av verten Core i5-4670 og 2 GB tilfeldig tilgangsminne, som tilsvarer omtrent 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 valgte vi flere konfigurasjoner av Accounting 2.0, utgivelse 2.0.64.12 , som deretter ble oppdatert til 3.0.38.52 , ble alle konfigurasjoner lansert på plattformen 8.3.5.1443 .

Det første som tiltrekker seg oppmerksomhet er den økte størrelsen på troikaens informasjonsbase, som har vokst betydelig, samt en mye større appetitt på RAM:

Vi er klare til å høre det vanlige: "hvorfor la de det til disse tre", 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å å vedlikeholde databaser. Også ansatte i spesialiserte selskaper som betjener (les oppdatering) disse databasene tenker sjelden på dette.

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 Testing og retting av informasjonsgrunnlaget. Kanskje spilte navnet en grusom spøk, som på en eller annen måte antyder at dette er et verktøy for feilsøking av problemer, men lav ytelse er også et problem, og restrukturering og reindeksering, sammen med tabellkomprimering, er velkjente verktøy for å optimalisere databaser for enhver DBMS-administrator . Skal vi sjekke?

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

Deretter, etter å ha lastet nye klassifiserere og kataloger, opprettet indekser, etc. størrelsen på basen vil øke generelt, de "tre" basene er større enn de "to" basene. Dette er imidlertid ikke viktigere, hvis den andre versjonen var fornøyd med 150-200 MB RAM, trenger den nye utgaven en halv gigabyte, 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 små bedriftsnettverk er bygget på grunnlag av billig 100 Mbit/s utstyr, så vi begynte å teste ved å sammenligne 1C ytelsesindikatorer i 100 Mbit/s og 1 Gbit/s nettverk.

Hva skjer ved oppstart fildatabase 1C over nettverket? Klienten laster ned nok til midlertidige mapper et stort nummer av informasjon, spesielt hvis dette er den første "kalde" starten. Ved 100 Mbit/s forventes vi å kjøre inn i kanalbredde og nedlasting kan ta betydelig tid, i vårt tilfelle ca 40 sekunder (kostnaden for å dele grafen er 4 sekunder).

Den andre lanseringen er raskere, siden noen av dataene er lagret i hurtigbufferen og forblir der til omstart. Bytte til et gigabit-nettverk kan øke hastigheten på programinnlastingen betydelig, både "kald" og "varm", og forholdet mellom verdier respekteres. Derfor bestemte vi oss for å uttrykke resultatet i relative verdier, og ta det meste veldig viktig hver måling:

Som du kan se av grafene, laster Accounting 2.0 med en hvilken som helst nettverkshastighet dobbelt så raskt, overgangen fra 100 Mbit/s til 1 Gbit/s 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å påvirkningen av nettverkshastighet på drift i tunge moduser, for eksempel under gruppeoverføringer. Resultatet er også uttrykt i relative verdier:

Her er det mer interessant, den optimaliserte basen til de "tre" i et 100 Mbit/s-nettverk fungerer med samme hastighet som de "to", og den ikke-optimaliserte viser dobbelt så dårlige resultater. På gigabit forblir forholdene de samme, den uoptimaliserte "tre" er også halvparten så treg som de "to", og den optimaliserte henger etter med en tredjedel. I tillegg lar overgangen til 1 Gbit/s deg redusere utførelsestiden med tre ganger for utgave 2.0 og med det halve for utgave 3.0.

For å evaluere innvirkningen av nettverkshastighet på det daglige arbeidet, brukte vi Prestasjonsmåling, utføre en sekvens av forhåndsbestemte handlinger i hver database.

Faktisk, for daglige oppgaver, er nettverksgjennomstrømning ikke en flaskehals, en uoptimalisert "tre" er bare 20 % tregere enn en "to", og etter optimalisering viser det seg å være omtrent det samme raskere - fordelene ved å jobbe i tynnklientmodus er tydelige. Overgangen til 1 Gbit/s gir ikke den optimaliserte basen noen fordeler, og den uoptimerte og de to begynner å jobbe raskere, og viser en liten forskjell mellom seg.

Fra de utførte testene blir det klart at nettverket ikke er en flaskehals for nye konfigurasjoner, og den administrerte applikasjonen kjører enda raskere enn vanlig. Du kan også anbefale å bytte til 1 Gbit/s hvis tunge oppgaver og databaselastingshastighet er kritisk for deg. I andre tilfeller lar nye konfigurasjoner deg jobbe effektivt selv i trege 100 Mbit/s-nettverk.

Så hvorfor er 1C treg? Vi skal se nærmere på det.

Serverdiskundersystem og SSD

I forrige artikkel oppnådde vi en økning i 1C-ytelse ved å plassere databasene på en SSD. Kanskje ytelsen til serverens diskdelsystem er utilstrekkelig? 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 store antallet input/output-operasjoner per sekund (IOPS) - 913, oversteg ikke kølengden 1,84, noe som er et veldig godt resultat for en to-disk-array. Basert på dette kan vi anta at et speil laget av 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? Den beste måten å svare på dette spørsmålet på er gjennom testing, som vi utførte med en lignende metode, Nettverkstilkobling overalt 1 Gbit/s, er resultatet også uttrykt i relative verdier.

La oss starte med lastehastigheten til databasen.

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

La oss gå videre til å gjøre om:

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

I hverdagsoppgaver er bildet likt:

Bare den ikke-optimaliserte databasen drar nytte av SSD-en. Du kan selvfølgelig kjøpe en SSD, men det ville være mye bedre å tenke på rettidig vedlikehold av databasen. Ikke glem å defragmentere delen med infobaser på serveren.

Klientdiskundersystem og SSD

Vi analyserte påvirkningen av SSD på driftshastigheten til lokalt installert 1C in, mye av det som ble sagt er også sant for arbeid i nettverksmodus. Faktisk bruker 1C ganske aktivt diskressurser, inkludert for bakgrunns- og rutineoppgaver. I figuren under kan du se hvordan Accounting 3.0 ganske aktivt får tilgang til disken i ca. 40 sekunder etter innlasting.

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

Langsom HDD kan bremse enkelte operasjoner, men kan ikke i seg selv få programmet til å bremse ned.

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. Allerede basert på det faktum at den gjennomsnittlige "troikaen" krever omtrent 500 MB minne, kan vi anta at en total mengde RAM på 1 GB ikke vil være nok til å fungere med programmet.

Vi reduserte systemminnet til 1 GB og lanserte to informasjonsdatabaser.

Ved første øyekast er ikke alt så ille, programmet har dempet appetitten og passet godt inn i det tilgjengelige minnet, men la oss ikke glemme at behovet for driftsdata ikke har endret seg, så hvor ble det av? Tilbakestill til disk, hurtigbuffer, swap, etc., essensen av denne operasjonen er at unødvendig dette øyeblikket data sendes fra rask RAM, mengden som ikke er nok, til treg diskminne.

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

Som vi kan se, bruker systemet aktivt nettverket til å motta data og prosessoren til å behandle den er ubetydelig under behandlingen, 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 tilgang til disken. For eksempel tok det omtrent 20 sekunder å åpne journalen Salg av varer og tjenester og ble ledsaget hele denne tiden av høy diskaktivitet (uthevet med en rød linje).

For å objektivt evaluere virkningen av RAM på ytelsen til konfigurasjoner basert på en administrert applikasjon, utførte vi tre målinger: lastehastigheten til den første databasen, lastehastigheten til den andre databasen og gjenkjøring av gruppe i en av databasene . Begge databasene er helt identiske og ble opprettet ved å kopiere den optimaliserte databasen. Resultatet er uttrykt i relative enheter.

Resultatet taler for seg selv: hvis lastetiden øker med omtrent en tredjedel, noe som fortsatt er ganske tolerabelt, øker 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.

Mangel på RAM er hovedårsaken til at det å jobbe med nye 1C-konfigurasjoner viser seg å være ubehagelig. Konfigurasjoner med 2 GB minne om bord bør anses som minimalt egnet. Samtidig må du huske at i vårt tilfelle ble det opprettet "drivhus"-forhold: et rent system, bare 1C og oppgavebehandleren kjørte. I det virkelige liv på en arbeidsdatamaskin, som regel er en nettleser, en kontorpakke åpne, et antivirus kjører osv. osv., så fortsett fra behovet for 500 MB per database pluss litt reserve, slik at du gjør det under tunge operasjoner ikke støter på mangel på hukommelse og en kraftig nedgang i produktivitet.

prosessor

Uten overdrivelse kan sentralprosessoren kalles hjertet til datamaskinen, siden det er den som til slutt behandler alle beregninger. For å evaluere dens rolle, gjennomfø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, og testen ble utført to ganger med minnemengder på 1 GB og 2 GB.

Resultatet viste seg å være ganske interessant og uventet: en kraftigere prosessor tok ganske effektivt på seg belastningen når det var mangel på ressurser, resten av tiden uten å gi noen konkrete fordeler. 1C Enterprise (i filmodus) kan knapt kalles en applikasjon som aktivt bruker prosessorressurser det er ganske lite krevende. Og under vanskelige forhold belastes prosessoren ikke så mye ved å beregne dataene til selve applikasjonen, men ved å betjene overheadkostnader: ekstra input/output-operasjoner, etc.

konklusjoner

Så hvorfor er 1C treg? 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, men de "tre" er ugudelige trege.

På andreplass er nettverksytelsen; en treg 100 Mbit/s-kanal kan bli en skikkelig flaskehals, men samtidig klarer tynnklientmodusen å opprettholde et ganske komfortabelt driftsnivå selv på trege kanaler.

Da bør du ta hensyn til diskstasjonen; å kjøpe en SSD vil neppe være en god investering, men å bytte ut disken med en mer moderne vil være en god idé. Forskjellen mellom generasjoner harddisk kan vurderes av til følgende materiale: .

Og til slutt prosessoren. En raskere modell vil absolutt ikke være overflødig, men gir mye mening Det er ingen måte å øke ytelsen på, med mindre denne PC-en brukes til tunge operasjoner: gruppebehandling, tunge rapporter, lukking av måneden, etc.

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

• Tagger:

Aktiver JavaScript for å se

Virkningen av blokkering på ytelsen til 1C:Enterprise 8

Gilev-teamet har jobbet med ytelsesspørsmål i mange år og har med suksess løst blant annet problemene med å eliminere ventetider på låser og vranglåser.

Nedenfor vil vi beskrive vår erfaring med å løse disse problemene.

Deteksjon av blokkeringsproblemer i 1C

Ytelsesproblemer i flerspillermodus er ikke nødvendigvis relatert til dårlig kode eller dårlig maskinvare. Først må vi svare på spørsmålet - hvilke ytelsesproblemer eksisterer og hva forårsaker dem?

Det er umulig å manuelt spore aktivitetene til hundrevis av brukere, du trenger et verktøy som automatiserer innsamlingen av slik informasjon.

Det er mange verktøy, men nesten alle av dem har en veldig betydelig ulempe - prisen.

Men det er en vei ut – vi velger

Vi vil undersøke problemet på MS SQL Server, så vi trenger følgende tjenester fra dette settet:

1. Overvåking og analyse av lange forespørsler(les mer om oppsett her) - nødvendig for å vurdere om det er langtidsdrift for subd.

Faktisk tillater faktumet av deres tilstedeværelse oss å si at det er ytelsesproblemer, og problemene ligger i linjene med 1C-konfigurasjonskode, som tjenesten vil rangere etter viktighet. Problemer øverst på listen må løses først. Slike løsninger på problematiske linjer vil gi størst effekt, d.v.s. vil være til størst nytte og fordel for brukerne av systemet.

(les mer her) vil tillate oss å vurdere om tiden med lange (lange) forespørsler faktisk er forårsaket av venting på låser eller det er andre årsaker (ikke-optimal kode, overbelastet maskinvare osv.) Tjenesten vil vise årsaken til ventetiden ved forespørselen, nemlig ressursen som ble blokkert og hvem som blokkerte ham. De. vi vil forstå tilstedeværelsen av blokkeringsproblemer og årsakene deres.

3. Analyse av gjensidige låser i 1C og MS SQL server(les mer om oppsettet her) - vil tillate oss å vurdere mer vanskelige situasjoner med å vente på ressurser, når flere deltakere allerede har klart å «fange» noen ressurser ved å blokkere og nå er tvunget til å vente på hverandre på grunn av at de ikke kan frigi okkuperte ressurser før fangst av andre ressurser blokkert av naboer er fullført.

Generelt kan en slik vanskelig situasjon ikke løses manuelt.

4. Kontroll av utstyrsbelastning(les mer om oppsettet her) hjelper oss med å svare på spørsmålene – hvor mange brukere er i systemet, har de låser, hvor mange låser er det, tåler maskinvaren belastningen?

Tjenester er veldig enkle å sette opp, men selv om du fortsatt har spørsmål, er det det!

Ved å bruke verktøyene som er oppført ovenfor, har vi objektiv informasjon om systemytelse. Dette gjør at vi kan vurdere situasjonen korrekt og foreslå tilstrekkelige tiltak.

Faktisk mottar vi informasjon om alle ytelsesproblemer og kan svare nøyaktig på spørsmål som "hvor mange problemer er i systemet", "hvor nøyaktig oppstår de", "hver av problemene med nøyaktig hvilken frekvens som oppstår", "hvilke problemer er betydelige og som er mindre». De. vi ser alle forutsetningene som dannet årsaken til problemet.

Tjenester lar deg forbedre forståelsen din av forholdene under hvilke problemer oppstår, uten å tvinge deg til å fordype deg manuelt i slike ting som datalagringsstrukturen til informasjonsbasen på DBMS-nivå, låsemekanismen, etc.

Som et resultat får vi et bilde av ytelse som måles

— forespørselstid (selvfølgelig rangering av problematiske forespørsler etter vekt (forespørselstid etter antall anrop til denne forespørselen);

— ventetid for låser;

Så vi lanserte tjenesten Analyse av forventninger om blokkering

I den øverste tabellen viser tjenesten en liste over "ofre" for blokkering, tatt i betraktning den totale vekten av "vekten av forventninger."

I den nedre tabellen vurderes for hvert offer en eller flere deltakere i "kampen for en svært konkurransedyktig ressurs", der blokkeringsventingen oppsto.

I den nedre tabellen åpner du detaljene for en av "timeout"-hendelsene. Som på bildet for eksempel.

Ved å markere linjen med "synderen", vil vi se at flaskehalsen var _Reference64-tabellen, og det oppsto et problem på den grupperte indeksen med det "ukjente" området. Kanskje i fremtiden vil vi gi det nytt navn til "tabell", siden denne oppførselen faktisk er typisk for å øke/forstørre blokkeringsområdet.

Linjen med "offeret" viser hvilken kode som var et gissel for situasjonen og ikke kunne blokkere alt, bare linjen "med nøkkel" (minste datablokkeringsområde i denne tabellen).

Dette problemet kan løses "riktig" og "enkelt".

Av den riktige måten det er vanskeligere å gjøre - du må faktisk skrive om koden, og minimere sannsynligheten for at slike situasjoner oppstår.

En av faktorene, hvor merkelig det enn kan høres ut, er en reduksjon i varighet.

Du kan redusere transaksjonsvarigheten:

1. omskriving av algoritmen

2. ved å omskrive spørringen (en raskere spørring reduserer sannsynligheten for låsinger i komplekse transaksjoner på tabeller, som noen ganger kanskje ikke en gang er med i spørringen!)

2.1 legge til den manglende dekkende indeksen (noen ganger øker en indeks ikke bare søket, men reduserer også dataleseområdet, noe som reduserer sannsynligheten for blokkering)

3. redusere mengden data som behandles i en transaksjon (i tillegg til lineær hastighet husker vi også låseskalering)

4. øke utstyrsproduktiviteten innenfor hver flyt

Be om utførelsestid

1) ulike brukere kan arbeide parallelt med ulike data
2) forskjellige brukere må jobbe strengt sekvensielt med de samme dataene

Det er imidlertid mulig å optimere bruken av låser, og dermed redusere den totale ventetiden.

Hvordan blokkering fungerer (du trenger ikke å lese dette avsnittet)

En spesiell SQL Server-modul, Lock Manager, håndterer låser. Hans oppgaver inkluderer:

• opprette og installere låser;
• opplåsing;
• eskalering av blokkering;
• bestemme låskompatibilitet;
• eliminere vranglås og mye mer.

Når en bruker gjør en forespørsel om å oppdatere eller lese data, overfører DBMS-transaksjonsbehandleren kontrollen til DBMS-låsebehandleren for å bestemme om de forespurte ressursene har blitt låst, og i så fall om den forespurte låsen er kompatibel med den gjeldende. Hvis låser er inkompatible, blir utføringen av den gjeldende transaksjonen forsinket til dataene er låst opp. Når dataene er tilgjengelige, anskaffer låseadministratoren den forespurte låsen og returnerer kontrollen til transaksjonsadministratoren.

Hovedårsaken til at ytelsen reduseres er blokkering

Venter på lås er et stort ytelsesproblem i flerspillermodus. Og dette er forståelig, fordi de øker ventetiden på operasjoner, og dermed responstiden. Er det mulig å si at venting på låser ikke er riktig og en feil i et flerbrukersystem? Dette kan ikke sies, siden ressursblokkeringsmekanismen i seg selv sikrer dataintegritet. Ved å bruke låsemekanismen, SKRIVES samtidig data som følge.

Forskjellen mellom nødvendige og unødvendige låser

Når en bruker rapporterer en feil som venter på en lås, så er dette fra hans synspunkt alltid en feil, fordi det for eksempel forstyrrer arbeidet hans - tiden det tar å fullføre arbeidet hans øker.

Erfaring antyder en enkel regel: hvis mer enn halvparten av forespørselsutførelsestiden faktisk venter på en blokkert ressurs, må du se: kanskje du kan optimalisere noe av låsingen og redusere ressursblokkeringstiden.

Her, som ved en tilfeldighet, introduserer jeg en definisjon:

Venter på blokka er en situasjon som oppstår når to brukere prøver å fange opp de samme dataene samtidig. I dette tilfellet blir en av disse brukerne blokkert, det vil si at den må vente til slutten av den første brukerens transaksjon.

En transaksjon er et sett med beregninger og operasjoner med data (de fleste lysende eksempel— når du utfører et dokument) utført som en helhet. Unnlatelse av å utføre noen av transaksjonsoperasjonene resulterer i kansellering av hele transaksjonen.

Så brukere i flerbruker infobaser kan ofte klage over at det er umulig å jobbe på grunn av disse låsene, mens det i koden faktisk kan være låser som ikke er nødvendig på dette stedet (overflødig).
Og også i konfigurasjonskoden kan det hende at de selv ikke er til stede, for eksempel kan du lese om dem her http://kb.1c.ru/articleView.jsp?id=30 (artikkelen er et fragment av boken; av P.S. Belousov, A .V.Ostroverh "1C:Enterprise: fra 8.0 til 8.1."). Jeg tilbyr en forenklet måte å forklare forskjellene mellom låser på enkelt eksempel Så:

I konfigurasjonen din i 1C:Enterprise-modus oppretter du to identiske fakturaer med samme varesammensetning. Men husk å angi de forskjellige mottakslagrene.
I posteringsbehandlingskoden må du legge til en linje med en melding som vises på skjermen (eller annen kode som kan forsinke utførelsen av posteringsbehandlingen med 21 sekunder (blokkeringstidsavbruddet inntreffer etter 20 sekunder hvis parametrene er som standard)) .
Legg ut to dokumenter.
Dersom det oppstår en timeout, og logisk nok kommer varene til forskjellige varehus, er det redundante låser i applikasjonen. Forretningslogikk (vurder sunn fornuft) det bør ikke være noen blokkering her.
Hvis vi nå lager identiske varehus i disse to fakturaene. Da vil blokkeringen opprettet som følge av forsøk på samtidig utførelse føre til en NØDVENDIG blokkering og dette er BRA!

De. Mens fakturaen gjør endringer i lagersaldoene, må den andre vente.

Selv dette enkle eksemplet etterlater selvfølgelig mange spørsmål. For eksempel, hva om dokumentene er fra én leverandør og gjelden på den "flytter". Og hvis det ikke bare er saldoene på lageret som flytter, men flere registre og dokumenter av ulike typer.
Men det viktigste spørsmålet er: VED HVILKEN FORRETNINGSLOGIKK SKAL DET IKKE VÆRE BLOKKERINGER. Hvem foreskriver denne forretningslogikken og hvor i blokkeringssammenheng? Men la oss snakke om alt i rekkefølge.

Overdrevne låser er unødvendige låser som ikke er nødvendige med tanke på å sikre dataintegritet og samtidig redusere den generelle ytelsen til systemet, noe som øker den totale nedetiden - venter på låser.
Nødvendig låsing oppstår når to brukere anskaffer de samme ressursene (dataobjekter). Hvis brukere jobber med ikke-overlappende ressurser, men venter på en lås, anses låsen som overflødig.

De mest forståelige kriteriene for låsing av redundans er:

1. Gjensidige låser;

2. Blokkeringsnivået (området) er høyere enn nødvendig (som spesielt tilfelleøke blokkeringsnivået, det såkalte. eskalering);

3. Låsetiden er lengre enn tiden for "reell" bruk av låseobjektet.

Etter å ha mottatt informasjon om grupperinger av problemer i sammenheng med 1C:Enterprise-metadata, anbefaler jeg først og fremst å være oppmerksom på følgende objekter:

• Konstanter
• Etterfølge
• Regnskapsregistre
• Akkumulasjonsregistre
• Informasjonsregistre
• Beregningsregistre

1) Inntil nylig var det en velkjent anbefaling om ikke å skrive noe inn i konstanter. I ekstreme tilfeller, gjør dette fra under én bruker, og husk at mens brukeren "skriver" en konstant, ikke bare denne, men også en hvilken som helst annen konstant, vil andre brukere "vente". Derfor er det spesielt farlig å bruke konstanter i transaksjonsbehandlingen. Verdiene til alle konstanter lagres V én ressurs.

Figuren viser den fysiske plasseringen av SCP-konfigurasjonskonstanter i en MS SQL Server 2005-databasetabell.

Dette betyr at låsing av én konstant vil låse alle konstanter. DBMS pålegger en lås på HELE enkeltraden i tabellen, dvs. for alle konstanter.

I de siste utgivelsene av plattformen har imidlertid lagringen av konstanter blitt endret. Nå er hver konstant en egen tabell. Ikke la deg rive med, men hvis du lager tusenvis av bord, kan du få en lås på masterbasen.

Merk, hvis konfigurasjonen din har eksistert lenge, kan du endre lagringsformatet ved å "restrukturere" det i Testing og korrigering av konfiguratoren.

2) Nekt å bruke Sequence-metadataobjektet. I hvert fall fra bevegelser når operativ gjennomføring, utføres under ikke-operative (ytterligere) prosedyrer. Se hvordan det implementeres i siste versjoner UPP.

3) Hvis systemet utfører online registrering av bevegelser i regnskapsregisteret i flerbrukermodus, anbefales det:

• aktiver totalseparasjonsmodus for dette registeret;
• Ikke bruk registerbalansekontroll under operativt arbeid.

4) I akkumuleringsregisteret, i tilfeller der det ikke er behov for å innhente "operative" data, kan du aktivere deling av totaler, noe som vil øke parallelliteten til dataregistrering og øke hastigheten på arbeidet generelt. Overvåk målingene nøye slik at "restene" kan oppnås med maksimal detalj i målingene.

5) Du kan bli kvitt noen av de overflødige låsene som er opprettet av plattformen kun ved . I den automatiske driftsmodusen for konfigurasjoner "tar plattformen på seg" blokkeringsressurser. Bekymringsfri pris automatisk modus— Låser er mulig ved grensene til indeksområder, låser på et tomt bord og låseskalering.

Disse låsene forsvinner helt fra dataene i transaksjonen. Det vil si at denne forriglingen ikke vil være mulig ved drift i kontrollert modus.

Jeg har allerede sagt "administrerte låser" og "administrerte modus" flere ganger. Du må forstå at det er to typer låser:
DBMS-låser installeres automatisk på DBMS-nivå når spørringer utføres.
1C:Enterprise-låser installeres automatisk når du skriver (endrer) data og alltid manuelt når du leser data.

En nitid leser vil si at 1C også deler inn i objekt- og ikke-objektlåser, men nå skal vi ikke berøre denne tilnærmingen.

Men jeg legger merke til at det stiller flere krav til kvalifikasjonene og erfaringen til en 1C-spesialist.

6) Manglende indekser (spesielt i komplekse søk) er generelt hovedfaktoren for at det oppstår et høyere nivå av låsing enn nødvendig. De. paradoks, på den ene siden sa jeg at før jeg optimaliserte spørringen sa jeg at du først må se på låsene, men nå sier jeg at for å optimalisere låsene, må du optimalisere spørringen. Jeg har en unnskyldning, å bytte konfigurasjonen til administrerte låser reduserer redundante låser selv i en ikke-optimal spørring. Dette oppstår på grunn av en reduksjon i transaksjonsisolasjonsnivået, som igjen gir DBMS-låseadministratoren færre grunner til å pålegge en overdreven låsing.

Hovedårsakene til overdreven låsing (for å oppsummere det ovenstående)

— designfeil
(graden av parallellitet bestemmes av "hvor fint dataene er kuttet": parallelt arbeid med to rader i tabellen er mulig, arbeid med en rad vil bare skje sekvensielt)
(feil ved bruk av metadata: registrering av konstanter, sekvenser, driftsregnskap på regnskapsregistre)
— overdreven låsing på grunn av feilen i den automatiske modusen (plattform-DBMS-kombinasjon).
- suboptimal søkeytelse
(for eksempel, når du skanner en tabell, er hele bordet låst - redundant område
og blokkeringstiden øker - overdreven tid, et ekstra antall blokkeringer øker sannsynligheten for blokkeringseskalering)

Som du kan se, er oppgaven med å optimalisere låser "mangsidig". Du må være så tydelig som mulig om "konteksten" som forårsaket problemet. På hvilke ressurser, hvilken kode. Hvor mye er egentlig denne blokkeringen nødvendig, eller er den overflødig?

Et barn og en voksen har sår hals. Når legen stiller spørsmålet "Hva er galt?", vil barnet se på legen og skrike (stol på meg, jeg vet), mens den voksne vil påpeke symptomene på sykdommen. Disse tilsynelatende forskjellene leder legen til forskjellige metoder for å identifisere problemet.
Med et barn må legen utføre mye av tester, samler inn data, kombinerer dem, utfører analyser og først deretter gi anbefalinger. Mens med en voksen vil han stille flere spørsmål, og siden antallet innledende data er lite, vil tiden for analyse og bestemmelse av problemet være betydelig mindre. Som et resultat vil anbefalinger bli gitt mye tidligere.

Bruk våre tjenester og du vil få flere muligheter til å analysere problemet gratis og finne en løsning!

Brukerklagen «1C henger», som er godt kjent for IT-spesialister, har mange årsaker. For å gjøre en riktig "diagnose" - identifisere og analysere et problem, krever det reproduksjon, fordi et problem som ikke kan reproduseres, som regel er nesten umulig å løse. Etter å ha forstått symptomene på 1C-frysing, vil vi ta det første skrittet mot et effektivt fungerende system.

Veldig lang systemoppstart

En lang lansering av en tung konfigurasjon under én bruker for første gang etter å ha lagt informasjonssikkerhet til listen over databaser på datamaskinen er et normalt fenomen. Under den første lanseringen bufres konfigurasjonen. Den andre og påfølgende kjøringen bør være raskere.

Systemoppstart som tar lang tid kan indikere problemer med den arkitektoniske implementeringen av konfigurasjonen. Det meste av konfigurasjonen leses av plattformen kun første gang det ønskede metadataobjektet åpnes. En lang oppstart indikerer sannsynligheten for bruk stort nummer metadataobjekter (mange anrop til ulike vanlige moduler, prosessering osv.).

Det bør tas i betraktning at første gang teksten til en modul åpnes, blir den kompilert. Denne prosessen tar også tid, noe som er spesielt merkbart hvis det er mange moduler. Dermed løses problemet med langsom oppstart ved å modifisere (optimalisere) konfigurasjonen, hvis formål er å deaktivere kjøringen av alle valgfrie algoritmer som kjøres ved systemoppstart.

Det er en mulighet for at konfigurasjonen prøver å lese data fra Internett når den starter. Dette øker også systemets oppstartstid.

Veldig lang åpning av skjemaer

Lang åpning av skjemaer kan skyldes:

1. Et stort antall kontroller på skjemaet - tid brukes på å lage skjemaet og koble sammen arrangementet av skjemaelementer;
2. Utførelse av algoritmer under skjemainitialisering. Det er mulig at når skjemaet opprettes, sjekkes noen forhold og/eller relaterte objekter leses fra databasen.

Det første problemet "behandles" ved å forenkle skjemaet. For eksempel kan noen kontroller plasseres i separate former, noe som til og med kan være mer praktisk for brukeren. For eksempel, hvis skjemaet har et adressefelt "By", "Gate", "Hus", etc., så er det bedre å redigere adressen i et eget skjema.

Det andre problemet løses ved å analysere handlingene som utføres når du oppretter og åpner et skjema, og optimaliserer disse algoritmene. Kanskje er noen av algoritmene allerede utdaterte, mens andre kan forenkles og optimaliseres, for eksempel eliminere eller minimere tilgangen til data i databasen.

Som en interaktiv handling bør du vurdere brukeren som prøver å velge en verdi på et skjemaelement. Som svar på det, "tenker systemet på noe." Dette kan skje av følgende årsaker:

1. Algoritmene som kjører i denne handlingen undersøker eller beregner tilknyttede data som påvirker verdivalgsatferden;
2. Velg-skjemaet som åpnes for å velge denne verdien, leser alle objekter fra databasen når de initialiseres.

For å løse det første problemet, bør du bruke "Performance Measurement", finne ressurskrevende algoritmer og optimalisere dem.

Det andre problemet kan ofte løses ved ganske enkelt å analysere gjennomføringen av valgskjemaet. Du bør for eksempel sørge for at egenskapen "Dynamisk datalesing" er satt for en dynamisk liste, at egenskapen "Hovedtabell" er riktig satt, og at listeimplementeringen ikke bruker åpenbart ressurskrevende algoritmer.

Det er også situasjoner der, når du åpner utvalgsskjemaet, noen relaterte data leses fra databasen (for eksempel når du åpner "Vare"-utvalgsskjemaet, leses varebalansen i varehusene). Vanligvis er dette ikke det Den beste avgjørelsen. Det er bedre å lese relaterte data asynkront etter å ha åpnet skjemaet. Dette vil gi mindre ubehag for brukeren, pga Etter at skjemaet er vist, vil brukeren bruke litt tid på å absorbere skjemaet, og denne tiden kan brukes til å laste inn relaterte data.

Veldig lang respons på oppdateringer

Et av de trivielle symptomene kan imidlertid fortelle om noen systemproblemer: 1C-oppdateringen fryser når du starter en sikkerhetskopi. Dette skjer hovedsakelig når du oppdaterer via Internett og indikerer mest sannsynlig at konfigurasjonen ikke har blitt oppdatert på lenge og utgivelsene, rullende etter hverandre, forårsaket en frysing. Du kan forhindre et slikt problem ved å installere oppdateringer i tide, og hvis du støter på det, kan du ganske enkelt avbryte sikkerhetskopieringsprosessen. Etter å ha startet konfiguratoren vil databasen starte med endringene som er gjort i normal modus.

Det skal bemerkes at 1C 8.3 fryser under oppdateringer oftest også fordi den krever mer ressurskrevende maskinvare enn tidligere versjoner plattformer. Det er verdt å ta hensyn til mengden RAM og om nødvendig øke den - dette skal i prinsippet bidra til å løse problemet "1C fryser når du oppdaterer konfigurasjonen."

Lang prosess med registrering av objekter/utføring av dokumenter

I dette tilfellet er "behandling basert på fotografering" praktisk talt utelukket, siden årsakene kan være svært forskjellige, fra en stor mengde data i objektet til å vente ved låser.

Men selv i DETTE tilfellet er det mulig å skissere en retning for analyse.

Fraværet av betydelige endringer i opptakstid på grunn av tidspunktet på dagen eller antall brukere (som et grovt, subjektivt estimat) indikerer et problem i koden eller i datamengden til objektet. For analyse er det fornuftig å bruke verktøyet "Performance Measurement".

En dramatisk endring i registreringstid med uklare avhengigheter krever at man utfører en statistisk analyse av forekomsten av problemet, dvs. ytelsesanalyse. Den enkleste måten er å analysere bruken av loggboken. En ekstra fordel her er at 1C:Enterprise 8-plattformen støtter lagring av loggdata til en fil i SQLite-format. Dette vil tillate deg å bruke SQL-spørringer til å analysere loggdata. Det er fullt mulig å hente objektskrivetiden fra loggdataene, gitt det faktum at hver objektskriving utføres i en transaksjon, og hver transaksjon har sitt eget identifikasjonsnummer.

Hvis resultatet av statistisk analyse viste at opptakstiden til et objekt avhenger av tidspunktet på dagen, og ikke antall brukere, er det nødvendig å analysere belastningen på 1C-serveren og databaseserveren. Det er mulig at serveren kjører rutineprosesser som tar opp unødvendige ressurser.

Hvis tiden det tar å skrive objekter avhenger av antall brukere, ligger problemet mest sannsynlig i koden (eventuelt venter på låser) eller i maskinvaregjennomstrømningen. For å løse dem bør du involvere en spesialist med kompetansen «1C: Expert in teknologiske problemer", siden det ikke er noen enhetlige regler for å løse et slikt problem.