1s er tregere på den nye serveren hvorfor. Automatiseringstips

Denne artikkelen diskuterer hovedfaktorene: når 1C bremser ned, fryser 1C og 1C fungerer sakte. Dataene ble utarbeidet basert på SoftPoints mangeårige erfaring med å optimalisere store IT-systemer bygget på kombinasjonen 1C + MS SQL.

Til å begynne med er det verdt å merke seg myten om at 1C ikke er ment for det samtidige arbeidet til et stort antall brukere, aktivt støttet av forumbrukere som finner trygghet i disse innleggene og en grunn til å la alt være som det er. Med nok tålmodighet og kunnskap kan du bringe systemet til et hvilket som helst antall brukere. Langsom drift og frysing av 1C vil ikke lenger være et problem.

Fra praksis: Den enkleste måten å optimalisere på er 1C v7.7 (Optimalisering av 1C 8.1, 1C 8.2, 1C 8.3 er en vanskeligere oppgave, siden applikasjonen består av 3 lenker). Å bringe den opp til 400 samtidige brukere er et ganske typisk prosjekt. Opptil 1500 er allerede vanskelig og krever hardt arbeid.

Den andre myten: for å forbedre ytelsen til 1C og bli kvitt 1C fryser, må du installere en kraftigere server. Som regel er det i optimaliseringsprosjekter i 95 % av tilfellene mulig å oppnå akseptabel ytelse enten uten en oppgradering i det hele tatt, eller ved å oppdatere en mindre del av utstyret, for eksempel ved å legge til RAM. Det skal bemerkes at utstyret fortsatt må være serverbasert, spesielt diskundersystemet. Et utdatert diskundersystem er bare en av grunnene til at 1C fungerer sakte.

Hovedbegrensningen ved arbeid med flere brukere i 1C er låsemekanismen. Det er blokkeringen i 1C, og ikke serverutstyret, som vanligvis hindrer et stort antall personer i å jobbe i databasen. For å overvinne dette problemet må du jobbe hardt og endre låselogikken i 1C - senke dem fra tabellbasert til radbasert. Da vil for eksempel poste et dokument blokkere kun ett, og ikke alle dokumenter i systemet.

Figur 1. 1C blokkeringskø i PerfExpert overvåkingssystem, med informasjon om 1C-brukere, en konfigurasjonsmodul og en spesifikk kodelinje i denne modulen.

Å endre 1C-låsemekanismen er en svært kompleks teknologi. Ikke alle kan ta et slikt triks, og for dem er det bare én vei igjen - å optimalisere strukturen og fremskynde gjennomføringstiden for operasjoner. Faktum er at blokkering i 1C og utførelsestiden for operasjoner er svært sammenhengende indikatorer. For eksempel, hvis operasjonen med å legge ut et dokument tar 15 sekunder, så hvis det er et stort antall brukere, er det stor sannsynlighet for at noen andre under overføringen vil prøve å legge ut dokumentet og vil vente med å blokkere. Hvis du øker utførelsestiden til minst 1 sekund, vil 1C-blokkering for denne operasjonen reduseres betydelig.

Mer farlig fra et blokkeringssynspunkt er gruppebehandling, som kan ta lang tid å fullføre og samtidig forårsake 1C-blokkering. Enhver behandling som endrer dataene, for eksempel gjenoppretting av sekvensen eller batchbehandling av dokumenter, låser tabellene og hindrer andre brukere i å legge ut dokumenter. Naturligvis, jo raskere disse behandlingene utføres mindre tid blokkerer og gjør det enklere for brukere å jobbe.

Tunge rapporter som utfører skrivebeskyttede operasjoner kan også være farlige når det gjelder låsing, selv om det ser ut til at de ikke låser data. Slike rapporter påvirker intensiteten av blokkering i 1C, og bremser andre operasjoner i systemet. Det vil si at hvis rapporten er veldig tung og tar opp mesteparten av serverens ressurser, kan det vise seg at før rapporten ble lansert, ble de samme operasjonene utført i 1 sekund, og under rapportkjøringen ble de utført i 15 sekunder . Naturligvis, ettersom utførelsestiden for operasjoner øker, vil blokkeringsintensiteten også øke.

Figur 2. Last på fungerende server i form av konfigurasjonsmoduler, fra alle brukere. Hver modul har sin egen farge. Det er en tydelig ubalanse i belastningen skapt fra 1C.

Grunnregelen for optimalisering er at dokumentbehandling skal ta et minimum av tid og kun utføre nødvendige operasjoner. Registerberegninger brukes for eksempel ofte i konteringsbehandling uten å spesifisere filtreringsbetingelser. I dette tilfellet må du spesifisere filtre for registre som lar deg oppnå den beste selektiviteten, uten å glemme at i henhold til filtreringsbetingelsene, må registeret ha passende indekser.

I tillegg til å lansere tunge rapporter, kan ikke-optimale innstillinger for MS SQL og MS Windows redusere utførelsestiden for operasjoner og derfor øke intensiteten til 1C-blokkering. Dette problemet forekommer hos 95 % av klientene. Det bør bemerkes at dette er servere til seriøse organisasjoner, hele avdelinger med høyt kvalifiserte administratorer er involvert i deres støtte og konfigurasjon.

Hovedårsaken er ikke riktige innstillinger server er administratorers frykt for å endre noe på en kjørende server og regelen "Det beste er det godes fiende." Hvis administratoren endrer serverinnstillingene og problemer begynner, vil alt myndighetenes sinne strømme ut over den uforsiktige administratoren. Derfor er det mer lønnsomt for ham å la alt være som det er, og ikke ta et eneste skritt uten ordre fra sine overordnede, enn å eksperimentere på eget ansvar.

Den andre grunnen er mangelen på tydelig informasjon om problemer med nettverksoptimalisering. Det er mange meninger som ofte helt motsier hverandre. Hver mening dedikert til optimalisering har sine motstandere og fanatikere som vil forsvare den. Som et resultat er det mer sannsynlig at Internett og fora forvirrer serverinnstillingene enn å hjelpe. I en situasjon med slik usikkerhet har administratoren enda mindre ønske om å endre noe på en server som på en eller annen måte fungerer.

Ved første øyekast er bildet klart - du må optimalisere alt som bremser driften av 1C-serveren. Men la oss forestille oss i stedet for en slik optimizer - la oss si at vi har 1C 8.1 8.2 8.3 UPP og 50 brukere jobber samtidig. En forferdelig dag begynner brukere å klage over at 1C er treg, og vi må løse dette problemet.

Først av alt ser vi på hva som skjer på serveren - hva om et spesielt uavhengig antivirus utfører en fullstendig skanning av systemet. En inspeksjon viser at alt er i orden - serveren lastes med 100%, og kun av sqlservr-prosessen.

Fra praksis: en av junioradministratorene slo på eget initiativ på automatisk oppdatering på serveren, Windows og SQL oppdaterte gladelig, og etter oppdateringen begynte en massiv nedgang i arbeidet til 1C-brukere, eller 1C frøs rett og slett.

Det neste trinnet er å sjekke hvilke programmer som laster MS SQL. Inspeksjon viser at belastningen genereres av ca. 20 applikasjonsservertilkoblinger.

Fra praksis: et program som raskt oppdaterer data på et nettsted gikk inn i en løkke, og i stedet for å oppdatere en gang hver 4. time, gjorde det det kontinuerlig, uten pauser, belastet serveren tungt og blokkerte dataene.

Videre analyse av situasjonen står overfor store vanskeligheter. Vi har allerede funnet ut at belastningen kommer direkte fra 1C, men hvordan kan vi forstå hva brukerne gjør? Eller i det minste hvem de er. Det er bra hvis det er 10 1C-brukere i en organisasjon, så kan du bare gå gjennom dem og finne ut hva de gjør nå, men i vårt tilfelle er det femti av dem, og de er spredt over flere bygninger.

I eksemplet vi vurderer er situasjonen ennå ikke kompleks. Tenk deg at nedgangen ikke var i dag, men i går. I dag gjentar ikke situasjonen seg, alt er bra, men du må finne ut hvorfor operatørene ikke kunne jobbe i går (de klaget naturligvis bare før de dro hjemmefra, siden de liker å chatte hele dagen lang fordi ingenting fungerer mer enn å jobbe ) . Denne saken understreker behovet for et serverloggingssystem som alltid vil holde en historikk over hovedparametrene for serverens drift og hvorfra hendelsesforløpet kan gjenopprettes.

Et loggsystem er rett og slett et uunnværlig verktøy i systemoptimalisering. Hvis du legger til muligheten til å se gjeldende status online, vil du få et overvåkingssystem for serverstatus. Hvert optimaliseringsprosjekt begynner med å samle inn serverstatusstatistikk for å identifisere flaskehalser.

Da vi begynte å jobbe innen optimalisering, prøvde vi mange serverovervåkingssystemer, dessverre klarte vi ikke å finne noe som løste dette problemet på riktig nivå, så vi måtte lage et system på egen hånd. Resultatet ble et unikt produkt, PerfExpert, som gjorde det mulig å automatisere og effektivisere prosessene med optimalisering av IT-systemer. Programmet utmerker seg ved tett integrasjon med 1C, fravær av merkbar tilleggsbelastning og gjentatte ganger bevist egnethet for praktisk bruk i kampsituasjoner.

For å gå tilbake til vårt eksempel, er det mest sannsynlige utfallet: Administratoren sier: "Det er programmererne som har skrevet konfigurasjonen som har skylden." Programmererne svarer: "Vi har alt skrevet godt - det er serveren som ikke fungerer bra." Og vogna, som de sier, er der fortsatt. Som et resultat bremser 1C farten, fryser eller virker sakte.

I alle fall, for å løse 1C ytelsesproblemer, anbefaler vi at du først kjøper og bruker ytelsesovervåking PerfExpert , vil dette tillate deg å ta den riktige avgjørelsen ledelsesbeslutning og spar penger. Produktet passer både for små 1C:Enterprise informasjonssystemer - opptil 50 brukere, og for systemer - fra 1000 brukere. Siden juli 2015 ytelsesovervåking PerfExpert mottatt et 1C:kompatibelt sertifikat, bestått testing i Microsoft og hjelper til med å løse ytelsesproblemer ikke bare for 1C-systemer, men også for andre informasjonssystemer basert på MS SQL Server (Axapta, CRM Dynamics, Doc Vision og andre).

Hvis du likte informasjonen, anbefales ytterligere handlinger:

- Hvis du selv ønsker å håndtere tekniske problemer med 1C-ytelse (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) og andre informasjonssystemer, så for deg er det en unik liste over tekniske artikler i vår almanakk (Blokkering og vreklås, stor belastning på CPU og disker, databasevedlikehold og indeksjustering er bare en liten del av det tekniske materialet du finner der).
.
- Hvis du ønsker å diskutere ytelsesproblemer med vår ekspert eller bestille en PerfExpert-løsning for ytelsesovervåking, så legg igjen en forespørsel, så kontakter vi deg så snart som mulig.

Vi mottar ofte spørsmål om hva som bremser 1c, spesielt når vi bytter til versjon 1c 8.3, takket være våre kolleger fra Interface LLC, forteller vi deg i detalj:

I våre tidligere publikasjoner 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 som gis "jern": "Regnskap 2.0 fløy bare, men "troikaen" beveget seg knapt," selvfølgelig, det er en viss sannhet i disse ordene, så la oss prøve å finne det ut.

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 WD Se, 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ører 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 databaser 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å vil være gjennom testing, som vi utførte med en lignende metode, nettverkstilkoblingen er 1 Gbit/s overalt, resultatet uttrykkes også 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 diskuterte påvirkningen av SSD på driftshastigheten til lokalt installert 1C i det forrige materialet, 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 akselerasjon i det daglige arbeidet, siden for eksempel lasting vil være begrenset gjennomstrømning nettverk.

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. 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 det 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 oppgavebehandlingen 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 reduksjon i produktiviteten.

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 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: Gjennomgang av to rimelige Western Digital Blue-seriestasjoner på 500 GB og 1 TB.

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.

Alle som jobber med produkter på 1C:Enterprise-plattformen har sannsynligvis hørt uttrykket "1C er treg." Noen klaget på det, andre tok imot klager. I denne artikkelen vil vi prøve å se på de vanligste årsakene til dette problemet og alternativer for å løse det.

La oss gå til en metafor: før du finner ut hvorfor en person ikke kom et sted, bør du sørge for at han har ben å gå. Så la oss starte med maskinvare- og nettverkskravene.

Hvis Windows 7 er installert:

Hvis du har Windows 8 eller 10 installert:

Husk det også ledig plass Disken må ha minst 2 GB, og nettverkstilkoblingen må ha en hastighet på minst 100 MB/sek.

Det gir ikke mye mening å vurdere egenskapene til servere i klient-serverversjonen, fordi i dette tilfellet avhenger alt av antall brukere og spesifikasjonene til oppgavene de løser i 1C.

Når du velger en serverkonfigurasjon, husk følgende:

Én 1C-serverarbeidsprosess bruker i gjennomsnitt 4 GB (må ikke forveksles med en brukertilkobling, siden én arbeidsprosess kan ha så mange tilkoblinger som du angir i serverinnstillingene);
Bruk av 1C og en DBMS (spesielt MS SQL) på én fysisk server gir fordeler ved behandling av store datamengder (for eksempel lukking av en måned, beregning av budsjett basert på en modell, etc.), men reduserer ytelsen betydelig under ubelastede operasjoner ( for eksempel opprette og gjennomføre implementeringsdokument, etc.);
Husk at 1C-servere og DBMS må kobles over en kanal "tykk" på 1 GB;
Bruk høyytelsesdisker og ikke kombiner 1C- og DBMS-serverrollene med andre roller (for eksempel fil, AD, domenekontroller osv.).

Hvis etter kontroll av utstyret 1C fortsatt bremser ned

Vi har et lite selskap, 7 personer, og 1C er treg. Vi kontaktet spesialister, og de sa at bare klient-server-alternativet ville redde oss. Men for oss er en slik løsning ikke akseptabel, den er for dyr!

Utfør rutinemessig vedlikehold i databasen*:

1. Start databasen i konfiguratormodus.

2. Velg "Administrasjon" i hovedmenyen, og i den - "Testing og korrigering".

3. Kryss av i alle boksene som på bildet. Klikk Kjør.

*Denne prosedyren kan ta fra 15 minutter til en time, avhengig av størrelsen på databasen og egenskapene til PC-en din.

Hvis dette ikke hjelper, oppretter vi en klient-server-tilkobling, men uten ytterligere investeringer i maskinvare og programvare:

1. Velg den minst belastede stasjonære datamaskinen på kontoret (ikke en bærbar PC): den må ha minst 4 GB RAM og en nettverkstilkobling på minst 100 MB/sek.

2. Aktiver IIS (Internet Information Server) på den. For dette:

3. Publiser databasen din på denne datamaskinen. Det er tilgjengelig materiale om dette emnet på ITS, eller kontakt en støttespesialist.

4. På brukerdatamaskiner, konfigurer tilgang til databasen gjennom en tynn klient. For dette:

Åpne 1C-startvinduet.

Velg arbeidsbasen din. Her er det "Din base". Klikk "Rediger". Sett bryteren til "På en webserver", angi i linjen under navnet eller IP-adressen til serveren som IIS ble aktivert på, og navnet som databasen ble publisert under. Klikk "Neste".

Sett bryteren "Grunnleggende oppstartsmodus" til "Tynn klient"-modus. Klikk "Ferdig".

Vi har et ganske stort selskap, men ikke et veldig stort, omtrent 50–60 personer. Vi bruker et klient-server-alternativ, men 1C er fryktelig treg.

I dette tilfellet anbefales det å dele 1C-serveren og DBMS-serveren i to forskjellige servere. Når du skiller, husk å huske: hvis de forble på den samme fysiske serveren, som ganske enkelt ble virtualisert, må diskene til disse serverne være forskjellige - fysisk forskjellige! Pass også på å sette opp rutineoppgaver på DBMS-serveren når det gjelder MS SQL (mer detaljer om dette er beskrevet på ITS-nettstedet)

Vi har et ganske stort selskap, mer enn 100 brukere. Alt er konfigurert i samsvar med 1C-anbefalingene for dette alternativet, men når du behandler noen dokumenter, er 1C veldig treg, og noen ganger oppstår det en blokkeringsfeil. Kanskje gjøre en base rollup?

En lignende situasjon oppstår på grunn av størrelsen på et veldig spesifikt akkumulerings- eller regnskapsregister (men oftere - akkumulering), på grunn av det faktum at registeret enten "lukker" helt, dvs. det er innkommende bevegelser, men ingen strømningsbevegelser, eller antallet målinger som registerbalansene beregnes etter er svært stort. Det kan til og med være en blanding av de to foregående årsakene. Hvordan finne ut hvilket register som ødelegger alt?

Vi registrerer tiden når dokumenter behandles sakte, eller tiden og brukeren som har en blokkeringsfeil.

Åpne registreringsloggen.

Vi finner dokumentet vi trenger, til rett tid, for rett bruker med hendelsestypen “Data.Post”.

Vi ser på hele utførelsesblokken til transaksjonen kanselleres hvis det var en blokkeringsfeil, eller vi ser etter den lengste endringen (tiden fra forrige post er mer enn ett minutt).

Etter dette tar vi en avgjørelse, med tanke på at det å kollapse akkurat dette registeret uansett er billigere enn hele databasen.

Vi er et veldig stort selskap, mer enn 1000 brukere, tusenvis av dokumenter per dag, vår egen IT-avdeling, en enorm serverflåte, vi har optimert spørringer flere ganger, men 1C er treg. Vi har tilsynelatende vokst ut av 1C, og vi trenger noe kraftigere.

I de aller fleste slike tilfeller er det ikke 1C som bremser, men arkitekturen til løsningen som brukes. Å ta et valg til fordel nytt program for bedrifter, husk at det er billigere og enklere å skrive forretningsprosesser i et program enn å konvertere dem til noen, spesielt et veldig kostbart program. Bare 1C gir denne muligheten. Derfor er det bedre å stille spørsmålet: "Hvordan rette opp situasjonen? Hvordan kan du få 1C til å «fly» med slike volumer?» La oss kort se på flere behandlingsalternativer:

Bruk parallelle og asynkrone programmeringsteknologier støttet av 1C ( bakgrunnsjobber og spørringer i en loop).
Ved utforming av løsningsarkitekturen, unngå å bruke akkumuleringsregistre og regnskapsregistre i de mest flaskehalsede områdene.
Når du utvikler en datastruktur (akkumulerings- og/eller informasjonsregistre), må du følge regelen: "Den raskeste tabellen for skriving og lesing er en tabell med én kolonne." Om hva vi snakker om, vil det bli tydeligere hvis du ser på den typiske RAUZ-mekanismen.
For å behandle store datamengder, bruk hjelpeklynger der samme database er koblet til (men ikke i noe tilfelle skal dette gjøres under interaktivt arbeid!!!). Dette vil tillate deg å omgå standard 1C-låser, som gjør det mulig å jobbe med databasen med nesten samme hastighet som når du jobber direkte med SQL-verktøy.

Det er verdt å merke seg at 1C-optimalisering for beholdninger og store selskaper er et tema for en egen flott artikkel, så følg med for oppdatert materiale på nettsiden vår.

2. Funksjoner i programmet. Ofte, selv med optimale innstillinger, fungerer 1C veldig sakte. Ytelsen synker spesielt kraftig når antallet samtidige arbeider med databasen overstiger 4-5 brukere.

Hvem er du i selskapet?

Løsning sakte arbeid 1C avhenger av hvem du er i selskapet. Hvis du er en tekniker, bare les videre. Hvis du er direktør eller regnskapsfører, følg den spesielle lenken ↓

Nettverksbåndbredde

Som regel arbeider ikke én, men flere brukere med én informasjonsbase (IS). Samtidig foregår det en konstant utveksling av data mellom datamaskinen som 1C-klienten er installert på og datamaskinen som informasjonssikkerheten er plassert på. Volumet av disse dataene er ganske betydelig. En situasjon oppstår ofte når et lokalt nettverk som opererer med en hastighet på 100 Mbit/s, som er den vanligste hastigheten, rett og slett ikke kan takle belastningen. Og igjen klager brukeren over at programmet er tregt.

Hver av disse faktorene individuelt reduserer allerede hastigheten på programmet betydelig, men det mest ubehagelige er at disse tingene vanligvis går opp.

La oss nå se på flere løsninger på problemet med lav 1C-driftshastighet og kostnadene deres, ved å bruke eksemplet lokalt nettverk av 10 gjennomsnittlige datamaskiner.

Løsning én. Modernisering av infrastruktur

Dette er kanskje den mest åpenbare løsningen. La oss beregne minimumskostnaden.

For hver datamaskin trenger vi i det minste en 2 GB RAM-pinne, som i gjennomsnitt koster 1500 rubler, LAN-kort med støtte for hastighet 1 Gbit/s, koster omtrent 700 rubler. I tillegg trenger du minst 1 ruter som støtter en hastighet på 1 Gbit/s, som vil koste omtrent 4000 rubler. Totale kostnader - 26 000 rubler for utstyr, unntatt arbeid.

I prinsippet kan hastigheten øke betydelig, men nå er det ikke lenger mulig å kjøpe rimelige datamaskiner til kontoret. I tillegg, denne avgjørelsen ikke aktuelt for de som bruker Wi-Fi eller ønsker å jobbe via Internett - i deres tilfelle kan nettverkshastigheten være titalls ganger lavere. Tanken oppstår: "Er det ikke mulig å implementere hele programmet på en kraftig server, slik at brukerens datamaskin ikke deltar i komplekse beregninger, men bare tjener til å overføre bildet?" Da kan du jobbe selv på svært svake datamaskiner, selv på nettverk med lav båndbredde. Naturligvis finnes slike løsninger.

Løsning to. Terminal Server

Fikk stor popularitet tilbake i 1C 7-dagene. Implementert på serveren Windows-versjoner og takler oppgaven vår perfekt. Det har imidlertid sine fallgruver, nemlig kostnadene for lisenser.

Hun selv operativsystem vil koste rundt 40 000 rubler. I tillegg til dette trenger vi for alle som planlegger å jobbe i 1C en Windows Server CAL-lisens, som koster rundt 1700 rubler, og en Windows Remote Desktop Services CAL-lisens, som koster omtrent 5900 rubler.

Etter å ha beregnet kostnadene for et nettverk på 10 datamaskiner, ender vi opp med 116 000 rubler. kun for én lisens. Legg til dette kostnadene for selve serveren (minst 40 000 rubler) og kostnadene for implementeringsarbeid, men selv uten dette viste prisen for lisenser seg å være imponerende.

Løsning tre. Service 1C Enterprise

1C har utviklet sin egen løsning på dette problemet, som kan øke hastigheten på programmet betydelig. Men det er en nyanse her også.

Faktum er at kostnadene for en slik løsning varierer fra 50 000 til 80 000 rubler, avhengig av utgaven. For et selskap med opptil 15 brukere viser det seg å være ganske dyrt. Store forhåpninger ble satt til "1C enterprise mini-server", som ifølge 1C-selskapet er rettet mot små bedrifter og koster rundt 10 000 - 15 000 rubler.

Men da det ble solgt, var dette produktet en stor skuffelse. Faktum er det maksimalt beløp Det var bare 5 brukere som miniserveren kunne brukes med.

Som en 1C-programmerer skrev på forumet: "Det er fortsatt ikke klart hvorfor 1C valgte nøyaktig 5 tilkoblinger! Problemene begynner bare med 4 brukere, men med fem slutter det hele. Hvis du vil koble til en sjette person, betal ytterligere 50 tusen. Vi kan gjøre minst 10 tilkoblinger..."

Selvsagt fant miniserveren også sin forbruker. For bedrifter der 5 eller flere personer jobber med 1C har det imidlertid ikke dukket opp en enkel og rimelig løsning.

I tillegg til programakselerasjonsmetodene beskrevet ovenfor, er det en annen som er ideell for segmentet 5 - 15 brukere, nemlig nettilgang for 1C i filmodus.

Løsning fire. Nettilgang for 1C i filmodus

Driftsprinsippet er som følger: en ekstra rolle til en webserver er installert på datamaskinen, som informasjonssikkerhet publiseres på.

Naturligvis må dette være enten det meste kraftig datamaskin på nettverket, eller en egen maskin dedikert til denne rollen. Etter det kan du jobbe med 1C i webservermodus. Alle tunge operasjoner vil bli utført på serversiden, og trafikk som overføres over nettverket vil bli minimert, det samme vil belastningen på klientens datamaskin.

Dermed kan selv svært svake maskiner brukes til å jobbe i 1C, og nettverksbåndbredden blir ikke kritisk. Våre tester har vist at du kan jobbe komfortabelt gjennom Mobilt Internett på et billig nettbrett uten å oppleve noe ubehag.

Dette alternativet er dårligere enn enterprise 1C-serveren når det gjelder driftshastighet, men denne forskjellen er praktisk talt usynlig for opptil 15-20 brukere. For å implementere en webserver kan du forresten bruke IIS (for Windows) og Apache (for Linux), og begge disse løsningene er gratis!

Til tross for de åpenbare fordelene, denne metoden optimering av 1C-drift har ikke fått mye popularitet.

Jeg kan ikke si det sikkert, men mest sannsynlig skyldes dette to grunner:

En ganske svak beskrivelse teknisk dokumentasjon
Ligger i skjæringspunktet mellom ansvar mellom systemadministrator og 1C-programmerer

Vanligvis, når en systemadministrator blir kontaktet med et problem med lav hastighet, foreslår han å oppgradere infrastrukturen eller en terminalserver hvis en 1C-spesialist blir kontaktet, blir han tilbudt en 1C-bedriftsserver. Så hvis en spesialist med ansvar for infrastruktur og en spesialist ansvarlig for 1C jobber "hånd i hånd" i din bedrift, kan du trygt bruke en løsning basert på en webserver.

La oss øke hastigheten på 1C. Fjernt, raskt og uten din deltakelse

Vi vet hvordan vi skal få fart på 1Ski uten å forstyrre kunden. Vi fordyper oss i problemet, gjør jobben vår og drar. Hvis du vil at programmet bare skal fungere normalt, kontakt oss. Vi finner ut av det.

Legg igjen en forespørsel og motta en gratis konsultasjon om å akselerere programmet.

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 berørt virkningen av diskundersystemytelse 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 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 ressurser på 1C viste at dette problemet er flittig unngått 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 en viss sannhet i disse ordene, så la oss prøve å finne ut av det.

Ressursforbruk, første øyekast

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

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:

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.

Nett

Hva skjer når du starter en 1C-fildatabase over nettverket? Klienten laster ned en ganske stor mengde informasjon til midlertidige mapper, 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).

Vi sjekket også påvirkningen av nettverkshastighet på drift i tunge moduser, for eksempel under gruppeoverføringer. Resultatet er også uttrykt i relative verdier:

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

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

Serverdiskundersystem og SSD

La oss starte med lastehastigheten til databasen.

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

I hverdagsoppgaver er bildet likt:

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 akselerasjon i hverdagen, siden for eksempel nedlasting vil være begrenset av nettverksbåndbredde.

En treg harddisk kan bremse enkelte operasjoner, men kan i seg selv ikke føre til at et program bremser ned.

RAM

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, cache, swap, etc., essensen av denne operasjonen er at data som ikke er nødvendig for øyeblikket sendes fra rask RAM, hvor mye 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 det er ubetydelig under behandlingen, men er ikke en begrensende faktor.

La oss nå redusere minnet til 1 GB:

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 oppgavebehandlingen kjørte. I det virkelige liv, på en arbeidsdatamaskin, er som regel en nettleser, en kontorpakke åpne, et antivirus kjører, etc., etc., så fortsett fra behovet for 500 MB per database, pluss litt reserve, slik at under tunge operasjoner møter du ikke mangel på hukommelse og kraftig nedgang i produktivitet.

prosessor

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

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 av harddisker kan vurderes 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: gruppebehandling, tunge rapporter, månedsavslutning osv.

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.