Upp 8.3 började fungera långsamt. Automationstips. Använda SQL Server DMO-objekt

Användare klagar ofta över att "1C 8.3 är långsam": dokumentformulär öppnas långsamt, dokument tar lång tid att bearbeta, programmet startar, rapporter tar lång tid att generera, och så vidare.

Dessutom kan sådana "fel" uppstå i olika program:

Orsakerna kan vara olika. Detta är inte återställda dokument, en svag dator eller server, 1C-servern är felaktigt konfigurerad.

I den här artikeln vill jag titta på en av de enklaste och vanligaste anledningarna till ett långsamt program - . Denna instruktion kommer att vara relevant för användare av fildatabaser för 1-2 användare, där det inte råder konkurrens om resurser.

Om du är intresserad av mer seriös optimering av klient-serveralternativ för systemdrift, besök avsnittet på webbplatsen.

Var finns de schemalagda uppgifterna i 1C 8.3?

Innan jag hann ladda programmet körde 1C många bakgrundsjobb. Du kan se dem genom att gå till menyn "Administration" och sedan "Support och underhåll":

Få 267 videolektioner på 1C gratis:

Så här ser fönstret med slutförda uppgifter ut:

Och så full lista alla schemalagda uppgifter som startas:

Bland dessa uppgifter kan du se som "", ladda olika klassificerare, kontrollera relevansen av programversionen och så vidare. Jag har till exempel ingen användning för nästan alla dessa uppgifter. Jag för inte valutaregister, jag kontrollerar versionerna själv och laddar klassificerare efter behov.

Följaktligen ligger det i mitt (och i de flesta fall i ditt) intresse att inaktivera onödiga uppgifter.

Inaktivera schemalagda uppgifter och bakgrundsuppgifter i 1C 8.3

Patientsymtom och historia:

Flera användares arbete över nätverket med samma fil (databas) inkluderar en nätverksblockeringsmekanism. Detta tvingar systemet att slösa bort värdefull tid på att identifiera öppna inspelningssessioner och lösa konflikter därefter.

De viktigaste tecknen på blockering:

• snabbt användararbete med databasen över nätverket i exklusivt läge och extremt långsamt när flera användare arbetar samtidigt
• snabb användarupplevelse med en lokal databas på servern och långsamt arbete över nätverket
• tilltalar filsystem knappt 10 MB/sek

Så jag fick i uppdrag att se till att så många som tre användare kunde arbeta i 1C samtidigt! Roligt, inte sant?

Jag glömde alla skämt när jag såg vad jag hade att ta itu med: en "server" i form av en vanlig kontorsdator och två bärbara datorer.

Lycka skulle vara ofullständig om inte de underbara operativsystemen - på datorn och på en Windows bärbar dator 7, å andra sidan - Windows 8.

När man försökte lägga upp dokument samtidigt på bärbara datorer satt en fast i ungefär en minut och den andra kraschade ur 1C med feltexten "kunde inte låsa bordet...".

Att lansera 1C på en bärbar dator är en separat show som varade ungefär 3 minuter!

På många resurser fick jag råd om att byta till att arbeta med terminalåtkomst. Tyvärr tillåter inte Windows 7 regelbundna medel förvandlas till en terminalserver - högst en aktiv anslutning. I det här fallet avslutas inte de återstående sessionerna; du kan återansluta under en annan användare - "kasta ut" den tidigare användaren, men utan att avsluta hans session. Därför bör du överföra 1C till ett serveroperativsystem, där det inte finns några sådana begränsningar. Klienten, på egen risk, löste problemet med hjälp av ett tredjepartsverktyg istället Windows7_SP1_RDPhack.

Men äventyren slutade inte där. Även i terminalanslutningen var det betydande förseningar. Återigen hjälpte de allsmäktiga sökmotorerna mig. Nedan finns tips för att påskynda fil 1C, som jag följde:

1. Inaktivera användning av nätverksprotokoll IPv6, konfigurera adressering på den "gamla" IPv4.

2. Lägg till 1C-processer till undantagen för Windows-brandväggen, såväl som till antivirusundantagen, eller inaktivera dem helt (mer riskabelt, men ett enkelt test visade hastighetsökning lägga upp dokument på nytt när de är inaktiverade Avast antivirus faktor av!)

3. Börja indexera fulltextsökning i 1C eller stäng av den helt

4. Kör Testa och fixa databasen, kontrollera med ChDbfl-verktyget

5. Kör objektet Kontrollera konfiguration i konfigurationen (om konfigurationen inte är standard kan detta vara användbart). Baserat på resultaten av att kontrollera konfigurationen, minskade den magiskt i storlek med nästan en tredjedel. Jag fördjupade mig inte riktigt i exakt vad de inkommande programmerarna uppdaterade före mig, men faktum är uppenbart.

6. Inaktivera onödiga funktionsalternativ.

7. Ställ in användarrättigheter. (Detta och föregående råd verkade dumt tills jag såg teckningen kontrollerade former när du öppnar listan med dokument. Ju mindre onödiga saker i ett hanterat gränssnitt, desto snabbare fungerar det som regel)

8. Börja räkna om totalerna och återställa sekvensen (en betydande ökning kan bara ske om totalsummorna inte har återställts på länge)

9. Ange "Anslutningshastighet - låg" i databaslistans inställningar (detta gav inte så mycket resultat, förutom att bilderna på undersystemen var avstängda :))

Efter att ha slutfört alla dessa steg började 1C-fildatabasen att fungera mycket snabbare. Den började lanseras inom max 10 sekunder och hastigheten på dokumentöverföringen ökade i genomsnitt 12 gånger.

Kanske den här korta artikeln kommer att vara användbar för dig om du plötsligt behöver snabba upp din 1C-fildatabas.

P.S: Men att starta en fil 1C med nätverksåtkomst till en delad mapp är fortfarande orealistiskt, eftersom... Dasha är snabbast solid state-enhet, RAM och processor kommer att fastna i nätverkslås, och arbetet för mer än en användare kommer att vara praktiskt taget omöjligt. Det handlar om specifikt om konfigurationen av UT 11.1. Självskrivna små konfigurationer kan fungera ganska snabbt även i filversionen.

Tillägg från kommentarer för publicering:

Diskdefragmenteraren med filbas

Veck databas (kan vara användbar om databasen är stor, till exempel under flera år). Kundens databas var ganska ung, så minskning var opraktisk.

Hårdvaruuppgradering - snabbare hårddisk, ny switch, processor, etc.

Installera på webbserver, åtkomst med en tunn klient. Här är meningarna delade. Vissa säger att det är många gånger snabbare, andra säger att det inte finns någon acceleration noterad.

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 webbplats gav ganska tydliga rekommendationer, men jag ska bara ge några resultat och kommentera det mesta troliga fel. Naturligtvis kan testresultaten på din utrustning skilja sig, 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?

Initial 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 specifikt tog var inte den nyaste, men modern utrustning resultaten är 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. Vi ansluter från klientdatorn och 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å genvägen 1C:Enterprise till att databasfönstret visas bör gå mindre än en minut. ( Celeron = långsam).

Om du har en dator som är sämre än en Pentium 775 uttag med 1 GB random access minne, 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å att antingen uppgradera (det är hög tid) eller byta till en terminal (eller webb, i fallet med 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(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, för normal drift Ledigt minne bör vara 300-400 MB.

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 testet, 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 "avancerade" BIOS, om du inte har hittat detta 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 så mycket ni vill, men om slutanvändare behöver snabbhet måste ni aktivera högprestandaläge.

c) Turbo Boost. Först måste du förstå om din processor till exempel stöder denna funktion. Om det stöder 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-tillståndet är påslaget. Och vi får något sånt här:

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

	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, turboboost				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. I vilket fall 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. 1C 8.2.19.83, för filversionen 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 operationstestet kommer 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ällningarna för Windows fungerar klienten bäst med en Windows-server (eller till och med windows fungerar station) och SMB/CIFS-protokollet, fungerar linuxklienten (debian, ubuntu tittade inte på de andra) bättre med linux och NFS (den fungerar också med SMB, men papegojorna är högre på NFS). 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. Initiala 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 adaptern Intel 362. Det var 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 är korrekt inmatad i 1C. Även den första Core i3 kan enkelt producera 40+ papegojor, vilket är ganska bra, och det här är inte bara papegojor, i verkligt arbete märks skillnaden också. 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. Grundinställningar – se Gilev, men tänk på att allt går att 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, jag har inte letat efter den exakta versionen ännu) ä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) endast ett fåtal gånger, jag kunde inte upprepa det för ett mer allmänt fall. Jag förstod inte så mycket, men att döma av fotlindningarna från Process Explorer är inspelningen där inte lika bra som i 8.3.6.

Trots det faktum att när du arbetar på ett 100 Mbit-nätverk är dess belastningsschema litet (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 inte ge några rekommendationer än använder windows och NFS-protokoll.

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 uppenbara svaga punkter, såsom brist på minne eller en enorm 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å kan du tydligt se "Active disk operation time (in%)" 80-95. Ja, om du aktiverar cachen för själva diskarna för inspelning kommer hastigheten att öka till 35, om du aktiverar cachen för raidcontrollern - upp till 49 (oavsett vilka diskar som testas i det här ögonblicket). Men det här ä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, det förstår jag när jag testar SSD-enhet Jag testar också cachen på denna disk i större utsträckning, de verkliga resultaten blir mindre.

Den mest korrekta (ur min synvinkel) lösningen skulle vara att allokera 2 SSD-diskar i en speglad raid för en fildatabas (eller flera fildatabaser), och inte placera 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 terminalserver kör Gilev-testet (från samma disk där arbetsdatabaserna finns) och i de ögonblick då arbetsdatabasen saktar ner, och Gilev-testet visar ett bra resultat (över 30) - då är det mest troligt att programmeraren får skulden för långsam drift av den huvudsakliga arbetsdatabasen.

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 serveralternativ och nätverk 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-enheter, 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 mycket sämre fungerar kombinationen av 1C och SQL i virtuell maskin- ämnet för 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.

Mycket ofta kommer människor till oss med frågor som:

• Varför saktar 1C-servern ner?
• 1C-datorn är väldigt långsam
• 1C-klienten är fruktansvärt långsam

Ibland, som en lösning på problemet, erbjuder vi kunderna en server för 1C att hyra utan bromsar, med val av serverkonfiguration och operativsystem kan du konfigurera servern online på vår partners webbplats, med hjälp av länken https://1cloud.ru kapitel Tjänster, kapitel Virtuell server.

Vad man ska göra och hur man övervinner det, och så vidare i ordning:

Klienter arbetar väldigt långsamt med serverversionen av 1C

Utöver det långsamma arbetet med 1C, finns det också långsamt arbete med nätverksfiler. Problemet uppstår under normal drift och med RDP

för att lösa detta startar jag alltid efter varje installation av Seven eller 2008 års server

netsh int tcp set global autotuning=inaktiverad

netsh int tcp set global autotuninglevel=inaktiverad

netsh int tcp set global rss=inaktiverad skorsten=inaktiverad

och nätverket fungerar utan problem

ibland är det bästa alternativet:

netsh-gränssnitt tcp set global autotuning= HighlyRestricted

så här ser installationen ut

Konfigurera Anti-Virus eller Windows brandvägg

Hur man konfigurerar en antivirus- eller Windows-brandvägg för att köra en 1C-server (till exempel en kombination av 1C Server: Enterprise och MS SQL 2008).

Lägg till regler:

• Om SQL-servern accepterar anslutningar på standard TCP-port 1433, tillåter vi det.
• Om SQL-porten är dynamisk måste anslutningar till %ProgramFiles%\-applikationen tillåtas Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
• Server 1C körs på portar 1541, kluster 1540 och intervall 1560-1591. Av helt mystiska skäl tillåter ibland en sådan lista med öppna portar fortfarande inte anslutningar till servern. För att säkerställa att det fungerar, tillåt intervallet 1540-1591.

Inställning av server/datorprestanda

För att din dator ska fungera med maximal prestanda måste du konfigurera den för detta:

1. BIOS-inställningar

• I serverns BIOS inaktiverar vi alla inställningar för att spara processorkraft.
• Om det finns "C1E" & se till att KOPPLA ifrån!!
• För vissa inte särskilt parallella uppgifter rekommenderas det också att stänga av hypertrading i BIOS
• I vissa fall (särskilt för HP!) behöver du gå in i serverns BIOS och stänga AV de objekt där som har EIST, Intel SpeedStep och C1E i sina namn.
• Istället måste du hitta föremål relaterade till processorn där som har Turbo Boost i sina namn, och AKTIVERA dem.
• Om det finns en allmän indikation på ett energisparläge i BIOS och slå på det maximal prestanda(det kan också kallas "aggressivt")

2. Schemainställningar i operativsystemet - Hög prestanda

Servrar med Intel Sandy Bridge-arkitektur kan dynamiskt ändra processorfrekvenser.

Ibland är lösningen på problemet med långsam drift av en 1C-server föråldrad eller trasig utrustning, i det här fallet erbjuder vi kunderna en server för 1C att hyra utan bromsar, med val av serverkonfiguration och operativsystem, du kan göra det på vår partners webbplats, på länken https://1cloud.ru Tjänster, virtuell server.

Om du har några frågor vänligen kontakta:

• ring +7-812-385-55-66 i St. Petersburg
• skriv till adressen
• lämna en ansökan på vår hemsida på sidan "Online ansökan".

2. Funktioner i programmet. Ofta, även med optimala inställningar, fungerar 1C 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 direktör eller revisor, följ den speciella länken ↓

Nätverksbandbredd

Som regel med en informationsbas(IB) det finns inte en, utan flera användare som arbetar. 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-minne, som kostar i genomsnitt 1 500 rubel, LAN-kort med stöd för hastighet 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, nu går det inte längre att köpa billiga datorer till kontoret. 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älv operativ system 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 en egen lösning på detta problem, vilket avsevärt kan öka programmets hastighet. Men det finns en nyans även 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 det maximala antalet användare med vilka miniservern kunde användas var endast 5.

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. Men för företag där 5 eller fler personer arbetar med 1C har det inte dykt upp någon enkel och billig lösning.

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 bör detta antingen vara den kraftfullaste datorn i 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 genomströmning nätverket blir inte längre kritiskt. Våra tester har visat att du kan arbeta bekvämt igenom Mobilt internet på en billig surfplatta utan att uppleva något 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 de uppenbara fördelarna, 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
• Ligger vid ansvarspunkten systemadministratör och 1C-programmerare

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 och få en kostnadsfri konsultation om att påskynda programmet.