Ofta körs andra tjänster på maskinen tillsammans med 1C:Enterprise-servern - en terminalserver, SQL-server, etc. Och någon gång äter 1C:Enterprise-servern, eller snarare rphost-arbetarprocessen, upp mer minne än planerat eller allt minne. Vilket leder till en avmattning av andra tjänster och zombies på servern. För att undvika sådana situationer måste du konfigurera automatisk omstart av 1C:Enterprise-serverarbetsflöden

Lösning

1. Öppna administrationskonsolen för 1C Enterprise-servrar;
2. Expandera det centrala serverträdet till kluster och välj det kluster som intresserar oss. I exemplet finns det bara ett kluster;
3. Öppna egenskaperna för det valda klustret och se följande formulär

Egenskaper för 1C:Enterprise 8.3-serverklustret

Låt oss titta på exemplet som visas i bilden:

Omstartintervall— tid efter vilken rphost-processen kommer att tvingas starta om. Innan processen avslutas startas en ny rphost-process, till vilken alla anslutningar överförs, och först då kommer den gamla processen att avslutas. Detta kommer inte att påverka användarens upplevelse på något sätt. Intervallet anges i sekunder, i exemplet anges 24 timmar.

Tillåten minnesstorlek— mängden minne inom vilket arbetsflödet kan fungera utan problem. Volymen anges i kilobyte, i exemplet är värdet 20 gigabyte (i själva verket är siffran för stor och du måste börja från det specifika systemet, men den genomsnittliga siffran är 4 GB). Så snart minnet som upptas av arbetsprocessen överskrider det angivna värdet, börjar nedräkningen.

Intervall för att överskrida den tillåtna mängden minne— efter att timern som startats efter att ha överskridit den tillåtna mängden minne räknat ned den angivna tiden, kommer en ny arbetsprocess att startas, till vilken alla anslutningar överförs, den gamla processen markeras som inaktiverad. Intervallet anges i sekunder, i exemplet anges 30 sekunder.

Stoppa inaktiverade processer efter— den tid efter vilken arbetsflödet som markerats som inaktiverat kommer att stoppas om värdet är 0, kommer processen inte att slutföras. Intervallet anges i sekunder, i exemplet anges 60 sekunder.

Efter att ha tillämpat inställningarna behöver du inte starta om servertjänsten de tillämpas dynamiskt.

Total

Så här ställer vi in ​​automatisk omstart av 1C:Enterprise-serverns arbetsprocesser och får ett mer stabilt system om en minnesläcka uppstår, kommer arbetet i en specifik session att avslutas.

I vissa situationer kan du också leka med inställningarna och förhindra en eventuell serverkrasch om du gör misstag.

SÅ VAD HAR ÄNDRAT I KLUSTER 1C 8.3:

Först och främst, efter att ha installerat 1C-klustret, var det nödvändigt att skapa arbetsflöden. Som det visade sig,klusterprocesserbörjade skapas automatiskt beroende på databasens belastning.

En provkörning av bakgrundsjobb i huvuddatabasen fick 1C-klustret att oändligt överbelasta rphost.exe och den extra rphost.exe ville inte skapas. Efter att ha grävt igenom inställningarna blev allt klart.

Maximalt arbetsflödesminne är mängden minne som arbetsprocesser kan använda tillsammans. Du måste vara mycket försiktig när du ställer in parametern, mätt i bytes. Om du ställer in fel värde (otillräckligt för normal användardrift) användare ett fel kommer att visas"Det finns inte tillräckligt med ledigt minne på 1C-servern". Du kan också få det här felet när minneskvoten på 1C-servern har tagit slut.

Säker minnesförbrukning per samtal- låter dig kontrollera minnesförbrukningen under ett serversamtal, mätt i bytes. Om ett anrop använder mer minne än förväntat, kommer detta anrop att slutföras inom 1C-klustret utan att starta om arbetsprocessen (rphost.exe). Följaktligen kommer "förloraren" som gjorde serveranropet att förlora sin session med 1C-databasen utan att påverka andra användares arbete.

Mängden arbetsprocessminne upp till som servern anses vara produktiv- kl Om denna parameter överskrids kommer servern i 1C-klustret att sluta acceptera nya anslutningar.

Antal informationssäkerheter per process- låter dig isolera informationsbaser för arbetsprocesser. Som standard var det aktuella 1C-klustret inställt på- "8", men under flera timmars drift blev servern mycket instabil, användarsessioner frös. Efter att ha isolerat varje infobas (värde- "1") problemen försvann.

Antal anslutningar per process- Standardvärdet är "128". Eftersom den nuvarande databasen har en mycket stor belastning av bakgrundsuppgifter (logistikberäkningar, prislistasanalyser, konkurrentanalyser etc.) beslutades att minska antalet till ”25”.

Inställningarna för själva 1C-klustret har ändrats något:

Feltoleransnivå- Det här antalet fungerande servrar som kan misslyckas samtidigt utan att få användare att krascha. Säkerhetskopieringstjänster startas automatiskt i den mängd som krävs för att säkerställa den specificerade feltoleransen. I realtid replikeras den aktiva tjänsten till de säkerhetskopierade.

Ladda delningsläge - det finns två alternativ för parametern: "Priority by performance" - mer serverminne spenderas och prestandan är högre, "Priority by memory" - 1C-klustret sparar serverminne.

Istället för ett efterord. 1C 8.3-klustret fungerar märkbart snabbare och mer tillförlitligt, att skapa en användarsession med infobasen är många gånger snabbare, gränssnittet i kompatibilitetsläge med 1C 8.2.16 kan sägas flyga. Visst finns det nyanser, men var skulle vi vara utan dem? Lycka till med att installera det nya 1C 8.3-klustret.

05.04.2017 |

Kluster 1C 8.3

Först och främst, efter att ha installerat 1C-klustret, var det nödvändigt att skapa arbetsflöden. Som det visade sig började klusterprocesser skapas automatiskt beroende på belastningen på databasen.

En provkörning av bakgrundsjobb i huvuddatabasen fick 1C-klustret att oändligt överbelasta rphost.exe och den extra rphost.exe ville inte skapas. Efter att ha grävt igenom inställningarna blev allt klart.

Maximalt arbetsflödesminneär mängden minne som arbetsprocesser kan använda tillsammans. Du måste vara mycket försiktig när du ställer in parametern, mätt i byte. Om du ställer in fel värde (otillräckligt för normal användardrift) kommer användarna att få felmeddelandet "Inte tillräckligt med ledigt minne på 1C-servern." Du kan också få detta fel när minneskvoten på 1C-servern har tagit slut.

Säker minnesförbrukning per samtal- låter dig kontrollera minnesförbrukningen under ett serversamtal, mätt i byte. Om ett anrop använder mer minne än förväntat, kommer detta anrop att slutföras inom 1C-klustret utan att starta om arbetsprocessen (rphost.exe). Följaktligen kommer "förloraren" som gjorde serveranropet att förlora sin session med 1C-databasen utan att påverka andra användares arbete.

i en GB - 1073741824 byte, därför i 2 GB - 2147483648 byte

Mängden minne för arbetsprocesser upp till som servern anses vara produktiv - om denna parameter överskrids kommer servern i 1C-klustret att sluta acceptera nya anslutningar.

Antal informationssäkerheter per process- låter dig isolera informationsbaser för arbetsprocesser. Som standard var det nuvarande 1C-klustret satt till "8", men under flera timmars drift blev servern mycket instabil, användarsessioner frös. Efter att ha isolerat varje infobas (värde - "1") försvann problemen.

Antal anslutningar per process- Standardvärdet är "128". Eftersom den nuvarande databasen har en mycket stor belastning av bakgrundsuppgifter (logistikberäkningar, prislistasanalyser, konkurrentanalyser etc.) beslutades att minska antalet till ”25”.

Inställningarna för själva 1C-klustret har ändrats något:

Feltoleransnivå- det här är antalet fungerande servrar som kan misslyckas samtidigt utan att få användare att krascha. Säkerhetskopieringstjänster startas automatiskt i den mängd som krävs för att säkerställa den specificerade feltoleransen. I realtid replikeras den aktiva tjänsten till de säkerhetskopierade.

Ladda delningsläge- det finns två alternativ för parametern: "Priority by performance" - mer serverminne spenderas och prestandan är högre, "Priority by memory" - 1C-klustret sparar serverminne.

Server 8.3 kännetecknas av en nyligen omdesignad intern kod, även om det "från utsidan" kan tyckas att det är en något modifierad 8.2.

Servern har blivit mer "automatisk konfigurerbar" vissa parametrar, såsom antalet arbetsprocesser, skapas inte längre manuellt, utan beräknas utifrån beskrivningarna av kraven på feltolerans och tillförlitlighetsuppgifter.

Detta minskar sannolikheten för felkonfiguration av servern och sänker kvalifikationskraven för administratörer.

En lastbalanseringsmekanism har utvecklats, som kan användas antingen för att öka systemets prestanda som helhet eller för att använda ett nytt "minnessparande" läge, som låter dig arbeta "med begränsat minne" i de fall där konfigurationen använde "gillar att äta upp minnet."

Driftstabilitet vid användning av stora mängder minne kommer att bestämmas av de nya parametrarna för produktionsservern.

Parametern "säker minnesförbrukning per samtal" är särskilt intressant. För dem som inte har en aning om vad det är, är det bättre att inte träna på en "produktiv" basis. Parametern "Maximal minnesstorlek för arbetsprocesser" tillåter, i händelse av "overflow", att inte krascha hela arbetsprocessen, utan bara en session "med förloraren". "Mängden minne för arbetsprocesser upp till som servern anses vara produktiv" låter dig blockera nya anslutningar så snart denna minneströskel överskrids.

Jag rekommenderar att man isolerar arbetsprocesser efter informationsbas, till exempel genom att specificera parametern ”Antal informationssäkerhet per process = 1”. Med flera högt belastade databaser kommer detta att minska ömsesidigt inflytande både vad gäller tillförlitlighet och prestanda.

Ett separat bidrag till systemets stabilitet görs genom "utgifter" för licenser/nycklar. I 8.3 blev det möjligt att använda en "programvarulicenshanterare", som påminner om "aladin"-hanteraren. Målet är att kunna placera nyckeln på en separat maskin.

Den implementeras som ytterligare en "tjänst" i klusterhanteraren. Du kan till exempel använda en "gratis" bärbar dator. Lägg till det i 1C 8.3-klustret, skapa en separat hanterare på det med tjänsten "licenstjänst". Du kan sätta in en hasp-nyckel för hårdvara i din bärbara dator eller aktivera mjukvarulicenser.

Av störst intresse för programmerare bör "Functional Assignment Requirements" vara.

Krav för den tilldelade funktionaliteten i 1c

Så på en bärbar dator med säkerhetsnyckel, för att inte starta användare på klusterservern, måste du lägga till "krav" för kravobjektet "Klientanslutning till informationssäkerhet" - "Tilldela inte", d.v.s. förhindra att arbetsprocesser på denna server bearbetar klientanslutningar.

Ännu mer intressant är möjligheten att köra "bara bakgrundsjobb" på klustrets produktionsserver utan användarsessioner. På så sätt kan högt belastade uppgifter (kod) överföras till en separat maskin. Dessutom kan du köra en bakgrundsuppgift att "stänga månaden" med "Värde av en extra parameter" på en dator, och bakgrundsuppgiften "Uppdatering av fulltextindex" på en annan sker genom indikeringen "Värde av en extra parameter”. Om du till exempel anger BackgroundJob.CommonModule som ett värde, kan du begränsa arbetet för arbetarservern i klustret till enbart bakgrundsjobb med något innehåll. BackgroundJob.CommonModule värde.<Имя модуля>.<Имя метода>- kommer att ange en specifik kod.

Kluster 1C 8.2

Sessioner möjliggör lastbalansering och feltolerans inom en hanterad applikation.

Klusterchefen har nu blivit mer komplex. Vissa funktioner kan nu separeras i en separat process och till och med placeras på en annan fungerande server i klustret. Detta låter dig balansera serverbelastningen.

Server 8.2-feltolerans uppnås genom:

• Lagra information om användarens session.
• Användaren är inte längre bunden till arbetsflödet.
• Reservation av arbetsprocesser i ett kluster.
• Det bör finnas flera arbetsprocesser, inklusive redundanta
• Klusterreservation.

Ett reservkluster indikeras när de är anslutna, de är listade i anslutningsraden

Detta gör att du kan säkerställa kontinuitet i arbetet!

Om klientens fysiska anslutning till klustret är bruten (städerskan drog ut kabeln, strömmen till nätverksutrustningen stängdes av, det var ett problem med leverantören), behöver du inte återansluta till infobasen och starta alla arbetet om igen. Efter att den fysiska anslutningen har återställts kan användaren fortsätta arbeta från den punkt där den avbröts.

Om underhåll av klusterdatorer krävs kan de stängas av under drift utan att hindra användare från att arbeta med informationsbasen.

Om någon server i klustret misslyckas kommer användararbetet inte att stoppas automatiskt till backupklustret och/eller backup-arbetsprocesserna. För användare kommer en sådan övergång att vara osynlig.

Om en av klustrets arbetsprocesser misslyckas, kommer användare som är anslutna till det automatiskt att överföras till andra eller backup-arbetsprocesser. En sådan övergång kommer också att vara osynlig för användarna.

Skriv ut (Ctrl+P)

I den här artikeln granskar jag de viktigaste aktiviteterna som måste utföras för att öka 1C-prestandan i klient-serverversionen av 1C:

1. Ökning av hårdvarukapacitet.
2. Konfigurera en 1C:Enterprise-server
3. Konfigurera SQL-server
4. Optimering av kod och algoritmer i 1C.

1. Ökning av hårdvarukapacitet

Minimikrav för datorer som skickas in för certifiering till företag "C" för att få "Compatible! 1C:Enterprise software system" skrivet

1C-serverprestanda: ett företag är ganska beroende av processorfrekvensen, och för en databasserver måste datorns egenskaper uppfylla kraven för Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Konfigurera 1C:Enterprise-servern

Instruktioner för att ställa in fungerande servrar med 1C:Enterprise Technology Platform finns på ITS-disken

I version 8.3 lades flera nya parametrar till för att konfigurera produktionsservrar:

• Maximalt arbetsflödesminne. Inställningen låter dig reglera mängden minne som kan upptas av alla arbetsprocesser i ett givet kluster på en given fungerande server.
• Säker minnesförbrukning per samtal. Inställningen låter dig begränsa mängden minne som kommer att vara upptaget när du gör ett serveranrop på en viss fungerande server.
• Antal informationssäkerhet per process och antal anslutningar per process. Dessa inställningar låter dig indirekt reglera antalet arbetsprocesser på en given fungerande server.
• Chef för varje tjänst. Konfigurationen låter dig köra varje klusterhanterartjänst som en separat process.

3. Konfigurera SQL-server

Funktioner för att ställa in Microsoft SQL Server för att öka prestanda kan ses på ITS-disken

Med hjälp av underhållsplanen i avsnittet Hantering måste du utföra följande rutinuppgifter för att förbättra produktiviteten:

• Defragmentering av index och uppdatering av statistik måste göras dagligen, eftersom om indexfragmenteringen är > 25 %, minskar det dramatiskt serverns prestanda.
• Defragmentering och uppdatering av statistik görs snabbt och kräver inte att användare kopplas bort. Det rekommenderas också att göra det dagligen.
• Fullständig omindexering – görs med databasen blockerad, det rekommenderas att göra det minst en gång i veckan. Naturligtvis, efter fullständig omindexering, defragmenteras indexen omedelbart och statistiken uppdateras.

3.1 Analys av graden av indexfragmentering

Överdriven indexfragmentering skapar problem för stora I/O-operationer. Efter att ha utfört intensiva operationer för att modifiera data i databastabeller, ökar exekveringstiden för frågor och datamodifieringsoperationer.

Detta beror på det faktum att sådana operationer modifierar indexen, vilket leder till deras fragmentering och en ökning av antalet I/O-operationer vid användning av index under dataläs- och skrivoperationer.

För effektiv användning av index Microsoft SQL Server krävs

• Indexera regelbundet databastabeller med kommandot DBCC DBREINDEX ( tabellnamn ) .
• Defragmentera regelbundet databasindex med kommandot DBCC INDEXDEFRAG (databasnamn, tabellnamn, index_name) .

Valet av hur man löser detta problem beror på intensiteten av operationer för att modifiera databastabeller.

MS SQL Server 2005 har nya verktyg för att styra denna parameter.

Dynamisk styrbordsfunktion sys.dm_db_index_physical_stats returnerar procentandelen fragmentering i en kolumn avg_fragmentation_in_percent. Om värdet i den här kolumnen är större än 25 % rekommenderar vi att du defragmenterar det här indexet för att återställa den ursprungliga prestandan. Stora skanningsoperationer som är vanliga i datalagrings- och rapporteringsapplikationer kan dra fördel av minskad indexfragmentering.

Att använda denna information kan avsevärt minska systembelastningen och undvika onödiga defragmenteringsoperationer för index som inte kräver det.

3.2 Fysisk minnesanvändning större än 2 GB i Microsoft SQL Server

Microsoft SQL Server 2000 Standard Edition och Microsoft SQL Server 2005 Workgroup Edition kan använda upp till 2 GB fysiskt minne, som är dynamiskt allokerat och frigjort beroende på arbetsbelastningen. När databasstorleken ökar, blir denna mängd RAM otillräcklig för att effektivt cachelagra data och bibehålla acceptabel prestanda.

3.3 Minska storleken på Microsoft SQL Server-transaktionsloggen

Att utföra intensiva operationer för att modifiera infobasdata leder till en ökning av storleken på datafiler och transaktionsloggen. Vid någon tidpunkt behövs inte längre gamla transaktionsloggposter för att återställa databasen och kan raderas, vilket frigör utrymme för nya poster. Om du inte omedelbart tar bort gamla transaktionsloggposter kan transaktionsloggfilen efter en tid ta upp allt ledigt diskutrymme och det blir omöjligt att arbeta med databasen.

För att minska storleken på loggfilen måste du först ta bort inaktiva transaktionsloggposter med kommandot BACKUP LOGG och sedan använda kommandot DBCC SHRINKFILE minska storleken på transaktionsloggfilen Sekvensen av kommandon som ska köras Frågeanalysator, ser ut så här:

BACKUP LOGG Databas_Name MED TRUNCATE_ONLY

DBCC SHRINKFILE(Transaction_Log_File_Name)

3.4 Flytta TEMPDB-databasen till en annan större disk.

TEMPDB är en Microsoft SQL Server-systemdatabas som lagrar temporära tabeller skapade både av servern själv och av användare. Denna databas återskapas varje gång Microsoft SQL Server startas om. Som standard är storleken på denna databas obegränsad och den utökas automatiskt, om nödvändigt, i delar av 10 % av den aktuella TEMPDB-storleken. Dessa parametrar kan dock åsidosättas av användaren. Som standard bestäms minimistorleken för denna databas, som ställs in när Microsoft SQL Server startar, av storleken på MODELL-systemdatabasen. Rensning av transaktionsloggar i denna databas sker automatiskt och tar bara bort inaktiva transaktionsloggposter.

När du kör 1C:Enterprise 8 i klient-serverläge används temporära tabeller i stor utsträckning . Dessutom används TEMPDB av Microsoft SQL Server vid exekvering av frågor som använder satserna GRUPP EFTER, UNION, DISTINKT etc.

Under driften av 1C:Enterprise 8 är en betydande ökning av storleken på TEMPDB-databasen möjlig. Om storleken på disken som TEMPDB-databasen finns på är otillräcklig kan 1C:Enterprise 8 krascha.

Om det här problemet uppstår regelbundet, rekommenderas det att flytta TEMPDB till en annan större disk.

Denna operation kan utföras på följande sätt:

1. bestäm de logiska namnen på TEMPDB-databasfilerna (kolumnen "NAME" i procedurresultatet). För att göra detta måste du köra följande kommando i Query Analyzer:

ANVÄND tempdb GO EXEC sp_helpfile GO 2. ändra platsen för TEMPDB-databasfilerna med kommandot ÄNDRA DATABAS. För att göra detta måste du köra följande kommandosekvens i Query Analyzer: USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev,FILNAMN= "New_Disk:\New_Directory\tempdb.mdf") GÅ ÄNDRA DATABAS tempdb MODIFIERA FIL (NAMN = templog,FILNAMN= "New_Disk:\New_Directory\templog.ldf") GÅ 3. Starta om Microsoft SQL Server.

4. Optimering av kod och algoritmer i 1C

4.1 Frågeoptimering

En betydande del av problemen som gör att frågor fungerar suboptimalt kan upptäckas genom att analysera konfigurationskoden och metadatastrukturen. Det finns en lista över typiska fel i kod och datastruktur, vars konsekvenser är ganska väl studerade och lätt förutsägbara. Kodanalys med hjälp av denna checklista låter dig lösa de flesta frågeprestandaproblem utan att fördjupa dig i detaljerad teknisk information (SQL-frågetext, frågeplan, etc.).

De främsta orsakerna till icke-optimal frågeprestanda, diagnostiserad på nivån för konfigurationskod och metadatastruktur, diskuteras på ITS-disken:

• ansluter till underfrågor
• anslutningar till virtuella tabeller
• oöverensstämmelse mellan index och frågevillkor
• använder logiskt ELLER under förhållanden
• använda underfrågor i ett kopplingsvillkor
• ta emot data via en punkt från fält av sammansatt typ
• filtrering av virtuella tabeller utan att använda parametrar

4.2 Använda prestandamätning

1C:Enterprise 8 låter dig felsöka och mäta prestanda för kod i det inbyggda språket, exekveras på både klienten och servern. En speciell egenskap med prestandamätning för en klient-server infobas i 1C:Enterprise 8 är att resultatmätningsresultaten kombineras till en fil. De inkluderar data om exekveringsförloppet för kod i det inbäddade språket på både klienten och servern. För att få en sådan mätning räcker det att starta 1C:Enterprise 8-servern i felsökningsläge (med hjälp av kommandoradsomkopplaren /debug) och i konfiguratorn, vid rätt tidpunkt, slå helt enkelt på prestandamätningsläget.

Prestandamätningsläget i 1C:Enterprise 8 tillåter dig att framgångsrikt optimera driften av klient-serverapplikationer. För att utföra en sådan optimering räcker det att utföra bara några få steg, sedan analysera resultaten av prestandamätningar och gå vidare till att förbättra koden i det inbyggda språket.

Mer information om hur du använder prestandamätningar finns på ITS-disken.

Innan du påbörjar systemoptimeringsarbetet bör du alltid skaffa en första prestandabedömning med hjälp av "APDEX Integrated System Performance Assessment".

4.3 Verktyg för kodrefaktorering

Kodrefaktoreringsfunktioner implementerade i 8.3.5, 1068-plattformskonfiguratorn, samt funktioner för automatisk konvertering av modala metoder och kodsektioner visas i figur 1.

Fig 1 Koda refactoring-verktyg i konfiguratorn

Plattformsutvecklarna förklarar behovet av dessa verktyg med att koden för applikationslösningar måste vara begriplig, speciellt när en grupp med flera utvecklare arbetar med konfigurationen. Då är programkoden lätt att underhålla och modifiera.

Segern var inte lätt...
Jag ska försöka beskriva allt i detalj, även om det har gått ganska mycket tid. Jag hoppas att informationen jag samlat in kommer att hjälpa systemadministratörer och ge mig något att tänka på.
Jag flyttade databaserna till 1 skola och tilldelade om användaren för 8.3-agenten - det hjälpte inte...

Jag reste längs med vårt RuNet och hittade två intressanta artiklar som jag föreslår att du också läser.

För första gången ett ganska detaljerat test mellan två plattformar: PS-mellanversionen och dual-core-servern. Det kommer fram ganska intressanta punkter som jag lyfte fram när jag arbetade i andra företag.
efsol.ru/articles/tuning-1c.html

Det andra gäller 1c-tester på virtuella maskiner. Det var här jag såg orsaken till förseningen i att starta konfigurationen:
efsol.ru/articles/performance-comparison-1c.html

Efter att ha grävt runt i ungefär en vecka och provat flera metoder kunde jag inte lösa problemet med den första lanseringen. Men jag märkte ett intressant mönster... När den tunna klienten körs sker den andra starten av systemet nästan omedelbart. Jag ändrade inställningarna för antalet informationssäkerhetssystem per process: 8 (baserat på 8.3 hittills 5). Som ett resultat, eftersom servern slutade slösa tid på att skapa RPHOST när den gick in på spåret. han ägnade basen och resten bara åt att lossa konferensen från gnäll. Minskade starttiden för andra basen med 10-7 sekunder.

I princip passar det här alternativet mig helt med tanke på att 7-10 användare arbetar med varje databas, conf underhålls ständigt i RPHOSTe och inloggningstiden är 4-8 sekunder med autentisering tillsammans.

Om du har problem med att databasen inte öppnas ofta, så som ett alternativ kan jag föreslå att du klipper en liten reg. uppgift för användarinmatning till varje databas och konfigurera tjänsten att starta om på kvällen (antingen via tjänster eller ett omstartsintervall). Jag tror att detta borde hjälpa, även om vi här är begränsade av tillgången på en licens, så vi måste tänka)))

Men ett annat obehagligt ögonblick dök upp på ett av forumen jag fick det här svaret:
Offtop. Har du CORP-licenser?

Utökade möjligheter hos CORP-nivåservern "1C:Enterprise 8.3" jämfört med 64-bitars PROF-nivåservern:
* säker minnesförbrukning per samtal;
* antal informationssäkerhet per process;
* mängden minne av arbetsprocesser upp till vilken servern anses vara produktiv;
* maximal minneskapacitet för arbetsprocesser;
*balanseringsstrategi (minne, prestanda);

Användningen av den listade funktionen med "1C:Enterprise 8. Server License (x86-64)"-produkter på PROF-nivån, det vill säga de som inte har beteckningen CORP i namnet, är olaglig.

Jag bestämde mig för att kolla med killarna från tre olika företag om de visste att det fanns en företags- och prof. Varpå svaret mottogs i form av: ett snurrande finger vid tinningen och ett sändande till 1c-forumet. Och nedan är svaret från 1c support:

1) >>> Jag skulle vilja klargöra skillnaderna mellan 8.3 Corp och 8.3 Prof plattformen.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

Faktum är att när du använder PROF-plattformen, enligt licensen, kan du bara använda standardinställningarna för kluster.

Om du stöter på problem med "standard" klusterinställningarna (brist på minne, oförmåga att uppdatera konfigurationen, etc.), då
detta beteende är ett fel (antingen av plattformen eller av denna applikationslösning).
Vänligen skapa förfrågningar om korrigering med specifika exempel.
Medan felet korrigeras kan tillstånd utfärdas skriftligt (undertecknat av direktören för 1C CJSC) för att använda funktionerna i Corp.-licensen.
2) >>> Vänligen förtydliga, d.v.s. finns det två 8.3-plattformar?
Inga. Plattformen är för närvarande inte ensam.
Rätten att använda CORP-funktionaliteten visas dock endast vid köp av lämplig licens.
Det finns heller ingen mjukvarukontroll för denna licens för tillfället.
Därför är CORP-licensen mer av ett juridiskt koncept.

Ärligt talat så tror jag inte på olika typer av konspirationer, men när ett företag har nästan 100% monopol på små och medelstora företagsmarknaden kommer olika tankar att tänka på.
"Det kommer att ske en uppdatering av någon form av konfiguration för att skicka rapporter, vilket kommer att kräva uppdatering av plattformen, där mjukvarukontroll redan kommer att implementeras... Och då kommer ni (1c) att betala oss fullt ut... ni barn. ”
P.S. Jag skulle vilja förtydliga att min server är baserad på 2008r2 och det kan finnas skillnader från 2012. Ändå har kärnan klippts om i detalj och hyper-v 3.0 är också en bonus för tillväxt. Men som de säger "IT's Alive!!!" och att köra 1C på virtuella maskiner är inte bara möjligt utan också uppmuntras. Som ett resultat har vi 30 8.2-användare och 20 8.3-användare. Lycka till till er alla, ha tålamod och ge aldrig upp)))