Det maksimale hukommelsesforbrug pr. opkald er overskredet. Flytning af TEMPDB-databasen til en anden større disk

nu lidt flere detaljer:

Klynge 1C 8.3

Først og fremmest, efter installation af 1C-klyngen, var det nødvendigt at oprette arbejdsgange. Som det viste sig, begyndte klyngeprocesser at blive oprettet automatisk afhængigt af belastningen af ​​databasen.

En testkørsel af baggrundsjob i hoveddatabasen fik 1C-klyngen til uendeligt at overbelaste rphost.exe, og den ekstra rphost.exe ønskede ikke at blive oprettet. Efter at have gravet igennem indstillingerne blev alt klart.

Maksimal arbejdsflowhukommelse er mængden af ​​hukommelse, som arbejdsprocesser kan bruge sammen. Du skal være meget forsigtig, når du indstiller parameteren, målt i bytes. Hvis du indstiller den forkerte værdi (utilstrækkelig til normal brugerdrift), vil brugerne modtage fejlmeddelelsen "Ikke nok ledig hukommelse på 1C-serveren." Du kan også få denne fejl, når hukommelseskvoten på 1C-serveren er løbet tør.

Sikkert hukommelsesforbrug pr. opkald- giver dig mulighed for at kontrollere hukommelsesforbrug under et serveropkald, målt i bytes. Hvis et opkald bruger mere hukommelse end forventet, vil dette opkald blive afsluttet i 1C-klyngen uden at genstarte arbejdsprocessen (rphost.exe). Følgelig vil "taberen", der foretog serverkaldet, miste sin session med 1C-databasen uden at påvirke andre brugeres arbejde.

i én GB - 1073741824 bytes, derfor i 2 GB - 2147483648 bytes

Mængden af ​​hukommelse til arbejdsprocesser, som serveren anses for produktiv til - hvis denne parameter overskrides, vil serveren i 1C-klyngen stoppe med at acceptere nye forbindelser.

Antal informationssikkerhed pr. proces- giver dig mulighed for at isolere informationsbaser for arbejdsprocesser. Som standard var den nuværende 1C-klynge sat til "8", men i løbet af flere timers drift blev serveren meget ustabil, brugersessioner frøs. Efter isolering af hver infobase (værdi - "1") forsvandt problemerne.

Antal forbindelser pr. proces- standardværdien er "128". Da den nuværende database har en meget stor belastning af baggrundsopgaver (logistikberegninger, prislisteanalyse, konkurrentanalyse mv.), blev det besluttet at reducere antallet til "25".

Indstillingerne for selve 1C-klyngen er ændret lidt:

Fejltoleranceniveau- dette er antallet af fungerende servere, der kan svigte på samme tid, og dette vil ikke føre til unormal opsigelse af brugere. Backup-tjenester lanceres automatisk i den mængde, der er nødvendig for at sikre den specificerede fejltolerance. I realtid replikeres den aktive tjeneste til backuptjenesten.

Indlæs delingstilstand- der er to muligheder for parameteren: "Priority by performance" - mere serverhukommelse bruges og ydeevne er højere, "Priority by memory" - 1C klyngen sparer serverhukommelse.

Server 8.3 er kendetegnet ved en nyligt redesignet intern kode, selvom det "udefra" kan se ud til, at det er en lidt modificeret 8.2.

Serveren er blevet mere "auto-konfigurerbar"; nogle parametre, såsom antallet af arbejdsprocesser, oprettes ikke længere manuelt, men beregnes ud fra beskrivelserne af kravene til fejltolerance og pålidelighedsopgaver.

Dette reducerer sandsynligheden for serverfejlkonfiguration og sænker kvalifikationskravene til administratorer.

Der er udviklet en, som enten kan bruges til at øge ydelsen af ​​systemet som helhed eller til at bruge en ny "hukommelsesbesparende" tilstand, som giver dig mulighed for at arbejde "med begrænset hukommelse" i tilfælde, hvor konfigurationen brugt "kan lide at æde hukommelsen op."

Driftsstabilitet ved brug af store mængder hukommelse vil blive bestemt af produktionsserverens nye parametre.

Parameteren "sikkert hukommelsesforbrug pr. opkald" er særligt interessant. For dem, der ikke aner hvad det er, er det bedre ikke at træne på et "produktivt" grundlag. Parameteren "Maksimal hukommelsesstørrelse for arbejdsprocesser" tillader, i tilfælde af "overløb", ikke at crashe hele arbejdsprocessen, men kun én session "med taberen". "Mængden af ​​arbejdsproceshukommelse op til, som serveren anses for at være produktiv" giver dig mulighed for at blokere nye forbindelser, så snart denne hukommelsestærskel er overskredet.

Jeg anbefaler at isolere arbejdsprocesser efter informationsbase, for eksempel ved at specificere parameteren "Antal informationssikkerhed pr. proces = 1". Med flere højt belastede databaser vil dette reducere gensidig indflydelse både hvad angår pålidelighed og ydeevne.

Et særskilt bidrag til systemets stabilitet ydes af "udgifter" af licenser/nøgler. I 8.3 blev det muligt at bruge en "software licens manager", der minder om "aladin" manager. Målet er at kunne placere nøglen på en separat maskine.

Den implementeres som en anden "service" i klyngemanageren. Du kan for eksempel bruge en "gratis" bærbar. Føj det til 1C 8.3-klyngen, opret en separat manager på det med "licenstjenesten". Du kan indsætte en hardware-hasp-nøgle i din bærbare computer eller aktivere softwarelicenser.

Af størst interesse for programmører bør "Functionality Assignment Requirements" være.

Krav til den tildelte funktionalitet i 1c

Så på en bærbar computer med en sikkerhedsnøgle, for ikke at starte brugere på klyngeserveren, skal du tilføje "krav" til kravobjektet "Klientforbindelse til informationssikkerhed" - "Tildel ikke", dvs. forhindrer arbejdsprocesser på denne server i at behandle klientforbindelser.

Endnu mere interessant er muligheden for at køre "kun baggrundsjob" på klyngens produktionsserver uden brugersessioner. På denne måde kan du flytte højt belastede opgaver (kode) til en separat maskine. Desuden kan du køre én baggrundsopgave med "lukning af måneden" ved hjælp af "Værdi af en ekstra parameter" på én computer og baggrundsopgaven "Opdatering af fuldtekstindekset" på en anden. Afklaring sker gennem indikationen "Værdi af en ekstra parameter”. Hvis du f.eks. angiver BackgroundJob.CommonModule som en værdi, kan du begrænse arbejdet på worker-serveren i klyngen til kun baggrundsjob med noget indhold. BackgroundJob.CommonModule værdi.<Имя модуля>.<Имя метода>- vil angive en specifik kode.

Klynge 1C 8.2

Sessioner muliggør belastningsbalancering og fejltolerance i en administreret applikation.

Klyngelederen er nu blevet mere kompleks. Nogle funktioner kan nu adskilles i en separat proces og endda placeres på en anden fungerende server i klyngen. Dette giver dig mulighed for at afbalancere serverbelastningen.

Server 8.2 fejltolerance opnås gennem:

  • Lagring af oplysninger om brugerens session.
  • Brugeren er ikke længere bundet til arbejdsgangen.
  • Reservation af arbejdsprocesser i en klynge.
  • Der bør være flere arbejdsprocesser, herunder overflødige
  • Klyngereservation.

En reserveklynge er angivet; når de er tilsluttet, er de opført i forbindelseslinjen

Dette giver dig mulighed for at sikre kontinuitet i arbejdet!

Hvis klientens fysiske forbindelse til klyngen er brudt (rengøringsdamen trak kablet ud, strømmen til netværksudstyret blev slukket, der var et problem med udbyderen), er der ingen grund til at genoprette forbindelse til infobasen og starte alle arbejdet igen. Efter at den fysiske forbindelse er gendannet, kan brugeren fortsætte med at arbejde fra det punkt, hvor den blev afbrudt.

Hvis der kræves vedligeholdelse af klyngecomputere, kan de slukkes under drift uden at forhindre brugere i at arbejde med informationsbasen.

Hvis en server i klyngen fejler, stopper brugerarbejdet ikke, det vil automatisk blive overført til backup-klyngen og/eller backup-arbejdsprocesserne. For brugere vil en sådan overgang være usynlig.

Hvis en af ​​klyngens arbejdsprocesser fejler, vil brugere, der er tilsluttet den, automatisk blive overført til andre eller backup-arbejdsprocesser. En sådan overgang vil også være usynlig for brugerne.

Begreber, begreber

Hvorfor har du brug for en 1C-server?

Udtrykket "serverklynge" refererer til flere computere (servere), der udfører en fælles opgave.

Opgaverne løst af 1C:Enterprise 8 serverklyngen er vist i figuren nedenfor.

Forskellen mellem 8.1 og 8.2

Klynge 1C 8.1

1C:Enterprise 8.1-serverklyngen er en implementering af ideerne om belastningsfordeling på servere, der betjener klientanmodninger. Denne mekanisme fordeler belastningen på computerressourcer inden for en server eller flere servere ("Working Servers"), hvilket sikrer applikationsskalering. Serverklyngen dublerer koden, der betjener klientforbindelser. Klyngens duplikerede eksekverbare kode hedder "Worker Process" (rphost). Når du installerer en klynge, oprettes der kun én arbejdsproces.
Adskillige arbejdsprocesser på én server gør det muligt effektivt at bruge mængden af ​​RAM og processorressourcer til at udføre anmodninger, samt forbinde en klientsession til en anden arbejdsproces, hvis den nuværende "crasher".
Server Agent (ragent) programmet er ansvarlig for at forstå, hvad der kører på en bestemt server. Hvis serveragenten stoppes, bliver serveren utilgængelig til brug af klyngen. Agenten gemmer sine oplysninger i filen srvribrg.lst.
Oplysninger om arbejdsdatabaser og involverede arbejdsprocesser ejes af "Servermanageren" (rmngr). Den gemmer disse oplysninger i filen 1CV8Reg.lst. Stop af serveradministratoren kan føre til en genstart af klientapplikationer, hvis manageren genstarter med succes, eller til et fuldstændigt stop for hele klyngens fungerende servere.
1C:Enterprise 8.1 giver mulighed for at oprette flere uafhængige klynger på én server. Hver af dem er identificeret på netværket af en unik "IP-port" og et unikt nummer i servicefiler. Den første klynge modtager port 1541 som standard.
Enterprise Servers snap-in er designet til at administrere klyngen.
Du kan oprette forbindelse til servere ved hjælp af servernavn eller IP-adresse.

Server agent

Serveragenten "ved" om alle de klynger, der kører på serveren. Disse oplysninger gemmes i filen srvribrg.lst med en liste over klynger og listeadministratorer. Agentens hovedport er 1540. På hver fungerende server kan der kun startes én agent, der betjener alle mulige klynger på denne server.
For at få mere detaljeret information visuelt, brug Process Explorer-værktøjet (udviklet af Sysinternals). Programmet giver dig mulighed for at tage et dybere kig på alle kørende processer, inklusive en 1C:Enterprise 8.1-serverklynge.

Cluster Manager

Klyngelederen er ansvarlig for driften af ​​klyngen. Hver klynge har sin egen Manager. Manageren gemmer information om klyngen i filen 1CV8Reg.lst (klyngeregistret). Hver Cluster Manager har også sin egen port på arbejdsserveren. For den første klynge er standard Manager-porten 1541. Det er denne port, der vises i snap-in'en 1C:Enterprise Servers i Clusters-grenen, der identificerer klyngen.
Lederen modtager forespørgsler fra klientdelen af ​​1C:Enterprise 8.1 og træffer en beslutning om, hvilket Workflow der skal give denne serviceanmodning.

Lederen bruger serviceporten til at interagere med arbejdsprocesser.

Arbejdsprocessen

Arbejdsprocessen er ansvarlig for "at arbejde med kunder." Vi kan sige, at der i den tidligere version af 1C:Enterprise 8.0 kun var én "Workflow".
Der kan være flere arbejdsprocesser i en 1C:Enterprise 8.1-klynge. Serveradministratoren bestemmer, hvilken arbejdsproces der skal betjene klientforbindelsen. For klientforbindelser er arbejdsprocesser som standard tildelt en række IP-porte 1560 – 1591. Derudover er hver arbejdsproces tildelt en serviceport til kommunikation med klyngeadministratoren. Hver arbejdsproces bruger op til 2 Gb RAM i et 32-bit operativsystem. I et 64-bit operativsystem er begrænsningen pålagt af den fysiske mængde RAM

Klynge 1C 8.2

Server cluster 1C:Enterprise 8.2 – videreudvikling af server 8.2 teknologier.

Serveren kan fungere "som 8.1", dvs. den forbliver kompatibel med tidligere teknologier.

Og plus en ny tilgang til serverdrift er blevet implementeret. Nu, i stedet for processer, spiller sessioner en vigtig rolle.

Sessioner muliggør belastningsbalancering og fejltolerance i en administreret applikation.

Cluster Manager

Klyngelederen er nu blevet mere kompleks. Nogle funktioner kan nu adskilles i en separat proces og endda placeres på en anden fungerende server i klyngen. Dette giver dig mulighed for at afbalancere serverbelastningen.

Server 8.2 fejltolerance opnås gennem:

  • Lagring af oplysninger om brugerens session.
    • Brugeren er ikke længere bundet til arbejdsgangen.
  • Reservation af arbejdsprocesser i en klynge.
    • Der bør være flere arbejdsprocesser, herunder overflødige
  • Klyngereservation.
    • En reserveklynge er angivet; når de er tilsluttet, er de opført i forbindelseslinjen

Dette giver mulighed for kontinuitet i driften:

Hvis klientens fysiske forbindelse til klyngen er brudt (rengøringsdamen trak kablet ud, strømmen til netværksudstyret blev slukket, der var et problem med udbyderen), er der ingen grund til at genoprette forbindelse til infobasen og starte alle arbejdet igen. Efter at den fysiske forbindelse er gendannet, kan brugeren fortsætte med at arbejde fra det punkt, hvor den blev afbrudt.

Hvis der kræves vedligeholdelse af klyngecomputere, kan de slukkes under drift uden at forhindre brugere i at arbejde med informationsbasen.

Hvis en server i klyngen fejler, stopper brugerarbejdet ikke, det vil automatisk blive overført til backup-klyngen og/eller backup-arbejdsprocesserne. For brugere vil en sådan overgang være usynlig.

Hvis en af ​​klyngens arbejdsprocesser fejler, vil brugere, der er tilsluttet den, automatisk blive overført til andre eller backup-arbejdsprocesser. En sådan overgang vil også være usynlig for brugerne.

Klynge 1C 8.3

Server 8.3 er kendetegnet ved en nyligt redesignet intern kode, selvom det "udefra" kan se ud til, at det er en lidt modificeret 8.2.

Serveren er blevet mere "auto-konfigurerbar"; nogle parametre, såsom antallet af arbejdsprocesser, oprettes ikke længere manuelt, men beregnes ud fra beskrivelserne af kravene til fejltolerance og pålidelighedsopgaver.

Der er udviklet en, som enten kan bruges til at øge ydelsen af ​​systemet som helhed eller til at bruge en ny "hukommelsesbesparende" tilstand, som giver dig mulighed for at arbejde "med begrænset hukommelse" i tilfælde, hvor konfigurationen brugt "kan lide at æde hukommelsen op."

Driftsstabilitet ved brug af store mængder hukommelse vil blive bestemt af produktionsserverens nye parametre.

Parameteren "sikkert hukommelsesforbrug pr. opkald" er særligt interessant. For dem, der ikke aner hvad det er, er det bedre ikke at træne på et "produktivt" grundlag. Parameteren "Maksimal hukommelsesstørrelse for arbejdsprocesser" tillader, i tilfælde af "overløb", ikke at crashe hele arbejdsprocessen, men kun én session "med taberen". "Mængden af ​​arbejdsproceshukommelse op til, som serveren anses for at være produktiv" giver dig mulighed for at blokere nye forbindelser, så snart denne hukommelsestærskel er overskredet.

Jeg anbefaler at isolere arbejdsprocesser efter informationsbase, for eksempel ved at specificere parameteren "Antal informationssikkerhed pr. proces = 1". Med flere højt belastede databaser vil dette reducere gensidig indflydelse både hvad angår pålidelighed og ydeevne.

Et særskilt bidrag til systemets stabilitet ydes af "udgifter" af licenser/nøgler. I 8.3 blev det muligt at bruge en "software licens manager", der minder om "aladin" manager. Målet er at kunne placere nøglen på en separat maskine.

Den implementeres som en anden "service" i klyngemanageren. Du kan for eksempel bruge en "gratis" bærbar. Føj det til 1C 8.3-klyngen, opret en separat manager på det med "licenstjenesten". Du kan indsætte en hardware-hasp-nøgle i din bærbare computer eller aktivere softwarelicenser.

Af størst interesse for programmører bør "Functionality Assignment Requirements" være.

Så på en bærbar computer med en sikkerhedsnøgle, for ikke at starte brugere på klyngeserveren, skal du tilføje "krav" til kravobjektet "Klientforbindelse til informationssikkerhed" - "Tildel ikke", dvs. forhindrer arbejdsprocesser på denne server i at behandle klientforbindelser.

Endnu mere interessant er muligheden for at køre "kun baggrundsjob" på klyngens produktionsserver uden brugersessioner. På denne måde kan du flytte højt belastede opgaver (kode) til en separat maskine. Desuden kan du køre én baggrundsopgave med "lukning af måneden" ved hjælp af "Værdi af en ekstra parameter" på én computer og baggrundsopgaven "Opdatering af fuldtekstindekset" på en anden. Afklaring sker gennem indikationen "Værdi af en ekstra parameter”. Hvis du f.eks. angiver BackgroundJob.CommonModule som en værdi, kan du begrænse arbejdet på worker-serveren i klyngen til kun baggrundsjob med noget indhold. BackgroundJob.CommonModule værdi.<Имя модуля>.<Имя метода>- vil angive en specifik kode.

Løsning af mulige installationsproblemer

Når du installerer 1C:Enterprise 8.1-serverdelen, kan du oprette en ny bruger eller vælge en eksisterende konto.

I tilfælde af at du vælger en eksisterende konto, skal du angive den korrekte adgangskode og bekræftelse, ellers vil start af serversiden yderligere resultere i en fejl.
Når du kører Cluster Agent for første gang, oprettes en standardklynge.
Standardklyngen har følgende egenskaber:
· portnummer – 1541;
· IP-portområde – 1560:1591;
· understøttelse af mange arbejdsgange – deaktiveret;
· én arbejdsproces, portnummeret indstilles fra det angivne interval.
Hvis der er problemer, første gang du starter Cluster Agent, oprettes standardklyngen muligvis ikke. Dette kommer til udtryk ved, at når serveragenten (ragent) starter, starter den, men starter ikke andre klyngeprocesser (rmngr, rphost). Listen over klynger srvribrg.lst ser sådan ud:
{
{0},
I dette tilfælde kan du stoppe ragentprocessen, slette listen over klynger (srvribrg.lst) og starte ragent igen.

Kontroller overensstemmelsen mellem de porte, der er angivet i portparameteren på kommandolinjen for at starte serveragenttjenesten, og dem, der er angivet i dialogboksen for centrale serverparametre på klyngekonsollen:

— Stop 1C:Enterprise 8.1 Server Agent-tjenesten.

Hvis serveragenten kører som en applikation, kan den stoppes ved at trykke på Ctrl+C tastekombinationen.
- Sørg for i Task Manager, at alle processer ragent, rmngr, rphost er afsluttet. Fuldfør dem om nødvendigt ved hjælp af Task Manager.

— Åbn egenskaberne for 1C:Enterprise 8.1 Server Agent-tjenesten.

- Vær opmærksom på linjen "Eksekverbar fil" (sti til eksekverbar). Den har parameteren -d efterfulgt af klyngedatamappen. Alle filer relateret til klyngen er placeret i denne mappe.
- Slet alt indhold i denne mappe.
— Start 1C:Enterprise 8.1 Server Agent-tjenesten.
- Sørg for i Task Manager, at alle processer ragent, rmngr, rphost er startet.
— Start klyngekonsollen og registrer den centrale server i den. Konsollen skal oprette forbindelse til den centrale server og vise én klynge oprettet som standard.
Mulige problemer med fejl i serverklyngen omfatter problemer med sikkerhedsnøgler, servicekontorettigheder og forkerte opstartsparametre.

  1. Serverbeskyttelsesnøglen er installeret LOKALT på hver server i virksomheden
  2. Angiv ikke en tjenestekonto med en tom adgangskode
  3. Med flere klynger bør de anvendte porte ikke overlappe hinanden

Bemærk venligst, at under installationsprocessen af ​​1C:Enterprise 8.1-platformen kan der blive vist fejlmeddelelser. De mest sandsynlige beskeder er angivet nedenfor. Årsagerne, der forårsagede meddelelserne og trin til at fjerne dem, er angivet.

Fejl 1069: Tjenesten kører ikke på grund af en login-fejl

Problemet er relateret til kontoens rettigheder til at køre som en systemtjeneste. Åbn hjælpeprogrammet Lokal sikkerhedspolitik, og tilføj brugeren (på hvis vegne Cluster Work-serverne startes) til politikkerne Logon as service og Logon as batch job.
Hvis data, der er gemt i servicefiler, er beskadiget, kan starten af ​​klyngens produktionsservere mislykkes. Sørg for, at 1C:Enterprise 8.1-serveragenten kører (ragentproces i Task Manager).
Glem ikke, at Windows Event Auditing også er et analyseværktøj. For at gøre dette skal du se, om der vises nogen "mistænkelige" meddelelser i Windows-hændelsesloggen.

Fejl 8007056B / 800708C5

Den nye adgangskode overholder ikke adgangskodepolitikkerne. Adgangskoden kan være for kort, eller du har allerede brugt denne adgangskode for nylig.
Årsag: den angivne adgangskode til kontoen i dialogboksen "Installer 1C:Enterprise server" opfylder ikke kravene i sikkerhedspolitikken.
Løsning: Indstil en ny adgangskode til den valgte konto, der opfylder kravene i sikkerhedspolitikken eller svækker kravene i den anvendte sikkerhedspolitik, dvs. kræve ikke en "kompleks" adgangskode, begræns ikke antallet af tegn i adgangskoden, kontroller ikke gentagelsesforsøg osv.

Fejl 1923: Ingen privilegier at installere af tjeneste

Årsag: Fejlen er relateret til kontoens installationsrettigheder som applikationer. Denne fejl er typisk for forsøg på at installere en server på en domænecontroller, hvor der kræves øgede sikkerhedsforanstaltninger.
Løsning: Brug ikke en domænecontroller til at være vært for virksomhedsserveren eller slække på sikkerhedskravene og angiv rettighederne "Kør som en tjeneste" eller "Kør som et batchjob" for den valgte konto.

Fejl 80070056

Din adgangskode kunne ikke ændres. Hver adgangskode skal bruges i mindst x dage.
Årsag og løsning: Endnu en fejl, der opstår, når sikkerhedspolitikkens krav til de anvendte adgangskoder overtrædes. Løsningen ligner fejl 800708C5.

Windows-stik - 11004(0x00002AFC)

1) Sørg for, at følgende kører på klyngens arbejdsserver i Task Manager:
Serveragent (ragent.exe),
Cluster Manager (rmngr.exe),
Klyngearbejdsproces (rphost.exe).
2) For at kontrollere IP-adressenavnets opløsning skal du køre på kommandolinjen:
ping maskinenavn
I systemets svar på kommandoen er vi interesserede i at afgøre, om IP-adressen er bestemt.
3) Hvis navnet er bestemt, men arbejdsprocessen stadig ikke findes, skal du sørge for, at navnets IP-adresse er bestemt<имя машины>Og<имя машины>.<имя домена>er ikke defineret anderledes.

(Windows Sockets - 10054(0x00002746).

Fjernværten lukkede forbindelsen med magt.
Denne besked kan modtages, hvis serveren genstartes, eller arbejdsprocessen tvinges til at blive slettet.
Denne fejl vises normalt ikke, når du genopretter forbindelsen. Hvis fejlen fortsætter, er det nødvendigt at undersøge årsagerne til fejlen på klyngens produktionsservere.
Denne fejl kan opstå, når en arbejdsproces når den maksimale hukommelseskapacitet på 32-bit systemer.
Et andet tilfælde er et forbindelsesforsøg fra en klient med en fejlmeddelelse:

(Windows Sockets - 10060(0x0000274C)

Et forsøg på at etablere en forbindelse var mislykket, fordi... det påkrævede svar blev ikke modtaget fra en anden computer inden for den påkrævede tid, eller en allerede etableret forbindelse blev afbrudt på grund af et forkert svar fra den allerede tilsluttede computer.
Essensen af ​​denne fejl er manglen på respons inden for en vis tid (timeout).
1) Sørg for, at din firewall ikke blokerer programtrafik. Sluk din firewall.
For at gøre dette skal du køre kommandoen på kommandolinjen (kommandoen er tilgængelig fra Windows XP og Windows Server 2003; tidligere versioner har ikke en indbygget firewall, men tredjepartssoftware kan installeres):
netshfirewallsætopmodedeaktivere
Hvis kommandoen lykkes, vil du modtage en besked:
OKAY.
Ud over en firewall kan netværksfiltre blokere trafik. De er som standard deaktiveret. Sørg dog for, at det er sådan her:

  1. Åbn mappen Netværksforbindelser.
  2. Højreklik på den netværksforbindelse, du vil konfigurere, og vælg Ejendomme.
  3. På fanen Er almindelige(til lokal netværksforbindelse) eller på fanen Net(for alle andre forbindelser) vælg Internetprotokol (TCP/IP) og tryk på knappen Ejendomme.
  4. Klik på knappen Derudover.
  5. Åbn fanen Muligheder, vælg en indstilling TCP/IP-filtrering og tryk på knappen Ejendomme.
  6. Sørg for at afkrydsningsfeltet Aktiver TCP/IP-filtrering (alle adaptere) fjernet.

2) Sørg for, at processorressourcerne ikke er 100% indlæst (CPU%).
3) Mål netværksaktiviteten af ​​klient- og servergrænseflader. Belastningen på netværksadapteren bør ikke overstige 60 %.

(Windows Sockets - 10061(0x0000274D)

Forbindelsen er ikke etableret pga Destinationscomputeren afviste forbindelsesanmodningen.
En typisk årsag til denne fejl er fraværet af en kørende serveragent. Start serveren manuelt eller genstart serveren for at starte automatisk.

Svar på spørgsmål

Multiplatform 1C

Server installation

Q: Fejl ved installation af 1c-server på MS Server 2008 R2 x64 Ved installation af 1c-server via kommandolinjen, f.eks. ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d "C:\Program Files\1cv82 \ (taget fra ITS-disken), skriver kommandolinjen beskeden: "Fejl! OpenSCManager fejl!" Tjenesten oprettes ikke i dette tilfælde. Testet 8.1.15.14 og 8.2.10.77

A: For at installere fra kommandolinjen på et OS, hvor UAC er til stede, skal du bruge RunAs-tjenesten, fordi Selvom brugeren er medlem af gruppen Administratorer, blokerer UAC handlinger, der ændrer systemtilstanden.

Beskyttelsesnøgler

Sp.: Tillader beskyttelsesnøglen til Server 8.2 mig at køre Server 8.1?
A: Ja, det gør det

Q: For at starte en 1C-server, har jeg brug for en slags server-hasp-nøgler? Lokalt, eller vil det ikke fungere for 5 brugere?

A: ja, serveren har brug for sin egen nøgle, lokal bruger og netværksnøgler virker ikke. Flere detaljer i « « , slide nummer 30.

Q: Lad os sige, at en 1C-serverklynge består af 3 fysiske servere. hvor mange sikkerhedsnøgler er nødvendige?

Q: Der er en terminalserver og en nøgle til 5 licenser, en 6. ekstra licens skal købes. licens. Er det muligt at installere det på serveren ved siden af ​​nøglen ved 5? Og vil alle 6 brugere arbejde i terminalsessioner eller 5 - under terminalen og 1 i filversionen?
A: Nej, det vil de ikke. Den 6. licens i form af en lokal nøgle skal tilsluttes brugerens computer, men ikke i terminalen.

1C-serveropdateringer

Q: Når en ny version 8.2.xxx af platformen frigives, hvad er proceduren for opdatering af servere og klienter?
A: 8.2 distributioner installerer deres filer i forskellige mapper (hver version har sin egen mappe), dvs. teoretisk er det stadig muligt at kalde flere versioner af serveren parallelt.

Jeg havde ingen problemer. Du skal dog nøje overvåge de porte, der er optaget af 1C-serverinstansen. Der bør ikke være kryds.

Opsætning af 1C-server

Q: I 1C 8.1, hvad er den bedste måde at placere infobaser, hvis der er flere af dem, i en klynge eller oprette en separat klynge for hver database? A: Ved stor volumen eller belastning skal testdatabaser placeres i separate klynger!

Spørgsmål: SPØRGSMÅL: Er 1C:Enterprise 8.1-arbejdsgangen en enkelt-trådet applikation eller en flertrådet? De der. kan mange kerner indlæses med én tilsluttet bruger? med flere? Hvad med 1C:Enterprise 8.2-arbejdsgangen? Tak skal du have.
A: 1Сv8.exe og rphost.exe i version 8.1 forbrugte 1 kerne. Da klientforbindelsen i 8.1 er strengt bundet til arbejdsprocessen, kan vi betinget antage, at 1C klientbehandling udføres inden for en enkelt kerne. Undtagelsen er DBMS, som bruger kerner uanset hvordan 1C-serveren fungerer.

I version 8.2 er forbindelser erstattet af sessioner. Sessioner kører muligvis allerede i forskellige arbejdsprocesser. Derfor er det nok ikke korrekt at kalde 8.2 single-threaded. Client 8.2 indlæser også visuelt flere kerner, så dette:

Platform 8.2 implementerer ikke alle mulighederne i et multi-threaded system, men den gør meget bedre brug af hardware-kapaciteter sammenlignet med 8.1, herunder med hensyn til parallelitet.

Sp: Er det nødvendigt at have flere 1C:Enterprise 8.1 arbejdsprocesser for databaseserveren (MS SQL) for at indlæse flere kerner? (Det bemærkes, at MS SQL normalt kun "indlæser" én kerne, dvs. at "parallelisere" behandlingen af ​​en anmodning på tværs af flere kerner, sker som regel ikke.) Tak.
A: Der er ikke behov for specifikt at administrere MS SQL; det er et ret selvjusterende system, der bruger ressourcer efter behov. Du kan kontrollere eksekveringsparallelisme:

EXEC sys.sp_configure N'max grad af parallelisme', N'5′

GENKONFIGURER MED TILSIDE

Du kan oprette flere arbejdsprocesser på 1C-serveren baseret på, at én arbejdsproces ikke giver mulighed for, at brugerne kan genforbinde, hvis arbejdsprocessen går ned. Proces 2 (på 8.2 er det bedre at gøre det "backup") løser dette problem. Men det giver kun mening at tilføje en tredje eller flere arbejdsprocesser, hvis de første to arbejdsprocesser er tungt belastede (mere end 90%). Det nytter ikke at multiplicere arbejdsprocesser unødigt, det kan forringe produktiviteten.

A: Der skal være mindst 1 backup arbejdsproces i 8.2.

Failover-klynge

Spørgsmål: Spørgsmål om aktivering af redundans for 1s 8.2-klynger. Hvis vores server styrtede ned (rengøringsdamen trak ledningen ud), så vil netværksnavnet, for eksempel "server:2540" ikke være tilgængeligt. Hvordan ved en klient, hvis forbindelsesstreng siger "server:2540", at den skal oprette forbindelse til backup-klyngen? hvor får han navnet på den anden server? Hvad hvis du skriver klynger adskilt af kommaer i databaseforbindelsesstrengen?
A: Flere klynger er kombineret til en "redundansgruppe". Til dette formål er der en "reservationsliste" i klyngens snap-in.

Når en klient først får adgang til en klynge, får den en liste over klynger, der er inkluderet i redundansgruppen.

Hvis klienten aldrig har kontaktet dig, skal du i dette tilfælde manuelt angive adresserne på alle klynger, for eksempel storm:2541,monster:2541.

Synkroniserede data udveksles mellem redundansklynger.

Q: Hvad sker der, efter at hovedklyngen er gendannet? når brugerne skiftede til backup.

A: De går tilbage. Der kan være pauser under skift, mens disse klynger synkroniseres.

Baggrund job

Sp: Hvordan sletter man et baggrundsjob, der kører på serverne 1C:8.1 og 1C:8.2?

Sv: Muligheden for at annullere en rutineopgave virker kun, hvis koden udføres i det indbyggede 1C:Enterprise-sprog. Hvis koden udføres i eksterne biblioteker, kan en sådan opgave ikke annulleres, undtagen ved at afslutte workflowet med magt. Hvis der i processen er en blok StartTransaction() - CommitTransaction(), så er det usandsynligt. Andre baggrundsjob kan slettes via jobkonsollen.

Reguleringsprocedurer

Q: Er det muligt at ødelægge basen under T&I?

A: Jeg er ikke bekendt med sådanne tilfælde, men IMHO alt er muligt. Derfor vil det være en god idé at lave en backup før T&I.

Q: Vyacheslav, af hvilke grunde udfører du ikke genindeksering ved hjælp af 1C-test og korrektion?
A: DBMS-funktioner er bedre egnede til disse formål, da de i det væsentlige også genopbygger indekser, men ikke kræver eksklusiv beslaglæggelse af databasen.

Teknologi magasin

Q: God eftermiddag. Spørgsmål fra et teknologimagasin: Jeg skal modtage kopier af arbejdsstationsskærme i tilfælde af 1C-fejl. Skal jeg oprette en teknologisk log på arbejdsstationer til dette, eller er det kun til serveren?
A: Du kan kun konfigurere modtagelse af et skærmbillede, når platformen falder, og ikke når der er nogen fejl. Der er dog ikke meget nytte i en sådan operation; det er ganske nok at indsamle undtagelsessituationer ved hjælp af en teknologisk log. Samtidig kan de fleste af fejlene ses ved hjælp af TZ på 1C-serversiden. En undtagelse ville være hændelser såsom en "formatstream-fejl", der er forbundet med en forældet metadata-cache.

Problemer og fejl

Spørgsmål: Er du stødt på et problem - forsvinden af ​​rapportindstillinger for brugere ved dynamisk opdatering af konfigurationer på 8.2-platformen. Nogle anbefalinger til, hvordan man håndterer dette?
A: Problemer forbundet med dynamisk opdatering afspejles i "1C-servere: Enterprise 8.1 og 8.2 - hvad skal man spise med "), slide nummer 60. Ryd cache. Måske er det i nogle tilfælde nødvendigt at forstå, hvor nøjagtigt brugerindstillinger er gemt. Gem eventuelt som binære data i informationsregisteret.

Q: Et relateret spørgsmål, fordi... dette er relevant for filtilstand: hvilke fejl retter chdbfl.exe?
A: Dette er et fejlkorrektionsværktøj til datalagringsstruktur. Dette kan være en situation, hvor f.eks. "Databasefilen er beskadiget.../1Cv8.1CD" vises. De der. løser korruption af databasefiler. Den udfører dog ikke T&I-funktioner. Jeg kører chdbfl.exe, hvis T&I ikke kører korrekt.

Spørgsmål: Fortæl mig venligst, hvis du er stødt på et sådant problem. når der er et stort antal brugere i databasen (ca. 40) ved behandling af store dokumenter, for eksempel ved at afspejle PO i reg. Står for omkring 8000 linjer. Fejlmeddelelsen er, at der ikke er nok hukommelse på enterprise 1C-serveren, og den bruger, der startede dette dokument, falder fra. Dokumentet kan derefter kun behandles efter genstart af 1C-serveragenten.
A: Det ligner hukommelseslækager:

1. Genstart 1C-serveren, øg antallet af arbejdsprocesser, og behold kun denne ene database i klyngen.

2. Slå bedriften i portioner, f.eks. 1000 linjer ad gangen. Brug TZ til at spore objekter, der optager hukommelse i begyndelsen af ​​en operation, men frigiver ikke hukommelse efter afslutning.

3. Installer x64-versionen, øg mængden af ​​RAM, skift til 8.2.

Q: Spørgsmål om test og styring. Er det muligt at køre et "Referential Integrity Check" baseret på URDB med valg baseret på de transmitterede data? (dvs. i nogle noder er der fysisk ingen objekter, men der er links til dem). Tak skal du have!
A: Det er desværre ikke muligt endnu.

Spørgsmål: Hvorfor løser test og fixering ikke alle problemerne på én gang, skal du køre det flere gange?

A: Kun udviklere kan svare præcist. Jeg kører T&I efter reglerne (cyklisk), så dette problem er ikke særlig relevant for mig. T&I skal gøres ikke kun én gang, men konstant, som "MOT for en bil."

Spørgsmål: Er der forskel på T&I 8.1 og 8.2?

A: I det øjeblik, jeg skrev svaret og release 8.2.10, kender jeg ikke forskellen.

Spørgsmål: Er det nødvendigt at omindeksere under omstrukturering?
A: Ikke nødvendigt.

Andet

Q: Kære herrer, har nogen prøvet at spejle databaser ved hjælp af MSSql 2008? Er det overhovedet muligt?

Spørgsmål om at tvinge delt hukommelse på server 1s 8.2

A: Der er ingen grund til at tvinge noget, serveren vil forstå.

Q: For 1C:Enterprise 8.1 er der blevet bemærket situationer, hvor filserverversionen med "tunge" operationer på samme hardware og en enkelt bruger arbejder meget hurtigere end klient-serverversionen, når alle "links" (database server, 1C server :Enterprise og klient) er installeret på samme server. Desuden, når du udfører denne "tunge" operation, er der ingen åbenlyse hardwareoverbelastninger (belastningen på processoren, hukommelsen og harddiskene er minimal). Det vil sige, at der er mange hardwareressourcer, men det virker langsomt. Hvad kan vi "hvile os imod"? Tak skal du have.
A: Fordelen ved klient-server-arkitekturen set ud fra et ydeevnesynspunkt er evnen til at behandle klientanmodninger om data i PARALLEL. De der. Flowhastighed er ikke en indikator, som man kan drage generelle konklusioner på. Mekanismer, der forbedrer samtidighed, kan stadig reducere ydeevnen en smule inden for en enkelt tråd.

For entydigt at finde flaskehalsen i dit tilfælde, skal du indhente serverudstyrets arbejdsbyrde og sammenligne det i tid med de længste operationer i klient-server-tilstand. Ofte er dette en overdreven flytning af data til klientsiden. De der. I stedet for at udføre operationer på 1C-serveren, overføres data fra databasen gennem serveren til klienten.

Hastigheden i én tråd af klient-server-versionen vil kun indhente ydeevnen af ​​filversionen. Det er værd at tackle dette problem, hvis driftstiden i absolutte tal måles på ikke mindre end minutter. Optimering inden for 1-3 sekunders forespørgsler er tvivlsomt.

Sp: Om forskellen mellem Windows-terminalen og 1C-tynde klienten.
A: Indtil de fleste løsninger er HELT oversat til 8.2, er det bestemt svært at tale om en praktisk sammenligning af disse teknologier.

Det er klart, at den tynde 1C-klient skal forbruge mindre trafik og give mulighed for at arbejde via nettet. Men det er noget, der endnu ikke er implementeret, og terminalløsninger bliver brugt meget bredt nu.

For konservative, pragmatiske projektledere, der konverterer 8.1 til 8.2 - en terminalløsning. For små projekter med lave fejlomkostninger og en konfiguration umiddelbart implementeret med administrerede formularer og adgangskontrolsystemer, er en tynd klient at foretrække IMHO.

Q: Hvordan udfører man belastningstest tæt på virkelige forhold? Når alt kommer til alt, kan du ikke tvinge brugere til at "klikke på noget."

A: 1C: Testcenter med et udvalg af de vanskeligste operationer, 100% reproduktion er ikke nødvendig, klikkene i sig selv er ikke vanskelige, hovedsageligt at udføre og anmode om rapporter. Der vil være et separat webinar om test. Jeg vil også fortælle dig mere detaljeret.

05.04.2017 |

Klynge 1C 8.3

Først og fremmest, efter installation af 1C-klyngen, var det nødvendigt at oprette arbejdsgange. Som det viste sig, begyndte klyngeprocesser at blive oprettet automatisk afhængigt af belastningen af ​​databasen.

En testkørsel af baggrundsjob i hoveddatabasen fik 1C-klyngen til uendeligt at overbelaste rphost.exe, og den ekstra rphost.exe ønskede ikke at blive oprettet. Efter at have gravet igennem indstillingerne blev alt klart.

Maksimal arbejdsflowhukommelse er mængden af ​​hukommelse, som arbejdsprocesser kan bruge sammen. Du skal være meget forsigtig, når du indstiller parameteren, målt i bytes. Hvis du indstiller den forkerte værdi (utilstrækkelig til normal brugerdrift), vil brugerne modtage fejlmeddelelsen "Ikke nok ledig hukommelse på 1C-serveren." Du kan også få denne fejl, når hukommelseskvoten på 1C-serveren er løbet tør.

Sikkert hukommelsesforbrug pr. opkald- giver dig mulighed for at kontrollere hukommelsesforbrug under et serveropkald, målt i bytes. Hvis et opkald bruger mere hukommelse end forventet, vil dette opkald blive afsluttet i 1C-klyngen uden at genstarte arbejdsprocessen (rphost.exe). Følgelig vil "taberen", der foretog serverkaldet, miste sin session med 1C-databasen uden at påvirke andre brugeres arbejde.

i én GB - 1073741824 bytes, derfor i 2 GB - 2147483648 bytes

Mængden af ​​hukommelse til arbejdsprocesser, som serveren anses for produktiv til - hvis denne parameter overskrides, vil serveren i 1C-klyngen stoppe med at acceptere nye forbindelser.

Antal informationssikkerhed pr. proces- giver dig mulighed for at isolere informationsbaser for arbejdsprocesser. Som standard var den nuværende 1C-klynge sat til "8", men i løbet af flere timers drift blev serveren meget ustabil, brugersessioner frøs. Efter isolering af hver infobase (værdi - "1") forsvandt problemerne.

Antal forbindelser pr. proces- standardværdien er "128". Da den nuværende database har en meget stor belastning af baggrundsopgaver (logistikberegninger, prislisteanalyse, konkurrentanalyse mv.), blev det besluttet at reducere antallet til "25".

Indstillingerne for selve 1C-klyngen er ændret lidt:

Fejltoleranceniveau- dette er antallet af fungerende servere, der kan svigte på samme tid, og dette vil ikke føre til unormal opsigelse af brugere. Backup-tjenester lanceres automatisk i den mængde, der er nødvendig for at sikre den specificerede fejltolerance. I realtid replikeres den aktive tjeneste til backuptjenesten.

Indlæs delingstilstand- der er to muligheder for parameteren: "Priority by performance" - mere serverhukommelse bruges og ydeevne er højere, "Priority by memory" - 1C klyngen sparer serverhukommelse.

Server 8.3 er kendetegnet ved en nyligt redesignet intern kode, selvom det "udefra" kan se ud til, at det er en lidt modificeret 8.2.

Serveren er blevet mere "auto-konfigurerbar"; nogle parametre, såsom antallet af arbejdsprocesser, oprettes ikke længere manuelt, men beregnes ud fra beskrivelserne af kravene til fejltolerance og pålidelighedsopgaver.

Dette reducerer sandsynligheden for serverfejlkonfiguration og sænker kvalifikationskravene til administratorer.

Der er udviklet en, som enten kan bruges til at øge ydelsen af ​​systemet som helhed eller til at bruge en ny "hukommelsesbesparende" tilstand, som giver dig mulighed for at arbejde "med begrænset hukommelse" i tilfælde, hvor konfigurationen brugt "kan lide at æde hukommelsen op."

Driftsstabilitet ved brug af store mængder hukommelse vil blive bestemt af produktionsserverens nye parametre.

Parameteren "sikkert hukommelsesforbrug pr. opkald" er særligt interessant. For dem, der ikke aner hvad det er, er det bedre ikke at træne på et "produktivt" grundlag. Parameteren "Maksimal hukommelsesstørrelse for arbejdsprocesser" tillader, i tilfælde af "overløb", ikke at crashe hele arbejdsprocessen, men kun én session "med taberen". "Mængden af ​​arbejdsproceshukommelse op til, som serveren anses for at være produktiv" giver dig mulighed for at blokere nye forbindelser, så snart denne hukommelsestærskel er overskredet.

Jeg anbefaler at isolere arbejdsprocesser efter informationsbase, for eksempel ved at specificere parameteren "Antal informationssikkerhed pr. proces = 1". Med flere højt belastede databaser vil dette reducere gensidig indflydelse både hvad angår pålidelighed og ydeevne.

Et særskilt bidrag til systemets stabilitet ydes af "udgifter" af licenser/nøgler. I 8.3 blev det muligt at bruge en "software licens manager", der minder om "aladin" manager. Målet er at kunne placere nøglen på en separat maskine.

Den implementeres som en anden "service" i klyngemanageren. Du kan for eksempel bruge en "gratis" bærbar. Føj det til 1C 8.3-klyngen, opret en separat manager på det med "licenstjenesten". Du kan indsætte en hardware-hasp-nøgle i din bærbare computer eller aktivere softwarelicenser.

Af størst interesse for programmører bør "Functionality Assignment Requirements" være.

Krav til den tildelte funktionalitet i 1c

Så på en bærbar computer med en sikkerhedsnøgle, for ikke at starte brugere på klyngeserveren, skal du tilføje "krav" til kravobjektet "Klientforbindelse til informationssikkerhed" - "Tildel ikke", dvs. forhindrer arbejdsprocesser på denne server i at behandle klientforbindelser.

Endnu mere interessant er muligheden for at køre "kun baggrundsjob" på klyngens produktionsserver uden brugersessioner. På denne måde kan du flytte højt belastede opgaver (kode) til en separat maskine. Desuden kan du køre én baggrundsopgave med "lukning af måneden" ved hjælp af "Værdi af en ekstra parameter" på én computer og baggrundsopgaven "Opdatering af fuldtekstindekset" på en anden. Afklaring sker gennem indikationen "Værdi af en ekstra parameter”. Hvis du f.eks. angiver BackgroundJob.CommonModule som en værdi, kan du begrænse arbejdet på worker-serveren i klyngen til kun baggrundsjob med noget indhold. BackgroundJob.CommonModule værdi.<Имя модуля>.<Имя метода>- vil angive en specifik kode.

Klynge 1C 8.2

Sessioner muliggør belastningsbalancering og fejltolerance i en administreret applikation.

Klyngelederen er nu blevet mere kompleks. Nogle funktioner kan nu adskilles i en separat proces og endda placeres på en anden fungerende server i klyngen. Dette giver dig mulighed for at afbalancere serverbelastningen.

Server 8.2 fejltolerance opnås gennem:

  • Lagring af oplysninger om brugerens session.
  • Brugeren er ikke længere bundet til arbejdsgangen.
  • Reservation af arbejdsprocesser i en klynge.
  • Der bør være flere arbejdsprocesser, herunder overflødige
  • Klyngereservation.

En reserveklynge er angivet; når de er tilsluttet, er de opført i forbindelseslinjen

Dette giver dig mulighed for at sikre kontinuitet i arbejdet!

Hvis klientens fysiske forbindelse til klyngen er brudt (rengøringsdamen trak kablet ud, strømmen til netværksudstyret blev slukket, der var et problem med udbyderen), er der ingen grund til at genoprette forbindelse til infobasen og starte alle arbejdet igen. Efter at den fysiske forbindelse er gendannet, kan brugeren fortsætte med at arbejde fra det punkt, hvor den blev afbrudt.

Hvis der kræves vedligeholdelse af klyngecomputere, kan de slukkes under drift uden at forhindre brugere i at arbejde med informationsbasen.

Hvis en server i klyngen fejler, stopper brugerarbejdet ikke, det vil automatisk blive overført til backup-klyngen og/eller backup-arbejdsprocesserne. For brugere vil en sådan overgang være usynlig.

Hvis en af ​​klyngens arbejdsprocesser fejler, vil brugere, der er tilsluttet den, automatisk blive overført til andre eller backup-arbejdsprocesser. En sådan overgang vil også være usynlig for brugerne.

Ofte kører andre tjenester på maskinen sammen med 1C:Enterprise-serveren - en terminalserver, SQL-server osv. Og på et tidspunkt spiser 1C:Enterprise-serveren, eller rettere rphost-arbejderprocessen, mere hukommelse end planlagt eller hele hukommelsen. Hvilket fører til en opbremsning af andre tjenester og zombier på serveren. For at undgå sådanne situationer skal du konfigurere automatisk genstart af 1C:Enterprise-serverarbejdsgange

Løsning

1. Åbn administrationskonsollen på 1C Enterprise-servere;
2. Udvid det centrale servertræ til klynger, og vælg den klynge, der interesserer os. I eksemplet er der kun én klynge;
3. Åbn egenskaberne for den valgte klynge, og se følgende formular

Egenskaber for 1C:Enterprise 8.3-serverklyngen

Lad os se på eksemplet vist på billedet:

Genstartsinterval— tid, hvorefter rphost-processen tvinges til at genstarte. Inden processen afsluttes, startes en ny rphost-proces, hvortil alle forbindelser overføres, og først derefter afsluttes den gamle proces. Dette vil ikke påvirke brugerens oplevelse på nogen måde. Intervallet er angivet i sekunder, i eksemplet er 24 timer angivet.

Tilladt hukommelsesstørrelse— mængden af ​​hukommelse, inden for hvilken arbejdsgangen kan fungere uden problemer. Volumen er angivet i kilobyte, i eksemplet er værdien 20 gigabyte (faktisk er tallet for stort, og du skal starte fra det specifikke system, men det gennemsnitlige tal er 4 GB). Så snart hukommelsen optaget af arbejdsprocessen overstiger den angivne værdi, begynder nedtællingen.

Interval for overskridelse af den tilladte mængde hukommelse— efter at timeren, der er startet efter at have overskredet den tilladte mængde hukommelse, tæller ned den angivne tid, vil en ny arbejdsproces blive startet, hvortil alle forbindelser overføres, den gamle proces er markeret som deaktiveret. Intervallet er angivet i sekunder, i eksemplet er 30 sekunder angivet.

Stop deaktiverede processer efter— den tid, hvorefter arbejdsgangen, der er markeret som deaktiveret, stoppes; hvis værdien er 0, vil processen ikke blive fuldført. Intervallet er angivet i sekunder, i eksemplet er 60 sekunder angivet.

Når du har anvendt indstillingerne, behøver du ikke at genstarte servertjenesten, de anvendes dynamisk.

Total

Sådan opsætter vi automatisk genstart af 1C:Enterprise server arbejdsprocesser og får et mere stabilt system; hvis der opstår en hukommelseslæk, vil arbejdet i en specifik session blive afsluttet.

I nogle situationer kan du også lege med indstillingerne og forhindre et muligt servernedbrud, hvis du laver fejl.

Først og fremmest, efter installation af 1C-klyngen, var det nødvendigt at oprette arbejdsgange. Som det viste sig, begyndte klyngeprocesser at blive oprettet automatisk afhængigt af belastningen af ​​databasen.

En testkørsel af baggrundsjob i hoveddatabasen fik 1C-klyngen til uendeligt at overbelaste rphost.exe, og den ekstra rphost.exe ønskede ikke at blive oprettet. Efter at have gravet igennem indstillingerne blev alt klart.

Maksimal arbejdsflowhukommelse er mængden af ​​hukommelse, som arbejdsprocesser kan bruge sammen. Du skal være meget forsigtig, når du indstiller parameteren, målt i bytes. Hvis du indstiller den forkerte værdi (utilstrækkelig til normal brugerdrift), vil brugerne modtage fejlmeddelelsen "Ikke nok ledig hukommelse på 1C-serveren." Du kan også få denne fejl, når hukommelseskvoten på 1C-serveren er løbet tør.

Sikkert hukommelsesforbrug pr. opkald– giver dig mulighed for at kontrollere hukommelsesforbruget under et serveropkald, målt i bytes. Hvis et opkald bruger mere hukommelse end forventet, vil dette opkald blive afsluttet i 1C-klyngen uden at genstarte arbejdsprocessen (rphost.exe). Følgelig vil "taberen", der foretog serverkaldet, miste sin session med 1C-databasen uden at påvirke andre brugeres arbejde.

i én GB – 1073741824 bytes, derfor i 2 GB – 2147483648 bytes

Mængden af ​​hukommelse til arbejdsprocesser, som serveren anses for produktiv til - hvis denne parameter overskrides, vil serveren i 1C-klyngen stoppe med at acceptere nye forbindelser.

Antal informationssikkerhed pr. proces– giver dig mulighed for at isolere informationsbaser for arbejdsprocesser. Som standard var den nuværende 1C-klynge indstillet til " 8 “, men i løbet af flere timers drift opførte serveren sig meget ustabilt, brugersessioner frøs. Efter at have isoleret hver infobase (værdi - "1") forsvandt problemerne.

Antal forbindelser pr. proces- standard værdi " 128 “. Da den nuværende database har en meget stor belastning af baggrundsopgaver (logistikberegninger, prislisteanalyse, konkurrentanalyse mv.), blev det besluttet at reducere antallet til "25".

Indstillingerne for selve 1C-klyngen er ændret lidt:

Fejltoleranceniveau– dette er antallet af fungerende servere, der samtidigt kan svigte, og dette vil ikke føre til unormal opsigelse af brugere. Backup-tjenester lanceres automatisk i den mængde, der er nødvendig for at sikre den specificerede fejltolerance. I realtid replikeres den aktive tjeneste til backuptjenesten.

Indlæs delingstilstand– der er to muligheder for parameteren: "Prioritet efter ydeevne" - mere serverhukommelse bruges og ydeevne er højere, "Prioritet efter hukommelse" - 1C-klyngen sparer serverhukommelse.

Server 8.3 er kendetegnet ved en nyligt redesignet intern kode, selvom det "udefra" kan se ud til, at det er en lidt modificeret 8.2.

Serveren er blevet mere "auto-konfigurerbar"; nogle parametre, såsom antallet af arbejdsprocesser, oprettes ikke længere manuelt, men beregnes ud fra beskrivelserne af kravene til fejltolerance og pålidelighedsopgaver.

Dette reducerer sandsynligheden for serverfejlkonfiguration og sænker kvalifikationskravene til administratorer.

Der er udviklet en, som enten kan bruges til at øge ydelsen af ​​systemet som helhed eller til at bruge en ny "hukommelsesbesparende" tilstand, som giver dig mulighed for at arbejde "med begrænset hukommelse" i tilfælde, hvor konfigurationen brugt "kan lide at æde hukommelsen op."

Driftsstabilitet ved brug af store mængder hukommelse vil blive bestemt af produktionsserverens nye parametre.

Parameteren "sikkert hukommelsesforbrug pr. opkald" er særligt interessant. For dem, der ikke aner hvad det er, er det bedre ikke at træne på et "produktivt" grundlag. Parameteren "Maksimal hukommelsesstørrelse for arbejdsprocesser" tillader, i tilfælde af "overløb", ikke at crashe hele arbejdsprocessen, men kun én session "med taberen". "Mængden af ​​arbejdsproceshukommelse op til, som serveren anses for at være produktiv" giver dig mulighed for at blokere nye forbindelser, så snart denne hukommelsestærskel er overskredet.

Jeg anbefaler at isolere arbejdsprocesser efter informationsbase, for eksempel ved at specificere parameteren "Antal informationssikkerhed pr. proces = 1". Med flere højt belastede databaser vil dette reducere gensidig indflydelse både hvad angår pålidelighed og ydeevne.

Et særskilt bidrag til systemets stabilitet ydes af "udgifter" af licenser/nøgler. I 8.3 blev det muligt at bruge en "software licens manager", der minder om "aladin" manager. Målet er at kunne placere nøglen på en separat maskine.

Den implementeres som en anden "service" i klyngemanageren. Du kan for eksempel bruge en "gratis" bærbar. Føj det til 1C 8.3-klyngen, opret en separat manager på det med "licenstjenesten". Du kan indsætte en hardware-hasp-nøgle i din bærbare computer eller aktivere softwarelicenser.

Af størst interesse for programmører bør "Functionality Assignment Requirements" være.

Krav til den tildelte funktionalitet i 1c

Så på en bærbar computer med en sikkerhedsnøgle, for ikke at starte brugere på klyngeserveren, skal du tilføje "krav" til kravobjektet "Klientforbindelse til informationssikkerhed" - "Tildel ikke", dvs. forhindrer arbejdsprocesser på denne server i at behandle klientforbindelser.

Endnu mere interessant er muligheden for at køre "kun baggrundsjob" på klyngens produktionsserver uden brugersessioner. På denne måde kan du flytte højt belastede opgaver (kode) til en separat maskine. Desuden kan du køre én baggrundsopgave med "lukning af måneden" ved hjælp af "Værdi af en ekstra parameter" på én computer og baggrundsopgaven "Opdatering af fuldtekstindekset" på en anden. Afklaring sker gennem indikationen "Værdi af en ekstra parameter”. Hvis du f.eks. angiver BackgroundJob.CommonModule som en værdi, kan du begrænse arbejdet på worker-serveren i klyngen til kun baggrundsjob med noget indhold. BackgroundJob.CommonModule værdi.<Имя модуля>.<Имя метода>– vil angive en bestemt kode.