1s starter ikke, splash-skjermen henger. Hvordan lukke et program som er frosset

Hvordan lukke et program hvis det fryser og slutter å svare. Hvorfor fryser programmer? Hvem har skylden og hva skal man gjøre? I denne artikkelen vil vi prøve å analysere hovedårsakene og løsningene på dette problemet.

Et åpent program har sluttet å svare på handlingene dine, markøren har frosset eller blitt til et timeglass, selve programvinduet viser meldingen "Reagerer ikke", klikker du på alt, er du nervøs og vet ikke hva du skal gjøre?

Først av alt, roe deg ned og les ferdig artikkelen. Absolutt alle har befunnet seg i denne situasjonen alle programmer er skrevet av mennesker, så de er ikke ideelle. Det viktigste vi må forstå er hvordan vi skal opptre riktig i slike tilfeller og hvorfor dette skjer.

Først må du finne ut om programmet virkelig er frosset og alle symptomene beskrevet ovenfor er observert, eller om du bare har startet et ressurskrevende program eller program som systemet ditt ikke fryser fra, men bare bremser ned.

Hva du ikke skal gjøre hvis programmet fryser

La oss se på de vanligste feilene som mange nybegynnere gjør, og dermed kaste bort tiden.

— Å skrike, slå på tastaturet (det er definitivt ikke hennes feil).
– Det er ikke nødvendig å prøve å kjøre det samme programmet på nytt, eller spesielt andre programmer – dette vil bare forverre situasjonen.
— Trekk ut strømmen, slå den av, start på nytt (dette er en siste utvei-metode).

Hva gjør jeg hvis programmet fryser

1. Før du går videre til mer radikale metoder, prøv å lukke den på oppgavelinjen ved å høyreklikke på det frosne programmet og velge riktig element.
2. Hvis det ikke hjelper, gå til den velprøvde metoden for dette må vi starte oppgavebehandlingen. Du kan ringe oppgavebehandlingen ved å bruke tastekombinasjonen Ctrl + Shift + Esc (Windows 7) Ctrl + Alt + Del (Windows XP).

Vi er interessert i "applikasjoner"-fanen alle applikasjoner som kjører på datamaskinen vises her. Vi ser etter programmet som er frosset (i mitt eksempel er det et program) og klikker → Avslutt oppgave. Som regel er dette nok!! Hjalp ikke → punkt 3.
3. Hva skal jeg gjøre hvis programmet fortsetter å fryse? Gå til neste fane → "Prosesser". Faktum er at ethvert program du kjører på datamaskinen din har noen prosess eller prosesser knyttet til seg. Og programmet som for øyeblikket er frosset har også sin egen prosess, som du kan finne ut ved å høyreklikke på programsnarveien og velge → “Egenskaper”. I mitt eksempel er dette prosessen → VideoConverter.exe

Velg prosesser-fanen → se etter prosessen din (i mitt tilfelle er det "VideoConverter.exe") og klikk → "avslutt prosess" eller, bare for å være sikker, → høyreklikk på prosessen → "Avslutt prosesstre"

Slik kan du, ved å bruke standard Windows-verktøy, løse problemet med et frossent program. Du kan også lukke et fryst program ved å bruke tredjepartsprogrammer, for eksempel programmet

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. En 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 "nesten" 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, så lukket alt normalt, den samme databasen ble lastet inn på PostgreSQL-serveren ved beregning av kostnaden, feil oppstod. På den tiden lå vi et halvt år bak 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 det siste har brukere og administratorer i økende grad begynt å klage over at nye 1C-konfigurasjoner utviklet på grunnlag av en administrert applikasjon fungerer sakte, 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 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

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 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.

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øke problemer, men lav ytelse er også et problem, og restrukturering og reindeksering, sammen med tabellkomprimering, er velkjente verktøy for å optimalisere databaser. 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 nettverk av små bedrifter 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 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 rundt 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 tar den største verdien av hver måling som 100 %:

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 Ytelsesmå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 testene som er utført, blir det klart at nettverket ikke er en flaskehals for de nye konfigurasjonene, 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å 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 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.

VÆR

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? Dumpet inn i 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 tregt diskminne.

Hva vil dette føre til? 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. Å åpne journalen Salg av varer og tjenester tok for eksempel omtrent 20 sekunder 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, 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.

CPU

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 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.

• Tagger:

Vennligst aktiver JavaScript for å se

Brukerklagen «1C henger», som er godt kjent for IT-spesialister, har mange årsaker. For å gjøre en riktig "diagnose" - identifisere og analysere et problem, er det nødvendig å reprodusere det, 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 å bruke et stort antall metadataobjekter (mange anrop til ulike vanlige moduler, behandling, etc.).

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 ikke dette den beste løsningen. 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å å behandle det åpnede 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 ved oppdatering via Internett og indikerer mest sannsynlig at konfigurasjonen ikke har blitt oppdatert på lenge og utgivelser, 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 oftest fryser under oppdateringer også fordi den krever mer ressurskrevende maskinvare enn tidligere versjoner av plattformen. 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 loggdataene. 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 tiltrekke deg en spesialist med kompetansen "1C: Ekspert på teknologiske spørsmål", siden det ikke er noen enhetlige regler for å løse et slikt problem.