Performance 1s 8.3 filversjon. Fildatabaseflaskehalser - hvordan unngå (fra nyere erfaring). Instruksjoner for migrering fra en fildatabase til SQL
Etter å ha byttet fra 1C: Accounting 2.0 til utgave 3.0, blir hastigheten på den nye versjonen langsommere. Vi vil se på dette problemet i denne artikkelen og gi trinnvise instruksjoner for handlinger i 1C: Accounting 3.0-programmet, som vil bidra til å gjøre arbeidet raskere.
Som regel ligger årsaken til den trege driften av programmet i det faktum at rutine- og bakgrunnsjobber kjører i systemet. I serverversjonen av versjon 3.0-konfigurasjonen lar de deg automatisere mange operasjoner for å vedlikeholde programmet i ikke-arbeidstid. Men i fildriftsmodus startes bakgrunnsjobber mens brukeren jobber, og derfor bremser systemet.
For å øke hastigheten på arbeidet i 1C: Accounting 3.0-filmodus, anbefales det å deaktivere bakgrunnsjobber. For å gjøre dette, må vi henvise til avsnittet Administrasjon. I denne delen i navigasjonspanelet finner vi Support og service.
Åpne delen Regulatoriske operasjoner og klikk deretter på lenken Rutine- og bakgrunnsoppgaver.
En liste vil vises foran deg, der aktive (aktiverte) oppgaver er merket av. 
For å deaktivere en oppgave, må du åpne den og fjerne merket for alternativet "Aktivert", og trykk deretter på knappen Lagre og lukk.
Når du arbeider i filversjonen av programmet, anbefaler vi å deaktivere alle rutineoppgaver som finnes i listen. En annen mulig årsak til den lave hastigheten til systemet er den aktiverte mekanismen Fulltekstsøk. Siden i 1C: Accounting 3.0-programmet er denne mekanismen valgfri, kan den være det deaktiver. For å gjøre dette, må du gå til delen Regulatoriske operasjoner fjern merket Fulltekstdatasøk.
Vi mottar ofte spørsmål om hva som bremser 1c, spesielt når vi bytter til versjon 1c 8.3, takket være våre kolleger fra Interface LLC, forteller vi deg i detalj:
I våre tidligere publikasjoner har vi allerede 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 som gis "jern": "Regnskap 2.0 fløy bare, men "troikaen" beveget seg knapt," selvfølgelig, det er en viss sannhet i disse ordene, så la oss prøve å finne det ut.
Ressursforbruk, første øyekast
Før vi startet denne studien satte vi oss to mål: å finne ut om administrerte applikasjonsbaserte konfigurasjoner faktisk er tregere enn konvensjonelle konfigurasjoner, og hvilke spesifikke ressurser som har den primære innvirkningen på ytelsen.
For testing tok vi to virtuelle maskiner som kjører henholdsvis Windows Server 2012 R2 og Windows 8.1, og 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 WD Se, og klienten ble plassert på en lignende rekke generelle disker.
Som eksperimentelle baser valgte vi flere konfigurasjoner av Accounting 2.0, utgivelse 2.0.64.12 , som deretter ble oppdatert til 3.0.38.52 , ble alle konfigurasjoner lansert på plattformen 8.3.5.1443 .
Det første som tiltrekker seg oppmerksomhet er den økte størrelsen på troikaens informasjonsbase, som har vokst betydelig, samt en mye større appetitt på RAM:
Vi er klare til å høre det vanlige: "hvorfor la de det til disse tre", men la oss ikke forhaste oss. I motsetning til brukere av klient-serverversjoner, som krever en mer eller mindre kvalifisert administrator, tenker brukere av filversjoner sjelden på å vedlikeholde databaser. Også ansatte i spesialiserte selskaper som betjener (les oppdatering) disse databasene tenker sjelden på dette.
I mellomtiden er 1C-informasjonsbasen en fullverdig DBMS i sitt eget format, som også krever vedlikehold, og for dette er det til og med et verktøy som heter Testing og retting av informasjonsgrunnlaget. Kanskje spilte navnet en grusom spøk, som på en eller annen måte antyder at dette er et verktøy for feilsøking av problemer, men lav ytelse er også et problem, og restrukturering og reindeksering, sammen med tabellkomprimering, er velkjente verktøy for å optimalisere databaser for enhver DBMS-administrator . Skal vi sjekke?
Etter å ha brukt de valgte handlingene, "gikk databasen kraftig ned i vekt", og ble enda mindre enn de "to", som ingen noen gang hadde optimalisert, og RAM-forbruket gikk også litt ned.
Deretter, etter å ha lastet nye klassifiserere og kataloger, opprettet indekser, etc. størrelsen på basen vil øke; generelt er de "tre" basene 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 Prestasjonsmåling, utfører en sekvens av forhåndsbestemte handlinger i hver database.
Faktisk, for daglige oppgaver, er nettverksgjennomstrømning ikke en flaskehals, en uoptimalisert "tre" er bare 20 % tregere enn en "to", og etter optimalisering viser det seg å være omtrent det samme raskere - fordelene ved å jobbe i tynnklientmodus er tydelige. Overgangen til 1 Gbit/s gir ikke den optimaliserte basen noen fordeler, og den uoptimerte og de to begynner å jobbe raskere, og viser en liten forskjell mellom seg.
Fra 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 databaselastehastighet er kritisk for deg; i andre tilfeller lar nye konfigurasjoner deg jobbe effektivt selv i trege 100 Mbit/s-nettverk.
Så hvorfor er 1C treg? Vi skal se nærmere på det.
Serverdiskundersystem og SSD
I forrige artikkel oppnådde vi en økning i 1C-ytelse ved å plassere databaser på en SSD. Kanskje ytelsen til serverens diskdelsystem er utilstrekkelig? Vi målte ytelsen til en diskserver under en gruppekjøring i to databaser samtidig og fikk et ganske optimistisk resultat.
Til tross for det relativt store antallet input/output-operasjoner per sekund (IOPS) - 913, oversteg ikke kølengden 1,84, noe som er et veldig godt resultat for en to-disk-array. Basert på dette kan vi anta at et speil laget av vanlige disker vil være nok for normal drift av 8-10 nettverksklienter i tunge moduser.
Så er det nødvendig med en SSD på en server? Den beste måten å svare på dette spørsmålet på vil være gjennom testing, som vi utførte med en lignende metode, nettverkstilkoblingen er 1 Gbit/s overalt, resultatet uttrykkes også i relative verdier.
La oss starte med lastehastigheten til databasen.
Det kan virke overraskende for noen, men SSD-en på serveren påvirker ikke lastehastigheten til databasen. Den viktigste begrensende faktoren her, som forrige test viste, er nettverksgjennomstrømning og klientytelse.
La oss gå videre til å gjøre om:
Vi har allerede bemerket ovenfor at diskytelsen er ganske tilstrekkelig selv for å jobbe i tunge moduser, så hastigheten til SSD-en påvirkes heller ikke, bortsett fra den uoptimaliserte basen, som på SSD-en har innhentet den optimaliserte. Faktisk bekrefter dette nok en gang at optimaliseringsoperasjoner organiserer informasjon i databasen, reduserer antallet tilfeldige I/O-operasjoner og øker tilgangshastigheten til den.
I hverdagsoppgaver er bildet likt:
Bare den ikke-optimaliserte databasen drar nytte av SSD-en. Du kan selvfølgelig kjøpe en SSD, men det ville være mye bedre å tenke på rettidig vedlikehold av databasen. Ikke glem å defragmentere delen med infobaser på serveren.
Klientdiskundersystem og SSD
Vi diskuterte påvirkningen av SSD på driftshastigheten til lokalt installert 1C i det forrige materialet; 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 nedenfor kan du se hvordan Accounting 3.0 ganske aktivt får tilgang til disken i ca. 40 sekunder etter innlasting.
Men samtidig bør du være klar over at for en arbeidsstasjon hvor aktivt arbeid utføres med en eller to informasjonsdatabaser, er ytelsesressursene til en vanlig masseprodusert HDD ganske tilstrekkelig. Å kjøpe en SSD kan fremskynde noen prosesser, men du vil ikke merke en radikal akselerasjon i hverdagen, siden for eksempel nedlasting vil være begrenset av nettverksbåndbredde.
En treg harddisk kan bremse enkelte operasjoner, men kan i seg selv ikke føre til at et program bremser ned.
RAM
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.
Hvor fører det hen? La oss se hvordan systemressurser brukes i tunge operasjoner, for eksempel, la oss starte en gruppeoverføring i to databaser samtidig. Først på et system med 2 GB RAM:
Som vi kan se, bruker systemet aktivt nettverket til å motta data og prosessoren til å behandle dem; diskaktiviteten er ubetydelig; under behandlingen øker den av og til, men er ikke en begrensende faktor.
La oss nå redusere minnet til 1 GB:
Situasjonen endrer seg radikalt, hovedbelastningen faller nå på harddisken, prosessoren og nettverket er inaktive og venter på at systemet skal lese de nødvendige dataene fra disken inn i minnet og sende unødvendige data dit.
Samtidig viste selv subjektivt arbeid med to åpne databaser på et system med 1 GB minne å være ekstremt ubehagelig; kataloger og magasiner åpnet med en betydelig forsinkelse og aktiv tilgang til disken. For eksempel tok det omtrent 20 sekunder å åpne journalen Salg av varer og tjenester og ble ledsaget hele denne tiden av høy diskaktivitet (uthevet med en rød linje).
For å objektivt evaluere virkningen av RAM på ytelsen til konfigurasjoner basert på en administrert applikasjon, utførte vi tre målinger: lastehastigheten til den første databasen, lastehastigheten til den andre databasen og gjenkjøring av gruppe i en av databasene . Begge databasene er helt identiske og ble opprettet ved å kopiere den optimaliserte databasen. Resultatet er uttrykt i relative enheter.
Resultatet taler for seg selv: hvis lastetiden øker med omtrent en tredjedel, noe som fortsatt er ganske tolerabelt, øker tiden for å utføre operasjoner i databasen tre ganger, det er ikke nødvendig å snakke om noe komfortabelt arbeid under slike forhold. Forresten, dette er tilfellet når du kjøper en SSD kan forbedre situasjonen, men det er mye enklere (og billigere) å håndtere årsaken, ikke konsekvensene, og bare kjøpe riktig mengde RAM.
Mangel på RAM er hovedårsaken til at det å jobbe med nye 1C-konfigurasjoner viser seg å være ubehagelig. Konfigurasjoner med 2 GB minne om bord bør anses som minimalt egnet. Samtidig må du huske at i vårt tilfelle ble det opprettet "drivhus"-forhold: et rent system, bare 1C og oppgavebehandlingen kjørte. I det virkelige liv, på en arbeidsdatamaskin, er som regel en nettleser, en kontorpakke åpne, et antivirus kjører, etc., etc., så fortsett fra behovet for 500 MB per database, pluss litt reserve, slik at under tunge operasjoner møter du ikke mangel på hukommelse og kraftig nedgang i produktivitet.
prosessor
Uten overdrivelse kan sentralprosessoren kalles hjertet til datamaskinen, siden det er den som til slutt behandler alle beregninger. For å evaluere dens rolle, gjennomførte vi et annet sett med tester, det samme som for RAM, og reduserte antall kjerner tilgjengelig for den virtuelle maskinen fra to til én, og testen ble utført to ganger med minnemengder på 1 GB og 2 GB.
Resultatet viste seg å være ganske interessant og uventet: en kraftigere prosessor tok ganske effektivt på seg belastningen når det var mangel på ressurser, resten av tiden uten å gi noen konkrete fordeler. 1C Enterprise kan knapt kalles en applikasjon som aktivt bruker prosessorressurser; den 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 kommer nettverksytelsen; en treg 100 Mbit/s-kanal kan bli en skikkelig flaskehals, men samtidig er tynnklientmodusen i stand til å opprettholde et ganske komfortabelt driftsnivå selv på trege kanaler.
Da bør du ta hensyn til diskstasjonen; å kjøpe en SSD er neppe en god investering, men å bytte ut stasjonen med en mer moderne vil være en god idé. Forskjellen mellom generasjoner av harddisker kan vurderes fra følgende materiale: Gjennomgang av to rimelige Western Digital Blue-seriestasjoner på 500 GB og 1 TB.
Og til slutt prosessoren. En raskere modell vil 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.
Med veksten av organisasjonen og med økningen i antall brukere av informasjonsbasen 1C Enterprise på det lokale datanettverket, øker belastningen på hovedlagringen til informasjonsbasen - serveren. Derfor, før eller senere, kan lederen og IT-spesialisten i selskapet ha et spørsmål: Hvordan sikre et raskt, sikkert og effektivt system til lavest mulig økonomisk kostnad?
Først må du velge en metode for å organisere et automatisert bedriftsdatakompleks på plattformen 1C Enterprise 8. 1C-plattformen støtter to operasjonsalternativer: fil og klient-server. I begge tilfeller fungerer alle applikasjonsløsninger nøyaktig likt.
Filversjon av 1C arbeid designet for at en eller flere brukere skal jobbe på et lokalt nettverk. I dette tilfellet er all informasjonsbasedata (konfigurasjon, database, administrativ informasjon) plassert i én fil - en fildatabase utviklet spesielt for 1C Enterprise 8-applikasjonsløsninger.
Fordeler med fildriftsmodus
- Optimal for et lite antall brukere (opptil 5)
- Enkel å installere og betjene systemet
- For å jobbe med informasjonsbasen kreves det ingen ekstra programvare bortsett fra operativsystemet og 1C Enterprise 8
- Risikoen for brudd på dataintegriteten på grunn av feil på datamaskiner og lokalt nettverk reduseres.
- Lag enkelt sikkerhetskopier ved å kopiere infobase-filen.
Arbeid i filversjonen er mulig både direkte, direkte med databasefilen, og gjennom en webserver dersom klientforbindelser brukes via HTTP- eller HTTPS-protokollen.
Klient-serverversjon av 1C fungerer Designet for bruk på tvers av avdelinger, arbeidsgrupper eller på tvers av bedriften. Den er implementert basert på en tre-nivå klient-server-arkitektur:
Klientapplikasjon - 1C Enterprise server cluster - Databaseserver
I klient-serverversjonen er informasjonsbasen lagret i en av de støttede DBMSene: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. Den er tilgjengelig etter behov av klientapplikasjonen gjennom en klynge med 1C Enterprise-servere.
I 1C Enterprise 8-systemet er det tre klientapplikasjoner eller klient(et program som kjører for brukeren) med ulike funksjoner: tykk klient, tynn klient, nettklient.
Fet klient lar deg realisere de fulle egenskapene til 1C Enterprise 8 når det gjelder utvikling, administrasjon og utførelse av applikasjonskode. Den støtter imidlertid ikke arbeid med informasjonsdatabaser via Internett, krever forhåndsinstallasjon på brukerens datamaskin og har en ganske imponerende distribusjonsstørrelse.
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 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.
Deaktivering av planlagte oppgaver og bakgrunnsoppgaver i 1C 8.3
Foto av Alena Tulyakova, nyhetsbyrået "Clerk.Ru"
Artikkelen identifiserer hovedfeilene som nybegynnere 1C-administratorer gjør og viser hvordan de løses ved å bruke Gilev-testen som eksempel.
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 underforstått at selv for gamle datamaskiner fra 10 år siden (Pentium on 775-socket), bør tiden fra å klikke på 1C:Enterprise-snarveien til databasevinduet vises, ta mindre enn ett minutt. (Celeron = sakte).
Hvis datamaskinen din er verre enn en Pentium on 775-sokkel med 1 GB RAM, 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 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 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.
- Feil konfigurert 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.
- 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).
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 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.
| Dette er standardinnstillingene. BIOS C-tilstand aktivert, balansert strømforbruksmodus |  |
| BIOS C-state-aktivert, høyytelsesmodus For Pentium og Core kan du stoppe der, Du kan fortsatt presse litt "papegøyer" ut av Xeon |  |
| I BIOS er C-tilstand deaktivert, 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 den 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. 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å turbo boost 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?
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 store anstrengelser.
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 servershare, du kan gjøre 192.168.0.1share, du kan netto bruke z: 192.168.0.1share (og i noen tilfeller vil denne metoden også fungere, men ikke alltid) og deretter spesifisere stasjonen Z. Det ser ut til at alle disse banene pek på samme ting samme sted, men for 1C er det bare én metode 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: servershare. Eksempel: nettbruk m: serverbaser. Jeg legger spesielt vekt på IKKE IP-adressen, men servernavnet. 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 tatt i bruk. 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.
| 100 Mbit CIFS Vinn 2008 - Vinn 2008 kontakt på ip-adresse | 100 Mbit CIFS Vinn 2008 - Vinn 2008 ringer ved navn | 1 Gbit CIFS Vinn 2008 - Vinn 2008 kontakt på ip-adresse | 1 Gbit CIFS Vinn 2008 - Vinn 2008 ringer ved navn | 1 Gbit CIFS Vinn 2008 - Vinn 7 ringer ved navn | 1 Gbit CIFS Vinn 2008 - Debian ringer ved navn | 10 Gbit CIFS Vinn 2008 - Vinn 2008 kontakt på ip-adresse | 10 Gbit CIFS 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 1 Gbit fortsatt 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.
Terminalserver. (databasen er på serveren, klienter kobles til via nettverket, RDP-protokoll). Algoritme trinn for trinn:
- Vi legger Gilevs testdatabase til serveren i samme mappe som hoveddatabasene. Vi kobler til fra samme server og kjører testen. Vi husker resultatet.
- På nøyaktig samme måte som i filversjonen konfigurerer vi prosessoren. 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).
- Konfigurering av 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.
- Når 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.
| Raid 10 4x SATA 7200 ATA ST31500341AS | Raid 10 4x SAS 10k | Raid 10 4x SAS 15k | Enkel SSD | Ramdisk | 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 testes for øyeblikket). Men disse er syntetiske cache-papegøyer; i virkelig 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 at når jeg tester en SSD-disk, tester jeg også cachen til denne disken 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 svært svake klienter, og nettverksinnstillingene påvirker terminalserveren mye mindre (igjen din K.O.).
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 seriøst av versjonen.
For testing valgte jeg forskjellige serveralternativer og nettverk mellom dem for å vise hovedtrendene.
| 1C: Xeon 5520 SQL: Xeon E5-2630 | 1C: Xeon 5520 SQL: Xeon E5-2630 Fiberkanal - SSD | 1C: Xeon 5520 SQL: Xeon E5-2630 Fiberkanal - SAS | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 SQL: Xeon E5-2630 Fiberkanal - SSD | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 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, fungerer med sammenlignbare hastigheter for Gilevs test. Jeg kjenner ingen standard flertrådstest (ikke bare opptak, men alt utstyr) bortsett fra 1C-lasttesten 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, MS SQL-serveren er utmerket (hvis du spør om det) til å 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 i artikkelen. 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 ikke spesifiseres av FQDN (tcp/ip vil fungere), ikke gjennom localhost eller bare ServerName, men gjennom ServerNameInstanceName, for eksempel zz- testzztest. (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 brukere under 100 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.