Hur man förstår varför 1C-servern är långsam. Automationstips

Hur man påskyndar arbetet i 1C: Accounting 8.3 (utgåva 3.0) eller inaktiverar rutin- och bakgrundsuppgifter

2019-01-15T13:28:19+00:00

Ni som redan har bytt till den nya utgåvan av 1C: Accounting 8.3 (utgåva 3.0) har märkt att den har blivit långsammare än 2. Några konstiga avmattningar, oändliga bakgrundsuppgifter flera gånger om dagen, som ingen bad henne utföra utan vår vetskap.

Mina revisorer sa till mig direkt efter övergången att den nya upplagan av 1C: Accounting 3.0 är direkt långsam jämfört med de tidigare! Och det är helt enkelt omöjligt att arbeta.

Jag började undersöka det och fick mycket snart reda på att den främsta orsaken till frysningar och efterföljande missnöje hos användare är rutin- och bakgrundsuppgifter, av vilka många är aktiverade som standard, även om det inte finns något behov av dem för de allra flesta revisorer.

Tja, varför behöver vi till exempel köra uppgiften "Textextraktion" hundra gånger om dagen om vi inte gör en fulltextsökning (revisorer, var inte rädda) över alla objekt i vår databas.

Eller varför ständigt ladda ner valutakurser om vi inte har valutatransaktioner eller vi gör dem ibland (och innan dess kan vi själva klicka på knappen för nedladdningskurser).

Detsamma gäller 1C:s ständiga försök att ansluta till sajten och kontrollera och uppdatera bankklassificerare. För vad? Jag kommer själv att trycka på knappen för att uppdatera klassificerarna om jag inte hittar rätt bank med dess BIC.

Hur man gör detta steg för steg nedan.

1. Gå till avsnittet "Administration" och välj "Underhåll" () i åtgärdspanelen:

2. I fönstret som öppnas, hitta och välj "Rutin- och bakgrundsuppgifter":

3. Öppna varje uppgift som har "På" i kolumnen "På". det finns en daw.

4. Avmarkera "Aktiverad" och klicka på knappen "Spara och stäng".

5. Gör detta med var och en av de inkluderade uppgifterna och njut av den nya utgåvan. Sammantaget, enligt min mening, är det mycket bättre än två.

Samtidigt kommer plattformen fortfarande att aktivera några av de schemalagda uppgifterna du inaktiverade.

Huvudsyftet med att skriva den här artikeln är att undvika att upprepa uppenbara nyanser för de administratörer (och programmerare) som ännu inte har fått erfarenhet av 1C.

Det sekundära målet är att om jag har några brister så kommer Infostart vara snabbast att påpeka detta för mig.

V. Gilevs test har redan blivit en slags "de facto" standard. Författaren på sin hemsida gav ganska tydliga rekommendationer, men jag kommer helt enkelt att presentera några resultat och kommentera de mest troliga felen. Naturligtvis kan testresultaten på din utrustning skilja sig åt. Detta är bara en guide för vad som bör vara och vad du kan sträva efter. Jag vill genast notera att ändringar måste göras steg för steg, och efter varje steg, kontrollera vilket resultat det gav.

Det finns liknande artiklar om Infostart, jag kommer att lägga länkar till dem i de relevanta avsnitten (om jag missar något, vänligen föreslå mig i kommentarerna, jag lägger till det). Så låt oss anta att din 1C är långsam. Hur diagnostiseras problemet och hur man förstår vem som är skyldig, administratören eller programmeraren?

Inledande data:

Testad dator, huvudmarsvin: HP DL180G6, utrustad med 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Som jämförelse visar Core i3-2100 jämförbara resultat i det entrådiga testet. Utrustningen jag medvetet valde var inte den nyaste med modern utrustning är resultaten märkbart bättre.

För testning av separata 1C- och SQL-servrar, SQL-server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

För att testa ett 10 Gbit-nätverk användes Intel 520-DA2-adaptrar.

Filversion. (databasen finns på servern i en delad mapp, klienter ansluter via nätverket, CIFS/SMB-protokoll). Algoritm steg för steg:

0. Lägg till Gilevs testdatabas till filservern i samma mapp som huvuddatabaserna. MED klientdator anslut, kör testet. Vi minns resultatet.

Det är underförstått att även för gamla datorer för 10 år sedan (Pentium on 775 socket ) tiden från att du klickar på 1C:Enterprise-genvägen tills databasfönstret visas bör vara mindre än en minut. ( Celeron = långsam).

Om du har en dator som är sämre än en Pentium 775 uttag med 1 GB RAM, då sympatiserar jag med dig, och det kommer att vara svårt för dig att uppnå bekvämt arbete på 1C 8.2 i filversionen. Tänk på antingen en uppgradering (det är hög tid) eller att byta till terminal (eller webb, i så fall tunna klienter och hanterade formulär) server.

Om datorn inte är sämre kan du sparka administratören. Kontrollera åtminstone funktionen för nätverks-, antivirus- och HASP-skyddsdrivrutinen.

Om Gilevs test i detta skede visade 30 "papegojor" eller högre, men 1C-arbetsbasen fortfarande fungerar långsamt, bör frågorna riktas till programmeraren.

1. Som en guide till hur mycket en klientdator kan "pressa" kontrollerar vi funktionen på endast denna dator, utan nätverk. Vi lägger testbasen på lokal dator(på en mycket snabb disk). Om klientdatorn inte har en normal SSD skapas en ramdisk. För närvarande är den enklaste och gratis Ramdisk Enterprise.

För att testa version 8.2 räcker det med en 256 MB ramdisk, och! Det viktigaste. Efter omstart av datorn, med ramdisken igång, bör det finnas 100-200 MB ledigt på den. Följaktligen, utan en ramdisk, bör det finnas 300-400 MB ledigt minne för normal drift.

För att testa version 8.3 räcker det med en 256 MB ramdisk, men du behöver mer ledigt RAM-minne.

När du testar måste du titta på processorbelastningen. I ett fall nära idealiskt (ramdisk), laddar lokal fil 1c 1 processorkärna när den körs. Följaktligen, om din processorkärna inte är fulladdad under testning, leta efter svaga punkter. Lite känslomässigt, men generellt korrekt, beskrivs processorns inflytande på driften av 1C. Bara för referens, även på moderna Core i3s med höga frekvenser, är siffrorna 70-80 ganska realistiska.

De vanligaste felen i detta skede.

a) Felaktigt konfigurerat antivirusprogram. Det finns många antivirus, inställningarna för varje är olika, jag kommer bara att säga att med korrekt konfiguration stör varken webben eller Kaspersky 1C. Med standardinställningarna kan cirka 3-5 papegojor (10-15%) tas bort.

b) Prestandaläge. Av någon anledning är det få som uppmärksammar detta, men effekten är den mest betydande. Om du behöver hastighet måste du göra detta, både på klient- och serverdatorer. ( Bra beskrivning hos Gilev. Det enda förbehållet är att på vissa moderkort Om du stänger av Intel SpeedStep kan du inte slå på TurboBoost).

Kort sagt, medan 1C körs är det mycket väntan på svar från andra enheter (disk, nätverk, etc.). I väntan på ett svar, om prestandaläget är aktiverat, sänker processorn sin frekvens. Ett svar kommer från enheten, 1C (processorn) måste fungera, men de första klockcyklerna är på en reducerad frekvens, sedan ökar frekvensen - och 1C väntar återigen på ett svar från enheten. Och så – många hundra gånger per sekund.

Du kan (och helst) aktivera prestandaläge på två ställen:

Via BIOS. Inaktivera lägena C1, C1E, Intel C-state (C2, C3, C4). I olika bios kallas de olika, men innebörden är densamma. Det tar lång tid att söka, en omstart krävs, men om du gör det en gång, då kan du glömma det. Om du gör allt rätt i BIOS kommer hastigheten att öka. På vissa moderkort kan du konfigurera BIOS-inställningarna så att Windows prestandaläge inte spelar någon roll. (Exempel BIOS-inställningar i Gilev). Dessa inställningar gäller främst serverprocessorer eller "avancerat" BIOS, om du inte har hittat en och du INTE har Xeon, är det okej.

Kontrollpanel - Strömförsörjning - Hög prestanda. Minus - om datorn inte har varit servad på länge kommer den att göra ett högre fläktljud, värma upp mer och förbruka mer energi. Detta är en prestationsavgift.

Hur man kontrollerar att läget är aktiverat. Starta aktivitetshanteraren - prestanda - resursövervakare - CPU. Vi väntar tills processorn är upptagen med ingenting.

Dessa är standardinställningarna.

I BIOS C-läge ingår,

balanserat energiförbrukningsläge

I BIOS C-läge ingår, högpresterande läge

För Pentium och Core kan du stanna där,

Du kan fortfarande pressa ut lite "papegojor" ur Xeon

I BIOS C-läge avstängd, högpresterande läge.

Om du inte använder Turbo boost är det så här det ska se ut

servern är inställd för prestanda

Och nu siffrorna. Låt mig påminna dig: Intel Xeon 5650, ramdisk. I det första fallet visar testet 23,26, i det sista - 49,5. Skillnaden är nästan dubbel. Siffrorna kan variera, men förhållandet förblir i stort sett detsamma för Intel Core.

Kära administratörer, ni kan kritisera 1C hur mycket som helst, men om slutanvändare behöver snabbhet måste ni aktivera högpresterande läge.

c) Turbo Boost. Först måste du förstå om din processor stöder den här funktionen, till exempel. Om det stöder, så kan du fortfarande helt lagligt få lite prestanda. (Jag vill inte beröra frågorna om frekvensöverklockning, speciellt servrar, gör det på egen risk och risk. Men jag håller med om att ökad busshastighet från 133 till 166 ger en mycket märkbar ökning av både hastighet och värmeavledning)

Hur man slår på turboboost skrivs till exempel . Men! För 1C finns det några nyanser (inte de mest uppenbara). Svårigheten är att den maximala effekten av turboboost uppstår när C-state är på. Och vi får något sånt här:

Observera att multiplikatorn är maximal, kärnhastigheten är vacker och prestandan är hög. Men vad kommer att hända som ett resultat med 1:or?

	Faktor	Kärnhastighet (frekvens), GHz	CPU-Z enkel tråd	Gilev Ramdisk test filversion	Gilev Ramdisk test klient-server
Utan Turbo boost
C-state av, turboförstärkning				53.19	40,32
C-state på, turboförstärkning			1080	53,13	23,04

Men i slutändan visar det sig att enligt CPU-prestandatester ligger versionen med en multiplikator på 23 före, enligt Gilevs tester i filversionen är prestandan med en multiplikator på 22 och 23 densamma, men i klient-servern version - versionen med en multiplikator på 23 är fruktansvärt fruktansvärt fruktansvärt (även om C-state satt till nivå 7, är det fortfarande långsammare än med C-state avstängt). Därför är rekommendationen att kontrollera båda alternativen själv och välja det bästa. Hur som helst är skillnaden mellan 49,5 och 53 papegojor ganska betydande, speciellt utan större ansträngning.

Slutsats - turboboost måste slås på. Låt mig påminna dig om att det inte räcker att aktivera Turbo boost-objektet i BIOS, du måste också titta på andra inställningar (BIOS: QPI L0s, L1 - inaktivera, kräver skrubbning - inaktivera, Intel SpeedStep - aktivera, Turbo boost - aktivera Kontrollpanel - Energialternativ - Hög prestanda). Och jag skulle fortfarande (även för filversionen) välja alternativet där c-state är avstängt, trots att multiplikatorn är mindre. Det kommer att bli något sånt här...

En ganska kontroversiell punkt är minnesfrekvensen. Till exempel har minnesfrekvens visat sig ha ett mycket starkt inflytande. Mina tester visade inte något sådant beroende. Jag kommer inte att jämföra DDR 2/3/4, jag kommer att visa resultaten av att ändra frekvensen inom samma linje. Minnet är detsamma, men i BIOS tvingas vi ställa in lägre frekvenser.

Och testresultat. IC 8.2.19.83, för filversion lokal ramdisk, för klient-server 1C och SQL på en dator, delat minne. Turboboost är inaktiverat i båda versionerna. 8.3 visar jämförbara resultat.

Skillnaden ligger inom mätfelet. Jag tog specifikt fram skärmdumpar av CPU-Z för att visa att med en förändring i frekvens ändras också andra parametrar, samma CAS Latency och RAS till CAS Delay, vilket neutraliserar förändringen i frekvens. Skillnaden blir när minnesmodulerna ändras fysiskt, från långsammare till snabbare, men även där är siffrorna inte särskilt betydande.

2. När vi har sorterat processorn och minnet på klientdatorn går vi vidare till nästa mycket viktiga plats - nätverket. Många volymer av böcker har skrivits om nätverksinställning, det finns artiklar om Infostart ( och andra), men här kommer jag inte att fokusera på detta ämne. Innan du börjar testa 1C, se till att iperf mellan två datorer visar hela bandbredden (för 1 Gbit-kort - ja, åtminstone 850 Mbit, eller ännu bättre 950-980), som Gilevs råd har följts. Sedan - det enklaste testet av arbete blir konstigt nog att kopiera en stor fil(5-10 gigabyte) över nätverket. Ett indirekt tecken på normal drift på ett 1 Gbit-nätverk kommer att vara den genomsnittliga kopieringshastigheten på 100 MB/sek, bra drift - 120 MB/sek. Jag skulle vilja fästa din uppmärksamhet på det faktum att den svaga punkten (inklusive) kan vara processorbelastningen. SMB Protokollet på Linux är ganska dåligt parallelliserat, och under drift kan det ganska enkelt "äta upp" en processorkärna och inte förbruka mer.

Och vidare. Med standardinställningar windows klient fungerar bäst med Windows Server (eller till och med windows fungerar station) och SMB/CIFS-protokoll, linux klient(debian, ubuntu tittade inte på de andra) fungerar bättre med linux och NFS (det fungerar också med SMB, men på NFS är papegojorna högre). Det faktum att en Windows Linux-server till NFS under linjär kopiering kopieras till en ström snabbare betyder ingenting. Debian tuning för 1C är ett ämne för en separat artikel, jag är inte redo för det än, även om jag kan säga att i filversionen fick jag till och med något bättre prestanda än Win-versionen på samma utrustning, men med postgres med över 50 användare Jag har fortfarande allt väldigt dåligt.

Det viktigaste , som "brända" administratörer vet, men nybörjare tar inte hänsyn till. Det finns många sätt att ställa in sökvägen till 1c-databasen. Du kan göra \\server\share, du kan göra \\192.168.0.1\share, du kan nettoanvända z: \\192.168.0.1\share (och i vissa fall kommer den här metoden också att fungera, men inte alltid) och sedan specificera Z-enheten Det verkar som att alla dessa vägar pekar till samma plats, men för 1C finns det bara ett sätt som ger normal prestanda ganska tillförlitligt. Så det här är vad du behöver göra korrekt:

I kommandorad(eller i policyer, eller som du föredrar) - använd DriveLetter på nätet: \\server\share. Exempel: nätanvändning m: \\server\baser. Jag betonar specifikt INTE IP-adressen, nämligen namn server. Om servernamnet inte är synligt lägger du till det i dns på servern eller lokalt i hosts-filen. Men adressen måste vara vid namn. Följaktligen, på vägen till databasen, få tillgång till denna disk (se bild).

Och nu ska jag visa med siffror varför detta är rådet. Inledande data: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169-kort OS Win 2008 R2, Win 7, Debian 8. Senaste drivrutiner, uppdateringar tillämpade. Innan jag testade såg jag till att Iperf ger hela bandbredden (förutom 10 Gbit-kort lyckades den bara pressa ut 7,2 Gbit, jag får se varför senare, testservern är ännu inte riktigt konfigurerad). Diskarna är olika, men överallt finns det en SSD (jag satte speciellt in en enda disk för att testa, den är inte laddad med något annat) eller en raid från en SSD. Hastigheten på 100 Mbit erhölls genom att begränsa inställningarna för Intel 362-adaptern. Det fanns ingen skillnad mellan 1 Gbit koppar Intel 350 och 1 Gbit optisk Intel X520-DA2 (erhållen genom att begränsa hastigheten på adaptern). Maximal prestanda, turboboost är avstängt (bara för att resultaten ska kunna jämföras, ger turboboost för bra resultat lite mindre än 10%, för dåliga resultat kanske det inte har någon effekt alls). Version 1C 8.2.19.86, 8.3.6.2076. Jag ger inte alla siffror, utan bara de mest intressanta, så att du har något att jämföra med.

	Vinn 2008 - Vinn 2008 kontakt via ip-adress	Vinn 2008 - Vinn 2008 Ringer med namn	Vinn 2008 - Vinn 2008 Kontakt via IP-adress	Vinn 2008 - Vinn 2008 Ringer med namn	Win 2008 - Win 7 Ringer med namn	Win 2008 - Debian Ringer med namn	Vinn 2008 - Vinn 2008 Kontakt via IP-adress	Vinn 2008 - Vinn 2008 Ringer med namn
	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

Slutsatser (från tabellen och från personlig erfarenhet. Gäller endast för filversionen):

Över nätverket kan du få ganska normala siffror för arbete om detta nätverk är korrekt konfigurerat och sökvägen skrivs in korrekt i 1C. Även den första Core i3 kan mycket väl producera 40+ papegojor, vilket är ganska bra, och det här är inte bara papegojor, utan riktigt arbete skillnaden är också märkbar. Men! Begränsningen när man arbetar med flera (mer än 10) användare kommer inte längre att vara nätverket, här räcker fortfarande 1 Gbit, men blockering vid fleranvändararbete (Gilev).

1C 8.3-plattformen är många gånger mer krävande när det gäller korrekt nätverkskonfiguration. Grund inställningar– se Gilev, men tänk på att allt kan påverka. Jag såg en acceleration från att avinstallera (och inte bara stänga av) antiviruset, från att ta bort protokoll som FCoE, från att byta drivrutiner till en äldre, men Microsoft-certifierad version (särskilt för billiga kort som ASUS och DLC), från att ta bort det andra nätverkskortet från servern. Det finns många alternativ, ställ in ditt nätverk noggrant. Det kan mycket väl finnas en situation där plattform 8.2 ger acceptabla siffror och 8.3 - två eller till och med fler gånger mindre. Testa att spela med plattformsversion 8.3, ibland får du väldigt stor effekt.

1C 8.3.6.2076 (kanske senare, exakt version Jag har inte tittat ännu) det är fortfarande lättare att konfigurera över nätverket än 8.3.7.2008. Jag kunde uppnå normal drift över nätverket från 8.3.7.2008 (i jämförbara papegojor) bara några gånger, jag kunde inte upprepa det för ett mer allmänt fall. Jag förstod inte mycket, men att döma av fotlindningarna från Process Explorer Där fungerar inte inspelningen lika bra som i 8.3.6.

Trots det faktum att när man arbetar på ett 100 Mbit-nätverk är dess belastningsdiagram liten (vi kan säga att nätverket är gratis), är driftshastigheten fortfarande mycket mindre än på 1 Gbit. Anledningen är nätverkslatens.

Allt annat lika (ett välfungerande nätverk) för 1C 8.2 är Intel-Realtek-anslutningen 10% långsammare än Intel-Intel. Men realtek-realtek kan generellt ge skarpa sättningar ur det blå. Därför, om du har pengar, är det bättre att ha Intel-nätverkskort överallt; om du inte har pengar, installera då Intel endast på servern (din CO). Och det finns många gånger fler instruktioner för att ställa in Intels nätverkskort.

Standard antivirusinställningar (med drweb version 10 som exempel) tar upp cirka 8-10% av papegojor. Om du konfigurerar det som det ska (låt 1cv8-processen göra allt, även om det inte är säkert), är hastigheten densamma som utan antivirus.

Läs INTE Linux-guruer. En server med samba är jättebra och gratis, men om du installerar Win XP eller Win7 (eller ännu bättre - server OS) på servern så kommer filversionen av 1c att fungera snabbare. Ja, samba och protokollstacken och nätverksinställningar och mycket, mycket mer kan justeras väl i debian/ubuntu, men detta rekommenderas för specialister. Det är ingen idé att installera Linux med standardinställningar och sedan säga att det går långsamt.

Det är en ganska bra idé att kontrollera funktionen för diskar som är anslutna via nätanvändning med fio . Det kommer åtminstone att framgå om det är problem med 1C-plattformen, eller med nätverket/disken.

För enanvändarversionen kan jag inte tänka på tester (eller en situation) där skillnaden mellan 1 Gbit och 10 Gbit skulle vara synlig. Det enda där 10Gbit för filversionen gav bättre resultat är att ansluta diskar via iSCSI, men detta är ett ämne för en separat artikel. Ändå tror jag att för filversionen räcker det med 1 Gbit-kort.

Jag förstår inte varför, med ett 100 Mbit-nätverk, 8.3 fungerar märkbart snabbare än 8.2, men det var ett faktum. All annan utrustning, alla andra inställningar är absolut desamma, det är bara att i ett fall testas 8.2 och i det andra - 8.3.

Icke-trimmad NFS win-win eller win-lin ger 6 papegojor, jag tog inte med dem i tabellen. Efter trimning fick jag 25, men det var instabilt (skillnaden i mått var mer än 2 enheter). Jag kan ännu inte ge rekommendationer om hur du använder Windows och NFS-protokollet.

Efter alla inställningar och kontroller kör vi testet igen från klientdatorn och gläds åt det förbättrade resultatet (om det fungerar). Om resultatet har förbättrats finns det fler än 30 papegojor (och särskilt fler än 40), färre än 10 användare arbetar samtidigt, och arbetsdatabasen är fortfarande långsam - nästan säkert ett problem med programmeraren (eller så har du redan nått toppkapaciteten för filversionen).

Terminalserver. (databasen finns på servern, klienter ansluter via nätverket, RDP-protokoll). Algoritm steg för steg:

0. Lägg till Gilevs testdatabas till servern i samma mapp som huvuddatabaserna. Vi ansluter från samma server och kör testet. Vi minns resultatet.

1. På samma sätt som i filversionen ställer vi upp arbetet. När det gäller en terminalserver spelar processorn i allmänhet huvudrollen (det antas att det inte finns några uttryckliga svaga punkter, såsom brist på minne eller stor mängd onödig programvara).

2. Att sätta upp nätverkskort i fallet med en terminalserver har praktiskt taget ingen effekt på driften av 1c. För att säkerställa "särskild" komfort, om din server producerar mer än 50 papegojor, kan du leka med nya versioner av RDP-protokollet, bara för användarnas bekvämlighet, snabbare svar och rullning.

3. Om ett stort antal användare aktivt arbetar (och här kan du redan försöka ansluta 30 personer till en databas, om du försöker), är det mycket lämpligt att installera en SSD-enhet. Av någon anledning tror man att disken inte påverkar driften av 1C särskilt, men alla tester utförs med kontrollerns cache aktiverad för skrivning, vilket är felaktigt. Testbasen är liten, den passar ganska bra i cachen, därav de höga siffrorna. På riktiga (stora) databaser kommer allt att vara helt annorlunda, så cachen är inaktiverad för tester.

Till exempel kontrollerade jag driften av Gilev-testet med olika diskalternativ. Jag installerade skivorna från det som fanns till hands, bara för att visa tendensen. Skillnaden mellan 8.3.6.2076 och 8.3.7.2008 är liten (i Ramdisk Turbo boost ger version 8.3.6 56.18 och 8.3.7.2008 55.56, i andra test är skillnaden ännu mindre). Strömförbrukning - maximal prestanda, turboförstärkning inaktiverad (om inget annat anges).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Enkel SSD	Ramdisk		Cache aktiverad 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 aktiverade RAID-styrenhetens cache eliminerar alla skillnader mellan diskarna. siffrorna är desamma för både sat- och cas. Att testa med det på en liten mängd data är värdelöst och är inte indikativt av något slag.

För plattform 8.2 är skillnaden i prestanda mellan SATA- och SSD-alternativ mer än dubbelt så stor. Detta är inget stavfel. Om du tittar på prestandamonitorn under testet på SATA-enheter. då syns det tydligt där" Aktiv tid diskarbete (i%)" 80-95. Ja, om du aktiverar själva diskarnas cache för inspelning kommer hastigheten att öka till 35, om du aktiverar raidcontrollercachen - upp till 49 (oavsett vilka diskar som testas) i det här ögonblicket). Men dessa är syntetiska cache-papegojor i verkligt arbete, med stora databaser kommer det aldrig att finnas ett 100% skrivcache-träffförhållande.

Hastigheten på även billiga SSD:er (jag testade på Agility 3) är tillräckligt för att köra filversionen. Inspelningsresursen är en annan sak, du måste titta på den i varje specifikt fall, det är klart att Intel 3700 kommer att ha det en storleksordning högre, men priset är motsvarande. Och ja, jag förstår att när jag testar en SSD-disk så testar jag även cachen på denna disk i större utsträckning, de verkliga resultaten blir mindre.

Den mest korrekta (ur min synvinkel) lösning skulle vara att välja 2 SSD-disk in i en spegelraid för en fildatabas (eller flera fildatabaser), och placera inte något annat där. Ja, med en spegel slits SSD-enheter lika mycket, och detta är ett minus, men åtminstone styrelektroniken är på något sätt skyddad från fel.

De främsta fördelarna med SSD-enheter för filversionen kommer att visas när det finns många databaser, var och en med flera användare. Om det finns 1-2 databaser, och det finns cirka 10 användare, räcker det med SAS-diskar. (men i alla fall, titta på att ladda dessa diskar, åtminstone genom perfmon).

De främsta fördelarna med en terminalserver är att den kan ha mycket svaga klienter, och nätverksinställningarna påverkar terminalservern mycket mindre (återigen, din K.O.).

Slutsatser: om du kör Gilev-testet på en terminalserver (från samma disk där arbetsdatabaserna finns) och vid de ögonblick då arbetsdatabasen saktar ner, och Gilev-testet visar ett bra resultat (över 30), då långsam drift av den huvudsakliga arbetsdatabasen är troligen att skylla på en programmerare.

Om Gilevs test visar små siffror och du har en högklockad processor och snabba diskar, måste administratören ta åtminstone perfmon, spela in alla resultat någonstans och titta, observera och dra slutsatser. Det kommer inga definitiva råd.

Klient-server-alternativ.

Tester utfördes endast den 8.2, eftersom på 8.3 beror allt ganska allvarligt på versionen.

För att testa valde jag olika varianter servrar och nätverken mellan dem för att visa de viktigaste trenderna.

	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 = Delat 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 verkar som att jag har övervägt alla intressanta alternativ, om det är något annat du är intresserad av, skriv i kommentarerna, jag ska försöka göra det.

SAS på lagringssystem är långsammare än lokala SSD:er, även om lagringssystemen har större cachestorlekar. SSD:er, både lokala och på lagringssystem, fungerar med jämförbara hastigheter för Gilevs test. Jag känner inte till något standardtest med flera trådar (inte bara inspelning, utan all utrustning) förutom 1C-belastningstestet från MCC.

Att ändra 1C-servern från 5520 till 5650 fördubblade nästan prestandan. Ja, serverkonfigurationerna stämmer inte helt överens, men det visar en trend (ingen överraskning).

Att öka frekvensen på SQL-servern ger förvisso effekt, men inte samma som på 1C-servern MS SQL-servern är utmärkt (om man frågar det) för att använda multi-core och ledigt minne.

Att byta nätverk mellan 1C och SQL från 1 Gbit till 10 Gbit ger ungefär 10 % papegojor. Jag förväntade mig mer.

Aktivering av delat minne ger fortfarande en effekt, om än inte 15 %, enligt beskrivningen. Se till att göra det, lyckligtvis går det snabbt och enkelt. Om någon under installationen gav SQL-servern en namngiven instans, så för att 1C ska fungera måste servernamnet inte specificeras av FQDN (tcp/ip kommer att fungera), inte via localhost eller bara ServerName, utan genom ServerName\InstanceName, till exempel zz-test\zztest. (Annars kommer det att uppstå ett DBMS-fel: Microsoft SQL Server Native Client 10.0: Delat minnesleverantör: Det delade minnesbiblioteket som användes för att upprätta en anslutning till SQL Server 2000 hittades inte. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, state=1, Severity=10, native=126, line=0).

För mindre än 100 användare är den enda punkten med att dela upp den i två separata servrar en Win 2008 Std (och äldre) licens, som bara stöder 32 GB RAM. I alla andra fall måste 1C och SQL definitivt installeras på en server och ges mer (minst 64 GB) minne. Att ge MS SQL mindre än 24-28 GB RAM är omotiverad girighet (om du tror att du har tillräckligt med minne för det och allt fungerar bra, kanske filversionen av 1C skulle räcka för dig?)

Hur sämre kombinationen av 1C och SQL fungerar i en virtuell maskin är ämnet i en separat artikel (tips - märkbart värre). Inte ens i Hyper-V är allt så tydligt...

Balanserat prestandaläge är dåligt. Resultaten är ganska överensstämmande med filversionen.

Många källor säger att felsökningsläge (ragent.exe -debug) orsakar en betydande minskning av prestanda. Jo, det minskar, ja, men jag skulle inte kalla 2-3% en signifikant effekt.

Orsaker långsamt arbete 1C. Några ord om filläge.

Som vissa användare noterar skapade nya 1C-konfigurationer på grundval hanterad applikation, arbeta med otillräcklig hastighet. I den här artikeln kommer vi att försöka svara på vilka skäl som påverkar driften av 1C i filläge, förutom det faktum att nya funktioner kräver mer resurser.

Tidigare sa vi att hastigheten på 1C beror på disksystemets prestanda. Dessa resultat erhölls genom att köra applikationen på en specifik dator eller terminalserver. Men ett antal implementeringar inträffar när man arbetar med ett nätverk där servern antingen är en dedikerad server baserad på en enkel PC, eller bara en användares dator.

Övervakning av olika "inhemska" resurser visade att praktiskt taget ingen uppmärksamhet ägnas åt denna fråga. Den populära uppfattningen har blivit att konfigurationen på den hanterade applikationen är skyldig. Huvudrekommendationen är att byta till ett annat läge: server-klient eller terminal. Dessa påståenden är bara delvis sanna. Detta kommer att diskuteras senare.

En första titt på resursförbrukning.

I den här artikeln kommer vi att försöka svara på två frågor:

Är det sant att hanterade appkonfigurationer är långsammare än enkla?
Vad påverkar främst produktiviteten?

För att svara på dessa frågor genomförde vi en speciell studie. För detta tog vi två virtuella maskiner. Den första är kontrollerad Wind o ws S e rv er 2012 R 2, och den andra Wind o ws 8.1. Var och en av dessa maskiner tilldelades två kärnor (Co re i 5-4670), samt 2 gigabyte RAM. Dessa siffror är genomsnittliga för en vanlig kontorsdator. Servern placerades på RAID 0 av två W.D. Se . Klienten fanns på en liknande uppsättning diskar för allmänna ändamål.

För experimentet tog vi olika konfigurationer av Accounting 2.0, release 2.0.64.12. Senare uppdaterades versionen till 3.0.38.52. Lansering gjordes på plattform 8.3.5.1443.

Det som direkt märks är att storleken informationsbas den tredje versionen växer märkbart. RAM-förfrågningar ökar också:

Ris. 1

Trots skepsisen mot den tredje versionen är det värt att notera att vanliga användare av filversioner faktiskt inte uppmärksammar behovet av att underhålla databaser och uppdatera dem. Detta är en betydande skillnad från klient-serverversionen, som i regel underhålls av en kvalificerad administratör.

1C informationsdatabasen kräver dock konstant underhåll för att korrekt funktion, som alla DBMS. Ett speciellt verktyg för detta är att testa och korrigera informationsbasen. Trots namnet, som antyder att det här verktyget är designat enbart för att fixa problem, är dålig prestanda också ett problem. Du kan optimera databasen med hjälp av omstrukturering och omindexering. Det ser ut så här:

Ris. 2

Användningen av dessa alternativ resulterade i att databasen blev mindre än den andra versionen. Det är värt att notera att de "två" inte heller var optimerade tidigare. För övrigt har RAM-förbrukningen också minskat.

Ris. 3

Senare laddade vi ner nya klassificerare och kataloger, skapade index och utförde ett antal andra nödvändiga åtgärder. Allt detta ledde till en ökning av basen för den tredje versionen. Så om de "två" behövde maximalt 20 megabyte RAM, behöver den nya utgåvan cirka 500 MB. Detta värde måste beaktas vid fortsatt arbete.

Netto

Låt oss överväga en parameter som genomströmning nätverk, vilket är en av de viktigaste för nätverkstillämpningar. 1C flyttar stora mängder information och nätverk i organisationer byggs huvudsakligen på 100 megabits utrustning. Detta var villkoret för att välja prestandaindikatorer lika med 100 megabit och 1 gigabit per sekund för testet.

Låt oss titta på de processer som inträffar när 1C-fildatabasen startas för första gången över nätverket. När den startas första gången laddar användaren ner en stor mängd information till tillfälliga mappar. Vid 100 Megabit/sek kommer nedladdningen att ta cirka fyrtio sekunder, detta beror på att kanalbredden inte tillåter att processerna kan utföras snabbare.

Ris. 4

Den andra lanseringen kommer att vara snabbare på grund av cachning av vissa data. Att ändra nätverket till 1 Gbit/s gör att 1C laddas snabbare. Detta är tydligt avbildat i bilden nedan:

Ris. 5

Efter att ha analyserat datan ser vi att den andra versionen laddas snabbare, oavsett hastighet. Vi ser också att övergång till gigabithastigheter förbättrar uppstartstiderna med 4x. Graferna visar också att i detta läge finns det praktiskt taget inga skillnader förknippade med optimeringen av den tredje versionen.

Att testa inverkan av nätverkshastighet på tung drift visade följande resultat:

Ris. 6

Låt oss ta en närmare titt. Den tredje versionen på 100 megabit med en optimerad bas har en hastighet motsvarande den andra versionen, medan "trojkan" utan optimering "saktar ner" nästan två gånger. Vid 1 Gbit/s förblir proportionerna praktiskt taget oförändrade. Dessutom minskar övergången till gigabithastighet faktiskt överföringstiden med tre gånger för två och med hälften för tre.

Ris. 7

Även om, vad man än kan säga, är problemet inte bandbredden. Före optimering är den tredje versionen underlägsen den andra med cirka 20 procent. Optimering gör att du kan påskynda arbetet och till och med överträffa de två i viss utsträckning. Efter byte till gigabithastighet får den optimerade trippeln inga "bonusar", och de ooptimerade baserna och dubbeln fungerar snabbare. Skillnaderna mellan dem hålls minimala.

Men ändå, vad är anledningen till den långsamma driften av 1C? Låt oss titta vidare!

Diskundersystem servrar och SSD

Tidigare har vi redan ökat hastigheten på 1C, tack vare placeringen av databasen på SSD . Serverns diskundersystem visar ganska bra bra framträdande, detta bevisas av resultaten av dess mätningar under grupptestning i 2 baser. Låt oss inte vara ogrundade, titta på bilden nedan:

Ris. 8

Låt oss analysera resultaten: antalet I/O-operationer var 913 per tidsenhet (1 sekund). I det här fallet är kölängden inte mer än 1,84. Inte illa för en 2-diskarray, eller hur? Således är det logiskt att för att tio nätverksklienter ska fungera bra i alla lägen, är speglar gjorda av enkla diskar lämpliga.

Följande studie kommer att besvara frågan om behovet SSD på servern. Principerna för studien liknar de ovan anslutningen är i alla fall 1 Gbit/s. Alla resultat anges i relativa värden.

1. Databasladdningshastighet

Ris. 9

Märkligt nog beror inte laddningshastigheten för databasen på något sätt på SSD . Detta beror på nätverkets bandbreddsbegränsningar. Dessutom har prestanda en viss inverkan.

Ris. 10

Som nämnts är diskprestanda lämplig för normal drift (oavsett hur allvarlig regimen är). Detta avgör det SSD påverkar inte hastigheten. (undantag, icke-optimerad bas, som förbättrade sin prestanda och blev lika med den optimerade). Detta bekräftar återigen tesen att optimering hjälper till att minska antalet slumpmässiga I/O-operationer och ökar hastigheten för databasåtkomst.

3. Låt oss titta på vardagliga uppgifter:

Ris. elva

Basen utan optimering får återigen en fördel, medan de optimerade baserna SSD hade nästan ingen inverkan. Alltså att köpa eller inte köpa SSD - valet är ditt. Glöm dock inte att underhålla databaserna i tid och defragmentera partitionen med informationsdatabaserna.

Klientdiskundersystem SSD

Vi har redan genomfört konsekvensstudier SSD vid drifthastigheten 1C, som installeras lokalt. De slutsatser som dras är delvis tillämpliga på nätverksläget. Detta tyder på att 1C använder diskresurser för olika uppgifter (inklusive bakgrund och rutin). Titta på bilden, som visar hur 1C kommer åt diskresurser efter uppstart (varaktighet ca 40 sekunder).

Fig 12

SSD alltså kan öka hastigheten på vissa processer, men detta är inget universalmedel. Nätverksbandbredden begränsar fortfarande hastigheten. För att lösa standardproblem är en enkel ganska lämplig HDD

Den logiska slutsatsen är att de är långsamma HDDär inte den främsta orsaken till programavmattning.

Bagge

Här är ögonblicken som förtjänar särskild uppmärksamhet. Den tredje versionen kräver cirka 500 MB RAM, så om den totala mängden RAM är 1 GB kan detta vara för lite för att programmet ska fungera korrekt.

Efter att ha minskat minnet till 1 GB lanserade vi två informationsdatabaser.

Ris. 13

Det verkar som om situationen inte är kritisk, eftersom programmet har investerat i det tilldelade minnet. Men låt oss inte glömma att programmets behov av driftsdata inte har förändrats. De gick bara för att cache, byta osv. Det vill säga, outtagna data går från RAM till diskminne. Och skillnaden i hastigheten för att hämta dessa data är radikal.

Låt oss jämföra resultaten med att köra på 2 GB:

Ris. 14

Nätverket började användas aktivt för att hämta data, och processorn användes inte mindre aktivt för att behandla dessa data. Diskaktiviteten är minimal och saktar inte ner processer.

Vad händer efter att ha reducerat minnet till 1 GB?

Ris. 15

All last gick till hårddisken. Processorn och nätverket är inte inblandade, medan systemet först tar emot nödvändiga data från disken och sedan skickar de outtagna data dit.

Detta gör även subjektivt arbete med två öppna databaser långsamt och obehagligt. Till exempel tog det cirka tjugo sekunder att öppna tidningen Sales of Goods and Services. Diskaktiviteten (understruken med rött) var extremt hög.

Ris. 16

Vi bestämde oss för att uppnå tillräckligheten och objektiviteten för påverkan av RAM på prestanda genom att utföra tre mätningar:

Gruppåteruppförande i en av baserna

Båda databaserna är lika, skapade genom att kopiera den optimerade databasen. Här är resultatet:

Ris. 17

Laddningstiden ökar med 30 %, men tiden det tar att utföra operationer i databasen har tredubblats. Detta gör normal drift nästan omöjlig (i den här situationen kan du hjälpa till SSD , men det är enklare och mer ekonomiskt lönsamt att köpa mer RAM.

Slutsats: en liten mängd RAM är huvudproblemet som saktar ner 1C med nya konfigurationer. Minsta nödvändiga mängd RAM är 2 GB. Och detta tar inte hänsyn till att sannolikt inte bara 1C kommer att vara öppen på din dator, utan också många andra program som också kommer att "äta upp" värdefullt RAM.

CPU

För att bedöma processorns roll genomfördes ett antal mätningar, liknande de som utfördes för RAM. Mätningar utfördes för enkelkärniga och dubbelkärniga processorer med en minneskapacitet på 1 GB samt 2 GB.

Ris. 18

Den kraftfullare processorn, trots att den tog på sig en viss belastning när resurserna var knappa, skapade totalt sett inga märkbara fördelar. Detta beror på att 1C inte kräver stora processorresurser.

Slutsatser.

Huvudorsaken till den långsamma driften av 1C är bristen på RAM, på grund av vilken belastningen överförs till hårddisken och delvis till processorn.
Delvis påverkad av nätverkets prestanda. En 100-Mbit-kanal kan vara en allvarlig begränsande faktor för driften, men tunt klientläge kan balansera denna nackdel.
Att köpa en SSD – Lösningen är bra, men dyr. Det är billigare att byta ut skivan mot en modernare av samma typ.
En snabb processor är bra, men det är inte nödvändigt att snabba upp 1C.) Förutom när datorn används för "tunga" operationer.

Baserat på den forskning som utförts och de slutsatser som dragits kan du ganska effektivt lösa problemet med långsam 1C-hastighet för dig själv.

2. Funktioner i programmet. Ofta även med optimala inställningar 1C fungerar väldigt långsamt. Prestanda sjunker särskilt kraftigt när antalet samtidigt arbetar med databasen överstiger 4-5 användare.

Vem är du i företaget?

Lösningen på problemet med långsam 1C-drift beror på vem du är i företaget. Om du är en tekniker, läs bara vidare. Om du är styrelseledamot eller revisor, följ speciallänken ↓

Nätverksbandbredd

Som regel arbetar inte en utan flera användare med en informationsbas (IS). Samtidigt sker ett ständigt datautbyte mellan datorn som 1C-klienten är installerad på och datorn som informationssäkerheten finns på. Volymen av dessa data är ganska betydande. En situation uppstår ofta när ett lokalt nätverk som arbetar med en hastighet på 100 Mbit/s, vilket är den vanligaste hastigheten, helt enkelt inte klarar av belastningen. Och återigen klagar användaren över att programmet är långsamt.

Var och en av dessa faktorer individuellt minskar redan programmets hastighet avsevärt, men det mest obehagliga är att dessa saker vanligtvis går ihop.

Låt oss nu titta på flera lösningar på problemet med låg 1C-drifthastighet och deras kostnad, med hjälp av exemplet lokalt nätverk av 10 genomsnittliga datorer.

Lösning ett. Modernisering av infrastrukturen

Detta är kanske den mest uppenbara lösningen. Låt oss beräkna dess lägsta kostnad.

För varje dator behöver vi åtminstone en 2 GB RAM-sticka, som kostar i genomsnitt 1 500 rubel, ett nätverkskort som stöder en hastighet på 1 Gbit/s kostar cirka 700 rubel. Dessutom behöver du minst en router som stöder en hastighet på 1 Gbit/s, vilket kommer att kosta cirka 4 000 rubel. Total kostnad - 26 000 rubel för utrustning, exklusive arbete.

I princip kan hastigheten öka rejält, men köp nu till kontoret billiga datorer Det kommer inte att fungera längre. Förutom, detta beslut inte tillämpligt för dem som använder Wi-Fi eller vill arbeta via Internet - i deras fall kan nätverkshastigheten vara tiotals gånger lägre. Detta väcker frågan: "Är det möjligt att implementera hela programmet på en kraftfull server, så att användarens dator inte deltar i komplexa beräkningar, men tjänade bara till att överföra en bild?” Då kan du arbeta även på mycket svaga datorer, även på nätverk med låg bandbredd. Naturligtvis finns sådana lösningar.

Lösning två. Terminal Server

Fick stor popularitet redan under 1C 7:s dagar. Implementerad på servern Windows-versioner och klarar vår uppgift perfekt. Det har dock sina fallgropar, nämligen kostnaden för licenser.

Själva operativsystemet kommer att kosta cirka 40 000 rubel. Utöver detta kommer vi att behöva för alla som planerar att arbeta i 1C Windows-licens Server CAL, kostar cirka 1 700 rubel och en Windows Remote Desktop Services CAL-licens, som kostar cirka 5 900 rubel.

Efter att ha beräknat kostnaden för ett nätverk med 10 datorer, hamnar vi på 116 000 rubel. endast för en licens. Lägg till detta kostnaden för själva servern (minst 40 000 rubel) och kostnaden för implementeringsarbete, men även utan detta visade sig priset för licenser vara imponerande.

Lösning tre. Service 1C Enterprise

1C har utvecklat sin egen lösning på detta problem, vilket avsevärt kan öka programmets hastighet. Men det finns en nyans också här.

Faktum är att kostnaden för en sådan lösning varierar från 50 000 till 80 000 rubel, beroende på upplagan. För ett företag med upp till 15 användare visar det sig vara ganska dyrt. Stora förhoppningar sattes på "1C enterprise mini-server", som enligt 1C-företaget riktar sig till småföretag och kostar runt 10 000 - 15 000 rubel.

Men när den började säljas var denna produkt en stor besvikelse. Faktum är att högsta belopp Det fanns bara 5 användare som miniservern kunde användas med.

Som en 1C-programmerare skrev på forumet: "Det är fortfarande inte klart varför 1C valde exakt 5 anslutningar! Problemen börjar bara med 4 användare, men med fem slutar det hela. Om du vill ansluta en sjätte person, betala ytterligare 50 tusen. Vi skulle kunna göra minst 10 anslutningar...”

Naturligtvis hittade miniservern också sin konsument. För företag där 5 eller fler personer arbetar med 1C har dock ingen enkel och billig lösning dykt upp.

Utöver de programaccelerationsmetoder som beskrivs ovan, finns det ytterligare en som är idealisk för segmentet 5 - 15 användare, nämligen webbåtkomst för 1C i filläge.

Lösning fyra. Webbåtkomst för 1C i filläge

Funktionsprincipen är som följer: en ytterligare roll för en webbserver är installerad på datorn, på vilken informationssäkerhet publiceras.

Naturligtvis måste detta vara antingen det mesta kraftfull dator på nätverket, eller en separat maskin dedikerad till denna roll. Därefter kan du arbeta med 1C i webbserverläge. Alla tunga operationer kommer att utföras på serversidan, och trafik som överförs över nätverket kommer att minimeras, liksom belastningen på klientens dator.

Således kan även mycket svaga maskiner användas för att arbeta i 1C, och nätverkets bandbredd blir inte kritisk. Våra tester har visat att du bekvämt kan arbeta via mobilt internet på en billig surfplatta utan att uppleva obehag.

Det här alternativet är sämre än företagets 1C-server när det gäller driftshastighet, men denna skillnad är praktiskt taget osynlig upp till 15-20 användare. Förresten, för att implementera en webbserver kan du använda IIS (för Windows) och Apache (för Linux) och båda dessa lösningar är gratis!

Trots uppenbara fördelar, den här metoden optimering av 1C-drift har inte vunnit mycket popularitet.

Jag kan inte säga säkert, men troligen beror detta på två skäl:

En ganska svag beskrivning i den tekniska dokumentationen
Belägen i skärningspunkten mellan ansvar mellan systemadministratören och 1C-programmeraren

Vanligtvis, när en systemadministratör kontaktas med ett problem med låg hastighet, föreslår han att man uppgraderar infrastrukturen eller en terminalserver, om en 1C-specialist kontaktas, erbjuds han en 1C-företagsserver. Så om i ditt företag en specialist ansvarig för infrastruktur och en specialist ansvarig för 1C arbetar "hand i hand", så kan du säkert använda en lösning baserad på en webbserver.

Låt oss snabba upp 1C. På distans, snabbt och utan ditt deltagande

Vi vet hur man snabbar upp 1Ski utan att störa kunden. Vi fördjupar oss i problemet, gör vårt jobb och lämnar. Om du vill att programmet bara ska fungera normalt, kontakta oss. Vi kommer att hitta en lösning.

Lämna en förfrågan så får du gratis konsultation för att snabba upp programmet.

Av olika anledningar stöter användare av 1C-programmet då och då på 1C-prestandaproblem. Till exempel: ett dokument tar lång tid att bearbeta, en rapport tar lång tid att generera, transaktionsfel, programmet fryser, långsam respons på användaråtgärder, etc. Genom att följa våra instruktioner kan du uppnå betydande framgång i programmets prestanda och förhindra att systemgränsen överskrids. Detta är inte ett universalmedel för alla sjukdomar, men de flesta av orsakerna till 1C-nedgångar ligger just i dessa problem.

1. Utför inte rutin- eller bakgrundsuppgifter medan användare arbetar

Den första och huvudregeln för systemadministratörer är att se till att alla bakgrundsjobb utanför arbetstid. Systemet måste avlastas så mycket som möjligt för att utföra rutinuppgifter (indexering, dokumentbehandling, datauppladdning) och samtidigt inte störa användarnas arbete. Varken systemet eller användarna kommer att störa varandra om de arbetar vid olika tidpunkter.

2. Utbyta inte RIB-data under användarnas arbetstid

Även om nyligen företag har övergett RIB datautbyte systemet till förmån för online-läge och terminalåtkomst är det inte överflödigt att komma ihåg att när du laddar upp och laddar ner utbytesdata är det omöjligt att utföra dokument och arbeta fullt ut i programmet. Om möjligt bör denna procedur, om den finns, utföras på natten med bakgrundsjobb.

3. Öka datorns prestanda i tid, anpassa dess kraft till verkliga behov

Glöm inte att den samtidiga driften av 30 och 100 användare i systemet ger olika belastningar. Följaktligen, om en kvantitativ ökning av antalet användare planeras, bör IT-tjänsten omgående överväga med företagsledningen frågan om att utöka maskinparken, köpa ytterligare minne eller servrar.

4. Programvara som 1C körs på

1C-programmet är sådant att det fungerar annorlunda på operativsystem. Man vet inte exakt varför, men det är så. Till exempel är serverversionen av en 1C-databas på Linux OS i kombination med SQL Postgre mycket långsammare än samma 1C-databas på Windows OS i kombination med MS SQL. De exakta orsakerna till detta faktum är inte kända, men uppenbarligen någonstans djupt inne i 1C-plattformen finns det kompatibilitetsproblem med operativsystem och en icke-Microsoft DBMS. Det är också värt att distribuera systemet på en 64-bitars server om du planerar att lägga betydande belastningar på databasen.

5. Databasindexering

Intern procedur för 1C-programmet, som "kammar" systemet från insidan. Ställ in den så att den körs som en rutinuppgift i bakgrunden på natten och var lugn.

6. Inaktivera operativ batchredovisning

Faktum är att under den operativa behandlingen av dokument registreras rörelser i register, inklusive partibokföringsregister. Registrering av partibokföringsregister vid bokföring av dokument kan inaktiveras i programinställningarna. En gång i månaden kommer det att vara nödvändigt att börja behandla bokföringen av dokument i omgångar, till exempel vid en tidpunkt då belastningen på databasen är minst eller när minst antal användare arbetar.

7. RAM

Använd följande formel:

RAM = (DB 1+DB 2+DB N) / 100 * 70

Cirka 70 % av den totala fysiska volymen av databaser. 1C-baser älskar att äta gott Bagge. Glöm inte detta.

8. Om möjligt, optimera självskrivna rapporter och bearbetning med ofullkomliga och föråldrade koder

Under ett företags liv finns det ett behov av att skriva rapporter och bearbeta, samt modifieringar för att hantera affärsprocesser och extrahera specifik information. Det är alla dessa förbättringar som kan orsaka problem och sakta ner arbetet, eftersom... a) vissa Kulibins kan en gång ha skrivit tung, felaktig kod som är svår för programmet att köra och som kräver betydande ansträngning att exekvera. Använd regeln: Ju mindre vi ändrar något i programmet, desto bättre.

9. Rensa cache

En vanlig omstart av servern löser ibland problem med den föråldrade 1C-cachen. Bara prova det. Avlastning kan också hjälpa – ladda informationsbasen via konfiguratorn. Och den senaste rensningen av cachen för en specifik användare är att ta bort mappar i 1C-systemkatalogen i formuläret: kexifzghjuhfv8j33hbdgk0. Men att ta bort cachade användarmappar är det sista, eftersom... Förutom att ta bort skräp får rensningen av cachen obehagliga konsekvenser i form av att sparade rapportinställningar och användarmenygränssnittet raderas.

10. Minska den fysiska volymen av databaser

Mer bas betyder mer resurser. Naturligtvis. Utnyttja standardmedel 1C för databasfalsning. Tänk på möjligheten att ge upp fem års data för att förbättra produktiviteten. Och om du fortfarande behöver data från de senaste fem åren kan du alltid använda en kopia av databasen.

11. Korrekt organisation av arkitekturen

I allmänhet företagsarkitekturen informationssystem måste vara korrekt. Vad menar vi med rätt system? Jämförbarhet av de uppgifter som tilldelats systemet med tillgänglig utrustning och programvara. Planera systemet tillsammans med: systemadministratören (eftersom han kan maskinparken), 1C-programmeraren (eftersom han känner till resursbehoven hos 1C) och chefen för företaget (eftersom han vet om företagets framtida tillväxt eller sammandragning ).