1s 8 fungerer sakte på nettverket. Automatiseringstips

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

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

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 langsomme arbeidet til 1C, er det også sakte 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 (for eksempel en kombinasjon av 1C Server: Enterprise og MS SQL 2008).

Legg til regler:

• Hvis SQL-serveren godtar tilkoblinger på standard TCP-port 1433, tillater vi det.
• Hvis SQL-porten er dynamisk, må du tillate tilkoblinger til %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe-applikasjonen.
• 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 det i BIOS er en generell indikasjon på en strømsparingsmodus og inkludere den i maksimal ytelsesmodus (det kan også kalles "aggressiv")

2. Skjemainnstillinger i operativsystemet - Høy ytelse

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

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 også at det må være minst 2 GB ledig diskplass, 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 klient-server-alternativet, 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! Sørg også for å 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 blokken med utførelse 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. Når du velger et nytt forretningsprogram, 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 som 1C støtter (bakgrunnsjobber og spørringer i en løkke).
• Ved utforming av løsningsarkitekturen, unngå å bruke akkumuleringsregistre og regnskapsregistre i de mest flaskehalsområder.
• 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." Hva vi snakker om vil bli tydeligere hvis du ser på den typiske RAUSE-mekanismen.
• For å behandle store datamengder, bruk hjelpeklynger der samme database er tilkoblet (men ikke i noe tilfelle skal dette gjøres under interaktivt arbeid!!!). Dette vil tillate deg å omgå standard 1C-låser, som vil gjøre 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, stor artikkel, så følg med for oppdatert materiale på nettsiden vår.

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 presentere noen resultater og kommentere de mest sannsynlige feilene. 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 med en gang merke meg at endringer må gjøres trinnvis, 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 med vilje valgte var ikke det nyeste med moderne utstyr er resultatene 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 RAM, så sympatiserer jeg med deg, og det vil være vanskelig for deg å oppnå komfortabelt arbeid på 1C 8.2 i filversjonen. Tenk på enten en oppgradering (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 installerer testdatabasen på en lokal datamaskin (på en 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, bør det være 300-400 MB ledig minne for normal drift.

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 under testing prosessorkjernen ikke er fullastet, 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. (Gilev har en god beskrivelse. 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 på BIOS-innstillinger fra Gilev). Disse innstillingene er hovedsakelig relatert til serverprosessorer eller "avansert" BIOS, 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 gjøre oppmerksom på 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 standardinnstillingene fungerer Windows-klienten best med en Windows-server (eller til og med en Windows-arbeidsstasjon) og SMB/CIFS-protokollen, en linux-klient (debian, ubuntu så ikke på de andre) fungerer bedre med linux og NFS ( det fungerer også med SMB, men på NFS er papegøyer høyere). 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:

På kommandolinjen (eller i policyer, eller hva som er praktisk for deg) - 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 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 å leke 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 belastningsplanen 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 ennå ikke gi anbefalinger om bruk av Windows 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 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 den 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 testes for ø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. Opptaksressursen 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 at når jeg tester en SSD-stasjon, tester jeg også cachen til denne stasjonen i større grad, de reelle resultatene blir mindre.

Den mest korrekte (fra mitt ståsted) løsning vil være å tildele 2 SSD-disker 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 veldig svake klienter, og nettverksinnstillingene påvirker terminalserveren mye mindre (igjen din K.O.).

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

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 til (hvis du blir bedt om det) å 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 forbindelse med SQL Server 2000 ble ikke funnet. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSr : SQLSTATE=08001, tilstand=1, alvorlighetsgrad=10, native=126, linje=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 dårligere kombinasjonen av 1C og SQL fungerer i en virtuell maskin er tema i 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.

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 relevant for brukere av fildatabaser for 1-2 brukere, hvor det ikke er konkurranse om ressurser.

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

Hvor er de planlagte oppgavene i 1C 8.3?

Før jeg rakk å laste programmet, ble mange bakgrunnsoppgaver utført i 1C. 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 her er en komplett liste over alle planlagte oppgaver som er lansert:

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

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

Deaktivering av planlagte oppgaver og bakgrunnsoppgaver i 1C 8.3

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 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-hastighet og kostnadene deres, ved å bruke eksemplet med et lokalt nettverk med 10 mellomstore 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 koster i gjennomsnitt 1500 rubler, et nettverkskort som støtter en hastighet på 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 er denne løsningen 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

Den fikk stor popularitet tilbake i 1C 7-dagene. Den er implementert på serverversjonen av Windows og takler oppgaven vår godt. Det har imidlertid sine fallgruver, nemlig kostnadene for lisenser.

Selve operativsystemet vil koste omtrent 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 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, som informasjonssikkerhet publiseres på.

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 nettverksbåndbredden blir ikke kritisk. Våre tester har vist at du komfortabelt kan jobbe via mobilt Internett på et billig nettbrett uten å oppleve 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, har denne metoden for å optimalisere 1C-drift 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
• 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.