Opp 8.3 begynte å virke sakte. Automatiseringstips. Bruke SQL Server DMO-objekter

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 til et tregt program - . Denne instruksen vil være aktuelt 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 planlagte oppgaver som startes:

Blant disse oppgavene kan du se som "", lasting av 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.

Deaktivere rutine- og bakgrunnsoppgaver i 1C 8.3

Pasientsymptomer og historie:

Arbeidet til flere brukere over nettverket med samme fil (database) inkluderer en nettverksblokkeringsmekanisme. Dette tvinger systemet til å kaste bort verdifull tid på å identifisere åpne opptaksøkter og løse konflikter deretter.

De viktigste tegnene på blokkering:

• raskt brukerarbeid med databasen over nettverket i eksklusiv modus og ekstremt sakte når flere brukere jobber samtidig
• rask brukeropplevelse med en lokal database på serveren og sakte arbeid over nettverket
• appellerer til filsystem i underkant av 10 MB/sek

Så jeg fikk i oppgave å sørge for at så mange som tre brukere kunne jobbe i 1C samtidig! Morsomt, ikke sant?

Jeg glemte alle vitsene da jeg så hva jeg måtte forholde meg til: en "server" i form av en vanlig kontordatamaskin og to bærbare datamaskiner.

Lykken ville ikke vært komplett hvis det ikke var for de fantastiske operativsystemene - på datamaskinen og på en Windows bærbar PC 7, på den andre - Windows 8.

Når du prøvde å legge ut dokumenter på bærbare datamaskiner samtidig, satt den ene fast i omtrent et minutt, og den andre krasjet ut av 1C med feilteksten "kunne ikke låse bordet ...".

Å lansere 1C på en bærbar PC er et eget show som varte ca 3 minutter!

På mange ressurser kom jeg over råd om å bytte til å jobbe med terminaltilgang. Dessverre tillater ikke Windows 7 vanlige midler gjøre om til en terminalserver - maksimalt én aktiv tilkobling. I dette tilfellet avsluttes ikke de gjenværende øktene du kan koble til igjen under en annen bruker - "kaste ut" den forrige brukeren, men uten å avslutte økten hans. Derfor bør du overføre 1C til et server-OS, der det ikke er slike begrensninger. Klienten, på egen risiko, løste problemet ved å bruke et tredjepartsverktøy i stedet Windows7_SP1_RDPhack.

Men eventyrene sluttet ikke der. Selv i terminalforbindelsen var det betydelige forsinkelser. Nok en gang hjalp de allmektige søkemotorene meg. Nedenfor er tips for å øke hastigheten på fil 1C, som jeg fulgte:

1. Deaktiver bruk av nettverksprotokoll IPv6, konfigurer adressering på den "gamle" IPv4.

2. Legg til 1C-prosesser til Windows-brannmurunntak, så vel som antivirusunntak, eller deaktiver dem helt (mer risikabelt, men en enkel test viste hastighetsøkning legge ut dokumenter på nytt når de er deaktivert Avast antivirus faktor av!)

3. Begynn å indeksere fulltekstsøk i 1C eller slå det av helt

4. Kjør Testing og fiksing av databasen, sjekk med ChDbfl-verktøyet

5. Kjør elementet Sjekk konfigurasjon i konfigurasjonen (hvis konfigurasjonen ikke er standard, kan dette være nyttig). Basert på resultatene av å sjekke konfigurasjonen, ble den magisk redusert i størrelse med nesten en tredjedel. Jeg fordypet meg egentlig ikke i nøyaktig hva de innkommende programmererne oppdaterte før meg, men faktum er åpenbart.

6. Deaktiver unødvendige funksjonelle alternativer.

7. Sett opp brukerrettigheter. (Dette og det forrige rådet virket dumt før jeg så på gjengivelsen administrerte skjemaer når du åpner listen over dokumenter. Jo mindre unødvendige ting i et administrert grensesnitt, jo raskere fungerer det som regel)

8. Begynn å beregne totalene på nytt og gjenopprette sekvensen (en betydelig økning kan bare skje hvis totalene ikke har blitt gjenopprettet på lang tid)

9. Spesifiser "Tilkoblingshastighet - lav" i databaselisteinnstillingene (dette ga ikke mye resultat, bortsett fra at bildene av undersystemene ble slått av :))

Etter å ha fullført alle disse trinnene, begynte 1C-fildatabasen å fungere mye raskere. Den begynte å starte på maksimalt 10 sekunder, og hastigheten på dokumentoverføringen økte i gjennomsnitt 12 ganger.

Kanskje denne korte artikkelen vil være nyttig for deg hvis du plutselig trenger å øke hastigheten på 1C-fildatabasen din.

P.S: Men å starte en fil 1C ved å bruke nettverkstilgang til en delt mappe er fortsatt urealistisk, fordi... Selv den raskeste solid-state-stasjonen, RAM og prosessor vil støte på nettverksblokkeringer, og arbeidet til mer enn én bruker vil være praktisk talt umulig. Det handler om spesifikt om konfigurasjonen av UT 11.1. Selvskrevne små konfigurasjoner kan fungere ganske raskt selv i filversjonen.

Tilføyelser fra kommentarer for publisering:

Diskdefragmentering med filbase

Konvolusjon database (kan være nyttig hvis databasen er stor, for eksempel i flere år). Klientens database var ganske ung, så reduksjon var upraktisk.

Maskinvareoppgradering - raskere harddisk, ny bryter, prosessor, etc.

Installer på webserver, tilgang ved hjelp av en tynn klient. Her er meningene delte. Noen sier det er mange ganger raskere, andre sier at det ikke er registrert noen akselerasjon.

Hovedformålet med å skrive denne artikkelen er å unngå å gjenta åpenbare nyanser for de administratorer (og programmerere) som ennå ikke har fått erfaring med 1C.

Det sekundære målet er at hvis jeg har noen mangler, vil Infostart være den raskeste til å påpeke dette for meg.

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

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

Opprinnelige data:

Testet datamaskin, hovedforsøkskanin: HP DL180G6, utstyrt med 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Til sammenligning viser Core i3-2100 sammenlignbare resultater i den entrådede testen. Utstyret jeg spesifikt tok var ikke det nyeste, men moderne utstyr resultatene er merkbart bedre.

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

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

Filversjon. (databasen er på serveren i en delt mappe, klienter kobles til via nettverket, CIFS/SMB-protokoll). Algoritme trinn for trinn:

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

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

Hvis du har en datamaskin verre enn en Pentium 775 stikkontakt med 1 GB tilfeldig tilgang minne, da føler jeg med deg, og det vil være vanskelig for deg å oppnå komfortabelt arbeid på 1C 8.2 i filversjonen. Tenk på enten å oppgradere (det er på høy tid) eller bytte til en terminal (eller web, i tilfelle av tynne klienter og administrerte skjemaer) server.

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

Hvis Gilevs test på dette stadiet viste 30 "papegøyer" eller høyere, men 1C-arbeidsbasen fortsatt fungerer sakte, bør spørsmålene rettes til programmereren.

1. Som en guide til hvor mye en klientdatamaskin kan "klemme", kontrollerer vi driften av kun denne datamaskinen, uten nettverk. Vi legger testgrunnlaget på lokal datamaskin(veldig rask disk). Hvis klientdatamaskinen ikke har en vanlig SSD, opprettes en ramdisk. Foreløpig er den enkleste og gratis Ramdisk enterprise.

For å teste versjon 8.2 er en 256 MB ramdisk nok, og! Det viktigste. Etter omstart av datamaskinen, med ramdisken kjørende, skal det være 100-200 MB ledig på den. Følgelig, uten en ramdisk, for normal operasjon Ledig minne bør være 300-400 MB.

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

Når du tester, må du se på prosessorbelastningen. I et tilfelle nær ideell (ramdisk), laster lokal fil 1c 1 prosessorkjerne når den kjøres. Følgelig, hvis prosessorkjernen ikke er fullastet under testing, se etter svake punkter. Litt emosjonell, men generelt korrekt, er påvirkningen fra prosessoren på driften av 1C beskrevet. Bare for referanse, selv på moderne Core i3s med høye frekvenser, er tallene 70-80 ganske realistiske.

De vanligste feilene på dette stadiet.

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

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

Kort sagt, mens 1C kjører, er det mye venting på svar fra andre enheter (disk, nettverk, etc.). Mens du venter på svar, hvis ytelsesmodusen er aktivert, senker prosessoren frekvensen. En respons kommer fra enheten, 1C (prosessoren) må fungere, men de første klokkesyklusene er på redusert frekvens, deretter øker frekvensen – og 1C venter igjen på svar fra enheten. Og så – mange hundre ganger per sekund.

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

Via BIOS. Deaktiver modusene C1, C1E, Intel C-state (C2, C3, C4). I forskjellige bios kalles de forskjellig, men betydningen er den samme. Det tar lang tid å søke, en omstart er nødvendig, men hvis du gjør det en gang, kan du glemme det. Hvis du gjør alt riktig i BIOS, vil hastigheten øke. På noen hovedkort kan du konfigurere BIOS-innstillingene slik at Windows ytelsesmodus ikke spiller noen rolle. (Eksempler BIOS-innstillinger på Gilev). Disse innstillingene gjelder hovedsakelig serverprosessorer eller "avanserte" BIOSer, hvis du ikke har funnet dette og du IKKE har Xeon, er det greit.

Kontrollpanel - Strømforsyning - Høy ytelse. Minus - hvis datamaskinen ikke har fått service på lenge, vil den lage en høyere viftelyd, varme opp mer og forbruke mer energi. Dette er et resultathonorar.

Hvordan sjekke at modusen er aktivert. Start oppgavebehandling - ytelse - ressursovervåking - CPU. Vi venter til prosessoren er opptatt med ingenting.

Dette er standardinnstillingene. I BIOS C-tilstand inkludert, balansert strømforbruksmodus
I BIOS C-tilstand inkludert, høyytelsesmodus For Pentium og Core kan du stoppe der, Du kan fortsatt presse litt "papegøyer" ut av Xeon
I BIOS C-tilstand slått av, høyytelsesmodus. Hvis du ikke bruker Turbo boost, er det slik det skal se ut server innstilt for ytelse

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

Kjære administratorer, du kan kritisere 1C så mye du vil, men hvis sluttbrukere trenger hastighet, må du aktivere høyytelsesmodus.

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

Hvordan slå på turboboost skrives for eksempel . Men! For 1C er det noen nyanser (ikke de mest åpenbare). Vanskeligheten er at den maksimale effekten av turboboost oppstår når C-tilstand er slått på. Og vi får noe sånt som dette:

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

	Faktor	Kjernehastighet (frekvens), GHz	CPU-Z Enkeltråd	Gilev Ramdisk test filversjon	Gilev Ramdisk test klient server
Uten Turbo boost
C-tilstand av, Turbo boost				53.19	40,32
C-state på, Turbo boost			1080	53,13	23,04

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

Konklusjon - turbo boost må slås på. La meg minne deg på at det ikke er nok å aktivere Turbo boost-elementet i BIOS, du må også se på andre innstillinger (BIOS: QPI L0s, L1 - deaktiver, kreve skrubbing - deaktiver, Intel SpeedStep - aktiver, Turbo boost - aktiver Kontrollpanel - Strømalternativer - Høy ytelse). Og jeg ville fortsatt (selv for filversjonen) valgt alternativet der c-state er slått av, selv om multiplikatoren er mindre. Det vil vise seg noe slikt...

Et ganske kontroversielt poeng er minnefrekvensen. For eksempel er minnefrekvens vist å ha en veldig sterk innflytelse. Testene mine avslørte ikke en slik avhengighet. Jeg vil ikke sammenligne DDR 2/3/4, jeg vil vise resultatene av å endre frekvensen innenfor samme linje. Minnet er det samme, men i BIOS er vi tvunget til å sette lavere frekvenser.

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

Forskjellen ligger innenfor målefeilen. Jeg tok spesifikt ut skjermbilder av CPU-Z for å vise at med en endring i frekvens, endres også andre parametere, samme CAS Latency og RAS til CAS Delay, som nøytraliserer endringen i frekvens. Forskjellen vil være når minnemodulene endres fysisk, fra tregere til raskere, men selv der er ikke tallene spesielt betydelige.

2. Når vi har sortert ut prosessoren og minnet til klientdatamaskinen, går vi videre til neste svært viktige sted – nettverket. Det er skrevet mange bind med bøker om nettverksinnstilling, det er artikler om Infostart ( og andre), men her skal jeg ikke fokusere på dette emnet. Før du begynner å teste 1C, sørg for at iperf mellom to datamaskiner viser hele båndbredden (for 1 Gbit-kort - vel, minst 850 Mbit, eller enda bedre 950-980), at Gilevs råd er blitt fulgt. Deretter - den enkleste operasjonstesten vil merkelig nok være å kopiere én stor fil (5-10 gigabyte) over nettverket. Et indirekte tegn på normal drift på et 1 Gbit-nettverk vil være gjennomsnittlig kopieringshastighet på 100 MB/sek, god drift - 120 MB/sek. Jeg vil gjerne trekke oppmerksomheten din til det faktum at det svake punktet (inkludert) kan være prosessorbelastningen. SMB Protokollen på Linux er ganske dårlig parallellisert, og under drift kan den ganske enkelt "spise opp" en prosessorkjerne og ikke forbruke mer.

Og videre. Med standard Windows-innstillinger fungerer klienten best med en Windows-server (eller til og med vinduene fungerer station) og SMB/CIFS-protokollen, fungerer linux-klienten (debian, ubuntu så ikke på de andre) bedre med linux og NFS (den fungerer også med SMB, men papegøyene er høyere på NFS). Det faktum at under lineær kopiering kopieres en Windows Linux-server til NFS til én strøm raskere, betyr ikke noe. Debian tuning for 1C er et emne for en egen artikkel, jeg er ikke klar for det ennå, selv om jeg kan si at i filversjonen fikk jeg enda litt bedre ytelse enn Win-versjonen på samme utstyr, men med postgres med over 50 brukere Jeg har fortsatt alt veldig dårlig.

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

I kommandolinje(eller i retningslinjer, eller som du foretrekker) - bruk nett DriveLetter: \\server\share. Eksempel: nettbruk m:\\server\baser. Jeg understreker spesifikt IKKE IP-adressen, nemlig Navn server. Hvis servernavnet ikke er synlig, legg det til i dns på serveren, eller lokalt i vertsfilen. Men adressen må være ved navn. Følgelig, på vei til databasen, få tilgang til denne disken (se bilde).

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

	Vinn 2008 - Vinn 2008 kontakt på ip-adresse	Vinn 2008 - Vinn 2008 Ringer ved navn	Vinn 2008 - Vinn 2008 Kontakt via IP-adresse	Vinn 2008 - Vinn 2008 Ringer ved navn	Vinn 2008 - Vinn 7 Ringer ved navn	Vinn 2008 - Debian Ringer ved navn	Vinn 2008 - Vinn 2008 Kontakt via IP-adresse	Vinn 2008 - Vinn 2008 Ringer ved navn
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
IC 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
IC 8,3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

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

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

1C 8.3-plattformen er mange ganger mer krevende når det gjelder riktig nettverkskonfigurasjon. Grunninnstillinger - se Gilev, men husk at alt kan påvirkes. Jeg så en akselerasjon fra å avinstallere (og ikke bare slå av) antiviruset, fra å fjerne protokoller som FCoE, fra å endre drivere til en eldre, men Microsoft-sertifisert versjon (spesielt for billige kort som ASUS og DLC), fra å fjerne det andre nettverkskortet fra serveren. Det er mange alternativer, sett opp nettverket ditt nøye. Det kan godt være en situasjon der plattform 8.2 gir akseptable tall, og 8.3 - to eller enda flere ganger mindre. Prøv å spille med plattformversjoner 8.3, noen ganger får du en veldig stor effekt.

1C 8.3.6.2076 (kanskje senere, jeg har ikke sett etter den eksakte versjonen ennå) er fortsatt enklere å konfigurere over nettverket enn 8.3.7.2008. Jeg var i stand til å oppnå normal drift over nettverket fra 8.3.7.2008 (i sammenlignbare papegøyer) bare noen få ganger, jeg kunne ikke gjenta det for et mer generelt tilfelle. Jeg skjønte ikke så mye, men å dømme etter foot wraps fra Process Explorer, er ikke opptaket der så bra som i 8.3.6.

Til tross for at når du jobber på et 100 Mbit-nettverk, er belastningsgrafen liten (vi kan si at nettverket er gratis), er driftshastigheten fortsatt mye mindre enn på 1 Gbit. Årsaken er nettverksforsinkelse.

Alt annet likt (et velfungerende nettverk) for 1C 8.2 er Intel-Realtek-tilkoblingen 10 % tregere enn Intel-Intel. Men realtek-realtek kan generelt gi skarpe innsynkninger ut av det blå. Derfor, hvis du har penger, er det bedre å beholde Intel-nettverkskort overalt; hvis du ikke har penger, installer Intel kun på serveren (din CO). Og det er mange ganger flere instruksjoner for tuning av Intel-nettverkskort.

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

IKKE les Linux-guruer. En server med samba er flott og gratis, men hvis du installerer Win XP eller Win7 (eller enda bedre - server OS) på serveren, vil filversjonen av 1c fungere raskere. Ja, samba og protokollstabelen og nettverksinnstillinger og mye, mye mer kan justeres godt i debian/ubuntu, men dette anbefales for spesialister. Det er ingen vits i å installere Linux med standardinnstillinger og så si at det er tregt.

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

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

Jeg forstår ikke hvorfor, med et 100 Mbit-nettverk, 8.3 fungerer merkbart raskere enn 8.2, men det var et faktum. Alt annet utstyr, alle andre innstillinger er helt de samme, det er bare at i ett tilfelle blir 8.2 testet, og i det andre - 8.3.

Ikke-tunet NFS vinn-vinn eller vinn-lin gir 6 papegøyer, jeg tok dem ikke med i tabellen. Etter tuning fikk jeg 25, men den var ustabil (forskjellen i mål var mer enn 2 enheter). Jeg kan ikke gi noen anbefalinger ennå ved hjelp av vinduer og NFS-protokollen.

Etter alle innstillingene og sjekkene kjører vi testen på nytt fra klientdatamaskinen og gleder oss over det forbedrede resultatet (hvis det fungerer). Hvis resultatet har forbedret seg, er det mer enn 30 papegøyer (og spesielt mer enn 40), færre enn 10 brukere jobber samtidig, og arbeidsdatabasen er fortsatt treg - nesten helt sikkert et problem med programmereren (eller du har allerede nådd toppkapasiteten til filversjonen).

Terminalserver. (databasen er på serveren, klienter kobles til via nettverket, RDP-protokoll). Algoritme trinn for trinn:

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

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

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

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

For eksempel sjekket jeg driften av Gilev-testen med forskjellige diskalternativer. Jeg installerte skivene fra det som var for hånden, bare for å vise tendensen. Forskjellen mellom 8.3.6.2076 og 8.3.7.2008 er liten (i Ramdisk Turbo boost-versjon produserer 8.3.6 56.18 og 8.3.7.2008 produserer 55.56, i andre tester er forskjellen enda mindre). Strømforbruk - maksimal ytelse, turbo boost deaktivert (med mindre annet er oppgitt).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Enkel SSD	Ramdisk		Buffer aktivert RAID-kontroller
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
IC 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
IC 8,3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Den aktiverte RAID-kontrollerbufferen eliminerer alle forskjellene mellom diskene. tallene er de samme for både sat og cas. Testing med det på en liten mengde data er ubrukelig og er ikke veiledende av noe slag.

For plattform 8.2 er forskjellen i ytelse mellom SATA- og SSD-alternativer mer enn det dobbelte. Dette er ikke en skrivefeil. Hvis du ser på ytelsesmonitoren under testen på SATA-stasjoner. da kan du tydelig se "aktiv diskdriftstid (i%)" 80-95. Ja, hvis du aktiverer cachen til selve diskene for opptak, vil hastigheten øke til 35, hvis du aktiverer cachen til raid-kontrolleren - opptil 49 (uansett hvilke disker som er testet i dette øyeblikket). Men disse er syntetiske cache-papegøyer i ekte arbeid, med store databaser vil det aldri være et 100% skrive-cache-treffforhold.

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

Den mest korrekte (fra mitt ståsted) løsning vil være å tildele 2 SSD-disker i et speilvendt raid for en fildatabase (eller flere fildatabaser), og ikke plassere noe annet der. Ja, med et speil slites SSD-er like mye, og dette er et minus, men i det minste er kontrollerelektronikken på en eller annen måte beskyttet mot feil.

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

De viktigste fordelene med en terminalserver er at den kan ha svært svake klienter, og nettverksinnstillingene påvirker terminalserveren mye mindre (igjen din K.O.).

Konklusjoner: hvis terminalserver kjør Gilev-testen (fra samme disk hvor arbeidsdatabasene er plassert) og i de øyeblikkene når arbeidsdatabasen bremser ned, og Gilev-testen viser et godt resultat (over 30) - da er det mest sannsynlig at programmereren har skylden for langsom drift av hoveddatabasen.

Hvis Gilevs test viser små tall, og du har en høyklokkeprosessor og raske disker, må administratoren ta minst perfmon, registrere alle resultatene et sted, og se, observere og trekke konklusjoner. Det vil ikke være noen definitive råd.

Klient-server-alternativ.

Tester ble utført kun 8.2, fordi på 8.3 avhenger alt ganske alvorlig av versjonen.

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

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiberkanal - SSD	SQL: Xeon E5-2630 Fiberkanal - SAS	SQL: Xeon E5-2630 Lokal SSD	SQL: Xeon E5-2630 Fiberkanal - SSD	SQL: Xeon E5-2630 Lokal SSD	1C: Xeon 5650 =	1C: Xeon 5650 = Delt minne	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
IC 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

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

SAS på lagringssystemer er tregere enn lokale SSD-er, selv om lagringssystemene har større cache-størrelser. SSD-er, både lokale og på lagringssystemer for Gilevs test, fungerer med sammenlignbare hastigheter. Jeg kjenner ingen standard flertrådstest (ikke bare opptak, men alt utstyr) bortsett fra 1C-belastningstesten fra MCC.

Å endre 1C-serveren fra 5520 til 5650 doblet nesten ytelsen. Ja, serverkonfigurasjonene stemmer ikke helt overens, men det viser en trend (ingen overraskelse).

Å øke frekvensen på SQL-serveren gir absolutt en effekt, men ikke den samme som på 1C-serveren er utmerket (hvis du spør om det) for å bruke flerkjerner og ledig minne.

Å endre nettverket mellom 1C og SQL fra 1 Gbit til 10 Gbit gir omtrent 10 % papegøyer. Jeg forventet mer.

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

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

Hvor mye verre fungerer kombinasjonen av 1C og SQL i virtuell maskin- emnet for en egen artikkel (hint - merkbart verre). Selv i Hyper-V er ikke alt så klart...

Balansert ytelsesmodus er dårlig. Resultatene er ganske konsistente med filversjonen.

Mange kilder sier at feilsøkingsmodus (ragent.exe -debug) forårsaker en betydelig reduksjon i ytelse. Vel, det reduserer, ja, men jeg vil ikke kalle 2-3% en betydelig effekt.

Svært ofte kommer folk til oss med spørsmål som:

• Hvorfor bremser 1C-serveren?
• 1C-datamaskinen er veldig treg
• 1C-klienten er fryktelig treg

Noen ganger, som en løsning på problemet, tilbyr vi kundene en server for 1C til leie uten bremser, med valg av serverkonfigurasjon og operativsystem, kan du konfigurere serveren online på vår partner nettside, ved å bruke lenken https://1cloud.ru kapittel Tjenester, kapittel Virtuell server.

Hva du skal gjøre og hvordan du kan overvinne det, og så videre i rekkefølge:

Klienter jobber veldig sakte med serverversjonen av 1C

I tillegg til det trege arbeidet til 1C, er det også tregt arbeid med nettverksfiler. Problemet oppstår under normal drift og med RDP

for å løse dette starter jeg alltid etter hver installasjon av Seven eller 2008-serveren

netsh int tcp set global autotuning=deaktivert

netsh int tcp set global autotuninglevel=deaktivert

netsh int tcp set global rss=deaktivert skorstein=deaktivert

og nettverket fungerer uten problemer

noen ganger er det beste alternativet:

netsh-grensesnitt tcp set global autotuning= HighlyRestricted

slik ser installasjonen ut

Konfigurer Anti-Virus eller Windows brannmur

Hvordan konfigurere en antivirus- eller Windows-brannmur for å kjøre en 1C-server (en kombinasjon av 1C Server: Enterprise og MS SQL 2008, for eksempel).

Legg til regler:

• Hvis SQL-serveren godtar tilkoblinger på standard TCP-port 1433, tillater vi det.
• Hvis SQL-porten er dynamisk, må tilkoblinger til %ProgramFiles%\-applikasjonen tillates Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
• Server 1C kjører på porter 1541, cluster 1540 og range 1560-1591. Av helt mystiske grunner tillater noen ganger en slik liste over åpne porter fortsatt ikke tilkoblinger til serveren. For å være sikker på at det fungerer, tillat området 1540-1591.

Innstilling av server/datamaskinytelse

For at datamaskinen din skal fungere med maksimal ytelse, må du konfigurere den for dette:

1. BIOS-innstillinger

• I server-BIOS deaktiverer vi alle innstillinger for å spare prosessorkraft.
• Hvis det er "C1E" og sørg for å KOPPE !!
• For noen ikke veldig parallelle oppgaver anbefales det også å slå av hypertrading i BIOS
• I noen tilfeller (spesielt for HP!) må du gå inn i server-BIOS og slå AV elementene der som har EIST, Intel SpeedStep og C1E i navnene sine.
• I stedet må du finne elementer relatert til prosessoren der som har Turbo Boost i navnene, og AKTIVERE dem.
• Hvis i BIOS er det en generell indikasjon på en strømsparingsmodus og slå den på maksimal ytelse(det kan også kalles "aggressivt")

2. Skjemainnstillinger i operativsystemet - Høy ytelse

Servere med Intel Sandy Bridge-arkitektur kan dynamisk endre prosessorfrekvenser.

Noen ganger er løsningen på problemet med langsom drift av en 1C-server utdatert eller ødelagt utstyr, i dette tilfellet tilbyr vi kundene en server for 1C til leie uten bremser, med valg av serverkonfigurasjon og operativsystem, du kan gjøre det på vår partnerens nettsted, på lenken https://1cloud.ru Tjenester seksjon, Virtuell server seksjon.

Hvis du har spørsmål, vennligst kontakt:

• ring +7-812-385-55-66 i St. Petersburg
• skriv til adressen
• legg igjen en søknad på nettsiden vår på siden "Nettsøknad".

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øsningen på problemet med langsom 1C-drift 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 med en informasjonsgrunnlag(IB) det er ikke én, men flere brukere som jobber. 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. Dette reiser spørsmålet: "Er det mulig å implementere hele programmet på en kraftig server, slik at brukerens datamaskin ikke deltar i komplekse beregninger, men bare tjent til å overføre et bilde?» 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 vil vi trenge for alle som planlegger å jobbe i 1C Windows-lisens Server CAL, koster rundt 1700 rubler og en Windows Remote Desktop Services CAL-lisens, som koster rundt 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. Det ble satt store forhåpninger til "1C enterprise mini-serveren", 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 at det maksimale antallet brukere som miniserveren kunne brukes med var bare 5.

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 hvor 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, hvor informasjonssikkerhet er publisert.

Naturligvis bør dette enten være den kraftigste datamaskinen 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 gjennomstrømning nettverket blir ikke lenger 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 i den tekniske dokumentasjonen
• Plassert i knutepunktet for ansvar 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.