Maksimalt minneforbruk per samtale er overskredet. Flytter TEMPDB-databasen til en annen større disk

nå litt mer detalj:

Klynge 1C 8.3

Først av alt, etter å ha installert 1C-klyngen, var det nødvendig å lage arbeidsflyter. Som det viste seg, begynte klyngeprosesser å bli opprettet automatisk avhengig av belastningen på databasen.

En testkjøring av bakgrunnsjobber i hoveddatabasen førte til at 1C-klyngen uendelig overbelastet rphost.exe og den ekstra rphost.exe ønsket ikke å bli opprettet. Etter å ha gravd gjennom innstillingene ble alt klart.

Maksimalt arbeidsflytminne er mengden minne som arbeidsprosesser kan bruke sammen. Du må være veldig forsiktig når du angir parameteren, målt i byte. Hvis du angir feil verdi (utilstrekkelig for normal brukerdrift), vil brukere få feilmeldingen "Ikke nok ledig minne på 1C-serveren." Du kan også få denne feilen når minnekvoten på 1C-serveren er tom.

Sikkert minneforbruk per samtale- lar deg kontrollere minneforbruket under et serveranrop, målt i byte. Hvis en samtale bruker mer minne enn forventet, vil denne samtalen bli fullført i 1C-klyngen uten å starte arbeidsprosessen på nytt (rphost.exe). Følgelig vil "taperen" som foretok serveranropet miste økten med 1C-databasen uten å påvirke arbeidet til andre brukere.

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

Mengden minne for arbeidsprosesser opp til som serveren anses som produktiv - hvis denne parameteren overskrides, vil serveren i 1C-klyngen slutte å akseptere nye tilkoblinger.

Antall informasjonssikkerhet per prosess- lar deg isolere informasjonsbaser for arbeidsprosesser. Som standard var den nåværende 1C-klyngen satt til "8", men i løpet av flere timers drift ble serveren veldig ustabil, brukerøkter frøs. Etter å ha isolert hver infobase (verdi - "1") forsvant problemene.

Antall tilkoblinger per prosess- Standardverdien er "128". Siden dagens database har en svært stor belastning av bakgrunnsoppgaver (logistikkberegninger, prislisteanalyse, konkurrentanalyse osv.), ble det besluttet å redusere antallet til "25".

Innstillingene til selve 1C-klyngen har endret seg litt:

Feiltoleransenivå- dette er antallet fungerende servere som kan svikte samtidig uten å få brukere til å krasje. Sikkerhetskopieringstjenester lanseres automatisk i det beløpet som er nødvendig for å sikre den angitte feiltoleransen. I sanntid blir den aktive tjenesten replikert til backuptjenestene.

Last delingsmodus- det er to alternativer for parameteren: "Prioritet etter ytelse" - mer serverminne brukes og ytelsen er høyere, "Prioritet etter minne" - 1C-klyngen sparer serverminne.

Server 8.3 er preget av en nylig redesignet intern kode, selv om det "fra utsiden" kan virke som om det er en litt modifisert 8.2.

Serveren har blitt mer "autokonfigurerbar" noen parametere, for eksempel antall arbeidsprosesser, opprettes ikke lenger manuelt, men beregnes basert på beskrivelsene av kravene til feiltoleranse og pålitelighetsoppgaver.

Dette reduserer sannsynligheten for feilkonfigurering av serveren og reduserer kvalifikasjonskravene for administratorer.

Det er utviklet en lastbalanseringsmekanisme, som kan brukes enten til å øke ytelsen til systemet som helhet, eller for å bruke en ny "minnesparing"-modus, som lar deg jobbe "med begrenset minne" i tilfeller der konfigurasjonen brukt "liker å spise opp hukommelsen."

Driftsstabilitet ved bruk av store mengder minne vil bli bestemt av de nye parameterne til produksjonsserveren.

Parameteren "sikkert minneforbruk per samtale" er spesielt interessant. For de som har liten anelse om hva det er, er det bedre å ikke trene på en "produktiv" basis. Parameteren "Maksimal minnestørrelse for arbeidsprosesser" tillater, i tilfelle "overflyt", ikke å krasje hele arbeidsprosessen, men bare én økt "med taperen". "Mengden arbeidsprosessminne opp til som serveren anses som produktiv" lar deg blokkere nye tilkoblinger så snart denne minneterskelen er overskredet.

Jeg anbefaler å isolere arbeidsprosesser etter informasjonsbase, for eksempel ved å spesifisere parameteren "Antall informasjonssikkerhet per prosess = 1". Med flere høyt belastede databaser vil dette redusere gjensidig påvirkning både i pålitelighet og ytelse.

Et eget bidrag til systemets stabilitet er gitt av "utgifter" av lisenser/nøkler. I 8.3 ble det mulig å bruke en "software license manager", som minner om "aladin" manager. Målet er å kunne plassere nøkkelen på en egen maskin.

Den implementeres som en annen "tjeneste" i klyngelederen. Du kan for eksempel bruke en "gratis" bærbar datamaskin. Legg den til 1C 8.3-klyngen, opprett en egen administrator på den med "lisensieringstjenesten". Du kan sette inn en hasp-nøkkel for maskinvare i den bærbare datamaskinen, eller aktivere programvarelisenser.

Av størst interesse for programmerere bør være "Functionality Assignment Requirements".

Krav til den tildelte funksjonaliteten til 1c

Så på en bærbar datamaskin med en sikkerhetsnøkkel, for ikke å starte brukere på klyngeserveren, må du legge til "krav" for kravobjektet "Klientforbindelse til informasjonssikkerhet" - "Ikke tilordne", dvs. forhindre at arbeidsprosesser på denne serveren behandler klientforbindelser.

Enda mer interessant er muligheten til å kjøre "bare bakgrunnsjobber" på produksjonsserveren til klyngen uten brukerøkter. På denne måten kan høyt belastede oppgaver (kode) overføres til en egen maskin. Dessuten kan du kjøre en bakgrunnsoppgave med å "lukke måneden" ved å bruke "Verdi av en ekstra parameter" på en datamaskin, og bakgrunnsoppgaven "Oppdatering av fulltekstindeksen" på en annen skjer gjennom indikasjonen "Verdi av en ekstra parameter". Hvis du for eksempel angir BackgroundJob.CommonModule som en verdi, kan du begrense arbeidet til arbeiderserveren i klyngen til bare bakgrunnsjobber med noe innhold. BackgroundJob.CommonModule verdi.<Имя модуля>.<Имя метода>- vil indikere en bestemt kode.

Klynge 1C 8.2

Økter muliggjør belastningsbalansering og feiltoleranse i en administrert applikasjon.

Klyngelederen er nå blitt mer kompleks. Noen funksjoner kan nå separeres i en egen prosess og til og med plasseres på en annen fungerende server i klyngen. Dette lar deg balansere serverbelastningen.

Server 8.2-feiltoleranse oppnås gjennom:

  • Lagre informasjon om brukerens økt.
  • Brukeren er ikke lenger bundet til arbeidsflyten.
  • Reservering av arbeidsprosesser i en klynge.
  • Det bør være flere arbeidsprosesser, inkludert overflødige
  • Klyngereservasjon.

En reserveklynge er indikert når de er tilkoblet, de er oppført i tilkoblingslinjen

Dette lar deg sikre kontinuitet i arbeidet!

Hvis klientens fysiske forbindelse til klyngen er brutt (rengjøringsdamen trakk ut kabelen, strømmen til nettverksutstyret ble slått av, det var et problem med leverandøren), er det ikke nødvendig å koble til infobasen igjen og starte alt arbeidet på nytt. Etter at den fysiske tilkoblingen er gjenopprettet, kan brukeren fortsette å jobbe fra punktet der den ble avbrutt.

Hvis det er nødvendig med vedlikehold av klyngedatamaskiner, kan de slås av under drift uten å hindre brukere i å arbeide med informasjonsbasen.

Hvis en server i klyngen svikter, vil ikke brukerarbeidet stoppe det automatisk overført til backup-klyngen og/eller backuparbeidsprosessene. For brukere vil en slik overgang være usynlig.

Hvis en av klyngens arbeidsprosesser mislykkes, vil brukere som er koblet til den, automatisk bli overført til andre eller backup-arbeidsprosesser. En slik overgang vil også være usynlig for brukerne.

Begreper, begreper

Hvorfor trenger du en 1C-server?

Begrepet "serverklynge" refererer til flere datamaskiner (servere) som utfører en felles oppgave.

Oppgavene løst av 1C:Enterprise 8-serverklyngen er vist i figuren nedenfor.

Forskjellen mellom 8.1 og 8.2

Klynge 1C 8.1

1C:Enterprise 8.1-serverklyngen er en implementering av ideene om lastfordeling på servere som betjener klientforespørsler. Denne mekanismen fordeler belastningen på dataressurser innenfor én server eller flere servere ("Working Servers"), og sikrer dermed applikasjonsskalering. Serverklyngen dupliserer koden som betjener klientforbindelser. Klyngens dupliserte kjørbare kode heter "Worker Process" (rphost). Når du installerer en klynge, opprettes bare én arbeidsprosess.
Flere arbeidsprosesser på én server gjør det mulig å effektivt bruke mengden RAM og prosessorressurser til å utføre forespørsler, samt koble en klientøkt til en annen arbeidsprosess hvis den nåværende "krasjer".
Server Agent (ragent)-programmet er ansvarlig for å forstå hva som kjører på en bestemt server. Å stoppe serveragenten vil gjøre serveren utilgjengelig for bruk av klyngen. Agenten lagrer informasjonen sin i filen srvribrg.lst.
Informasjon om arbeidsdatabaser og involverte arbeidsprosesser eies av "Server Manager" (rmngr). Den lagrer denne informasjonen i filen 1CV8Reg.lst. Å stoppe serveradministratoren kan føre til omstart av klientapplikasjoner hvis manageren starter på nytt, eller til fullstendig stopp av fungerende servere til hele klyngen.
1C:Enterprise 8.1 gir mulighet for å lage flere uavhengige klynger på én server. Hver av dem identifiseres på nettverket av en unik "IP-port" og et unikt nummer i tjenestefiler. Den første klyngen mottar port 1541 som standard.
Enterprise Servers snap-in er laget for å administrere klyngen.
Du kan koble til servere med servernavn eller IP-adresse.

Serveragent

Serveragenten "vet" om alle klyngene som kjører på serveren. Denne informasjonen er lagret i filen srvribrg.lst med en liste over klynger og listeadministratorer. Hovedporten til agenten er 1540. På hver fungerende server kan bare én agent startes, som betjener alle mulige klynger på denne serveren.
For å få mer detaljert informasjon visuelt, bruk Process Explorer-verktøyet (utviklet av Sysinternals). Programmet lar deg ta en dypere titt i alle kjørende prosesser, inkludert en 1C:Enterprise 8.1-serverklynge.

Cluster Manager

Klyngeleder er ansvarlig for driften av klyngen. Hver klynge har sin egen Manager. Lederen lagrer informasjon om klyngen i filen 1CV8Reg.lst (klyngeregister). Hver Cluster Manager har også sin egen port på Work Server. For den første klyngen er standard Manager-port 1541. Det er denne porten som vises i snapin-modulen 1C:Enterprise Servers i Clusters-grenen, og identifiserer klyngen.
Lederen mottar forespørsler fra klientdelen av 1C:Enterprise 8.1 og tar en beslutning til hvilken arbeidsflyt som skal gi denne tjenesteforespørselen.

Lederen bruker tjenesteporten til å samhandle med arbeidsprosesser.

Arbeidsprosessen

Arbeidsprosessen er ansvarlig for å "arbeide med kunder." Vi kan si at i den forrige versjonen av 1C:Enterprise 8.0 var det bare én "Workflow".
Det kan være flere arbeidsprosesser i en 1C:Enterprise 8.1-klynge. Serveradministratoren bestemmer hvilken arbeidsprosess som skal betjene klientforbindelsen. For klientforbindelser er arbeidsprosesser som standard tildelt en rekke IP-porter 1560 – 1591. I tillegg er hver arbeidsprosess tildelt en tjenesteport for kommunikasjon med klyngelederen. Hver arbeidsprosess bruker opptil 2 Gb RAM i et 32-biters operativsystem. I et 64-bits operativsystem er begrensningen pålagt av den fysiske mengden RAM

Klynge 1C 8.2

Server cluster 1C:Enterprise 8.2 – videreutvikling av server 8.2 teknologier.

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

Og i tillegg har en ny tilnærming til serverdrift blitt implementert. Nå, i stedet for prosesser, spiller økter en viktig rolle.

Økter muliggjør belastningsbalansering og feiltoleranse i en administrert applikasjon.

Cluster Manager

Klyngelederen er nå blitt mer kompleks. Noen funksjoner kan nå separeres i en egen prosess og til og med plasseres på en annen fungerende server i klyngen. Dette lar deg balansere serverbelastningen.

Server 8.2-feiltoleranse oppnås gjennom:

  • Lagre informasjon om brukerens økt.
    • Brukeren er ikke lenger bundet til arbeidsflyten.
  • Reservering av arbeidsprosesser i en klynge.
    • Det bør være flere arbeidsprosesser, inkludert overflødige
  • Klyngereservasjon.
    • En reserveklynge er indikert når de er tilkoblet, de er oppført i tilkoblingslinjen

Dette muliggjør kontinuitet i driften:

Hvis klientens fysiske forbindelse til klyngen er brutt (rengjøringsdamen trakk ut kabelen, strømmen til nettverksutstyret ble slått av, det var et problem med leverandøren), er det ikke nødvendig å koble til infobasen igjen og starte alt arbeidet på nytt. Etter at den fysiske tilkoblingen er gjenopprettet, kan brukeren fortsette å jobbe fra punktet der den ble avbrutt.

Hvis det er nødvendig med vedlikehold av klyngedatamaskiner, kan de slås av under drift uten å hindre brukere i å arbeide med informasjonsbasen.

Hvis en server i klyngen svikter, vil ikke brukerarbeidet stoppe det automatisk overført til backup-klyngen og/eller backuparbeidsprosessene. For brukere vil en slik overgang være usynlig.

Hvis en av klyngens arbeidsprosesser mislykkes, vil brukere som er koblet til den, automatisk bli overført til andre eller backup-arbeidsprosesser. En slik overgang vil også være usynlig for brukerne.

Klynge 1C 8.3

Server 8.3 er preget av en nylig redesignet intern kode, selv om det "fra utsiden" kan virke som om det er en litt modifisert 8.2.

Serveren har blitt mer "autokonfigurerbar" noen parametere, for eksempel antall arbeidsprosesser, opprettes ikke lenger manuelt, men beregnes basert på beskrivelsene av kravene til feiltoleranse og pålitelighetsoppgaver.

Det er utviklet en lastbalanseringsmekanisme, som kan brukes enten til å øke ytelsen til systemet som helhet, eller for å bruke en ny "minnesparing"-modus, som lar deg jobbe "med begrenset minne" i tilfeller der konfigurasjonen brukt "liker å spise opp hukommelsen."

Driftsstabilitet ved bruk av store mengder minne vil bli bestemt av de nye parameterne til produksjonsserveren.

Parameteren "sikkert minneforbruk per samtale" er spesielt interessant. For de som har liten anelse om hva det er, er det bedre å ikke trene på en "produktiv" basis. Parameteren "Maksimal minnestørrelse for arbeidsprosesser" tillater, i tilfelle "overflyt", ikke å krasje hele arbeidsprosessen, men bare én økt "med taperen". "Mengden arbeidsprosessminne opp til som serveren anses som produktiv" lar deg blokkere nye tilkoblinger så snart denne minneterskelen er overskredet.

Jeg anbefaler å isolere arbeidsprosesser etter informasjonsbase, for eksempel ved å spesifisere parameteren "Antall informasjonssikkerhet per prosess = 1". Med flere høyt belastede databaser vil dette redusere gjensidig påvirkning både i pålitelighet og ytelse.

Et eget bidrag til systemets stabilitet er gitt av "utgifter" av lisenser/nøkler. I 8.3 ble det mulig å bruke en "software license manager", som minner om "aladin" manager. Målet er å kunne plassere nøkkelen på en egen maskin.

Den implementeres som en annen "tjeneste" i klyngelederen. Du kan for eksempel bruke en "gratis" bærbar datamaskin. Legg den til 1C 8.3-klyngen, opprett en egen administrator på den med "lisensieringstjenesten". Du kan sette inn en hasp-nøkkel for maskinvare i den bærbare datamaskinen, eller aktivere programvarelisenser.

Av størst interesse for programmerere bør være "Functionality Assignment Requirements".

Så på en bærbar datamaskin med en sikkerhetsnøkkel, for ikke å starte brukere på klyngeserveren, må du legge til "krav" for kravobjektet "Klientforbindelse til informasjonssikkerhet" - "Ikke tilordne", dvs. forhindre at arbeidsprosesser på denne serveren behandler klientforbindelser.

Enda mer interessant er muligheten til å kjøre "bare bakgrunnsjobber" på produksjonsserveren til klyngen uten brukerøkter. På denne måten kan høyt belastede oppgaver (kode) overføres til en egen maskin. Dessuten kan du kjøre en bakgrunnsoppgave med å "lukke måneden" ved å bruke "Verdi av en ekstra parameter" på en datamaskin, og bakgrunnsoppgaven "Oppdatering av fulltekstindeksen" på en annen skjer gjennom indikasjonen "Verdi av en ekstra parameter". Hvis du for eksempel angir BackgroundJob.CommonModule som en verdi, kan du begrense arbeidet til arbeiderserveren i klyngen til bare bakgrunnsjobber med noe innhold. BackgroundJob.CommonModule verdi.<Имя модуля>.<Имя метода>- vil indikere en bestemt kode.

Løse mulige installasjonsproblemer

Når du installerer 1C:Enterprise 8.1-serverdelen, kan du opprette en ny bruker eller velge en eksisterende konto.

I tilfelle du velger en eksisterende konto, må du oppgi riktig passord og bekreftelse, ellers vil start av backend resultere i en feil.
Når du kjører Cluster Agent for første gang, opprettes en standard klynge.
Standardklyngen har følgende egenskaper:
· portnummer – 1541;
· IP-portområde – 1560:1591;
· støtte for mange arbeidsflyter – deaktivert;
· én arbeidsprosess, portnummeret settes fra det angitte området.
Hvis det er noen problemer når du starter klyngeagenten, kan det hende at standardklyngen ikke opprettes. Dette viser seg ved at når serveragenten (ragent) starter, starter den, men starter ikke andre klyngeprosesser (rmngr, rphost). Listen over klynger srvribrg.lst ser slik ut:
{
{0},
I dette tilfellet kan du stoppe ragent-prosessen, slette listen over klynger (srvribrg.lst) og starte ragent på nytt.

Sjekk samsvaret mellom portene spesifisert i portparameteren på kommandolinjen for å starte serveragenttjenesten og de som er spesifisert i dialogboksen for sentrale serverparametere i klyngekonsollen:

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

Hvis serveragenten kjører som en applikasjon, kan den stoppes ved å trykke på Ctrl+C-tastekombinasjonen.
- Sørg for i Task Manager at alle prosesser ragent, rmngr, rphost er avsluttet. Om nødvendig, fullfør dem med Task Manager.

— Åpne egenskapene til 1C:Enterprise 8.1 Server Agent-tjenesten.

- Vær oppmerksom på linjen "Kjørbar fil" (bane til kjørbar fil). Den har -d-parameteren etterfulgt av klyngedatakatalogen. Alle filer relatert til klyngen ligger i denne katalogen.
- Slett alt innholdet i denne katalogen.
— Start 1C:Enterprise 8.1 Server Agent-tjenesten.
- Sørg for i Task Manager at alle prosesser ragent, rmngr, rphost har startet.
— Start klyngekonsollen og registrer den sentrale serveren i den. Konsollen skal koble til den sentrale serveren og vise én klynge opprettet som standard.
Mulige problemer med feilen i serverklyngen inkluderer problemer med sikkerhetsnøkler, servicekontorettigheter og feil oppstartsparametere.

  1. Serverbeskyttelsesnøkkelen er installert LOKALT på hver server i bedriften
  2. Ikke angi en tjenestekonto med et tomt passord
  3. Med flere klynger bør ikke portene som brukes overlappe hverandre

Vær oppmerksom på at under installasjonsprosessen av 1C:Enterprise 8.1-plattformen kan det vises feilmeldinger. De mest sannsynlige meldingene er oppført nedenfor. Årsakene som forårsaket meldingene og trinnene for å eliminere dem er angitt.

Feil 1069: Tjenesten kjører ikke på grunn av en påloggingsfeil

Problemet er knyttet til kontoens rettigheter til å kjøre som en systemtjeneste. Åpne verktøyet for lokal sikkerhetspolicy og legg til brukeren (på hvis vegne Cluster Work-serverne er lansert) til policyene pålogging som tjeneste og pålogging som batchjobb.
Hvis dataene som er lagret i tjenestefiler er skadet, kan starten av klyngens produksjonsservere mislykkes. Sørg for at 1C:Enterprise 8.1-serveragenten kjører (ragent-prosess i Task Manager).
Ikke glem at Windows Event Auditing også er et analyseverktøy. For å gjøre dette, se om noen "mistenkelige" meldinger vises i Windows-hendelsesloggen.

Feil 8007056B / 800708C5

Det nye passordet oppfyller ikke passordretningslinjene. Passordet kan være for kort eller du har allerede brukt dette passordet nylig.
Årsak: det spesifiserte passordet for kontoen i dialogboksen "Installer 1C:Enterprise server" oppfyller ikke kravene til sikkerhetspolicyen.
Løsning: Angi et nytt passord for den valgte kontoen som oppfyller kravene i sikkerhetspolicyen eller svekker kravene til den anvendte sikkerhetspolicyen, dvs. ikke kreve et "komplekst" passord, ikke begrens antall tegn i passordet, ikke sjekk gjentagelsesforsøk osv.

Feil 1923: Ingen rettigheter å installere av tjeneste

Årsak: Feilen er relatert til kontoens installasjonsrettigheter som applikasjoner. Denne feilen er typisk for forsøk på å installere en server på en domenekontroller der det kreves økte sikkerhetstiltak.
Løsning: Ikke bruk en domenekontroller til å være vert for bedriftsserveren eller løsne på sikkerhetskravene og spesifiser rettighetene "Kjør som en tjeneste" eller "Kjør som en batchjobb" for den valgte kontoen.

Feil 80070056

Passordet ditt kunne ikke endres. Hvert passord må brukes i minst x dager.
Årsak og løsning: En annen feil som oppstår når sikkerhetspolicykravene for passordene som brukes, brytes. Løsningen ligner feil 800708C5.

Windows Sockets - 11004(0x00002AFC)

1) Pass på at følgende kjører på klyngens arbeidsserver i oppgavebehandlingen:
Serveragent (ragent.exe),
Cluster Manager (rmngr.exe),
Klyngearbeidsprosess (rphost.exe).
2) For å sjekke oppløsningen av IP-adressenavnet, kjør på kommandolinjen:
ping maskinnavn
I systemets svar på kommandoen er vi interessert i å fastslå om IP-adressen er bestemt.
3) Hvis navnet er bestemt, men arbeidsprosessen fortsatt ikke finnes, må du kontrollere at IP-adressen til navnet er bestemt<имя машины>Og<имя машины>.<имя домена>er ikke definert annerledes.

(Windows Sockets - 10054(0x00002746).

Den eksterne verten lukket tilkoblingen med makt.
Denne meldingen kan mottas hvis serveren startes på nytt eller arbeidsprosessen tvinges til å bli slettet.
Denne feilen vises vanligvis ikke når du kobler til på nytt. Hvis feilen vedvarer, er det nødvendig å undersøke årsakene til feilen på klyngens produksjonsservere.
Denne feilen kan oppstå når en arbeidsprosess når maksimal minnekapasitet på 32-biters systemer.
Et annet tilfelle er et tilkoblingsforsøk fra en klient med en feilmelding:

(Windows Sockets - 10060(0x0000274C)

Et forsøk på å opprette en tilkobling mislyktes fordi... det nødvendige svaret ble ikke mottatt fra en annen datamaskin innen den nødvendige tiden, eller en allerede etablert tilkobling ble avsluttet på grunn av feil svar fra den allerede tilkoblede datamaskinen.
Essensen av denne feilen er mangelen på respons innen en viss tid (timeout).
1) Sørg for at brannmuren ikke blokkerer programtrafikk. Slå av brannmuren.
For å gjøre dette, kjør kommandoen på kommandolinjen (kommandoen er tilgjengelig fra Windows XP og Windows Server 2003; tidligere versjoner har ikke en innebygd brannmur, men tredjepartsprogramvare kan installeres):
netshbrannmursettopmodedeaktiver
Hvis kommandoen er vellykket, vil du motta en melding:
OK.
I tillegg til en brannmur kan nettverksfiltre blokkere trafikk. De er deaktivert som standard. Pass imidlertid på at det er slik:

  1. Åpne mappen Nettverkstilkoblinger.
  2. Høyreklikk nettverkstilkoblingen du vil konfigurere og velg Egenskaper.
  3. På fanen Er vanlig(for lokal nettverkstilkobling) eller på fanen Nett(for alle andre tilkoblinger) velg Internett-protokoll (TCP/IP) og trykk på knappen Egenskaper.
  4. Klikk på knappen I tillegg.
  5. Åpne fanen Alternativer, Velg et alternativ TCP/IP-filtrering og trykk på knappen Egenskaper.
  6. Pass på at avkrysningsboksen Aktiver TCP/IP-filtrering (alle adaptere) fjernet.

2) Pass på at prosessorressursene ikke er 100 % lastet (CPU%).
3) Mål nettverksaktiviteten til klient- og servergrensesnittene. Belastningen på nettverksadapteren bør ikke overstige 60 %.

(Windows Sockets - 10061(0x0000274D)

Forbindelsen er ikke etablert pga Destinasjonsdatamaskinen avviste tilkoblingsforespørselen.
En typisk årsak til denne feilen er fraværet av en kjørende serveragent. Start serveren manuelt eller start serveren på nytt for å starte automatisk.

Svar på spørsmål

Multiplattform 1C

Serverinstallasjon

Sp: Feil ved installasjon av 1c-server på MS Server 2008 R2 x64 Ved installasjon av 1c-server via kommandolinjen, for eksempel ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d "C:\Program Files\1cv82 \ (hentet fra ITS-disken), skriver kommandolinjen meldingen: "Feil! OpenSCManager-feil!" Tjenesten opprettes ikke i dette tilfellet. Testet 8.1.15.14 og 8.2.10.77

A: For å installere fra kommandolinjen på et operativsystem der UAC er til stede, må du bruke RunAs-tjenesten, fordi Selv om brukeren er medlem av administratorgruppen, blokkerer UAC handlinger som endrer systemtilstanden.

Beskyttelsesnøkler

Spørsmål: Tillater beskyttelsesnøkkelen for Server 8.2 meg å kjøre Server 8.1?
A: Ja, det gjør det

Spørsmål: For å starte en 1C-server, trenger jeg en slags server-hasp-nøkler? Lokalt, eller vil det ikke fungere for 5 brukere?

A: ja, serveren trenger sin egen nøkkel, lokal bruker og nettverksnøkler vil ikke fungere. Flere detaljer i « « , lysbilde nummer 30.

Spørsmål: La oss si at en 1C-serverklynge består av 3 fysiske servere. hvor mange sikkerhetsnøkler trengs?

Spørsmål: Det er en terminalserver og en nøkkel for 5 lisenser, en sjette tilleggslisens må kjøpes. tillatelse. Er det mulig å installere det på serveren ved siden av nøkkelen på 5? Og vil alle 6 brukerne jobbe i terminalsesjoner eller 5 - under terminalen, og 1 i filversjonen?
A: Nei, det vil de ikke. Den sjette lisensen i form av en lokal nøkkel må kobles til brukerens datamaskin, men ikke til terminalen.

1C-serveroppdateringer

Spørsmål: Når en ny versjon 8.2.xxx av plattformen er utgitt, hva er prosedyren for å oppdatere servere og klienter?
A: 8.2-distribusjoner installerer filene sine i forskjellige mapper (hver versjon har sin egen mappe), dvs. teoretisk sett er det fortsatt mulig å kalle flere versjoner av serveren parallelt.

Jeg hadde ingen problemer. Du må imidlertid nøye overvåke portene som er okkupert av 1C-serverforekomsten. Det skal ikke være kryss.

Sette opp 1C server

Spørsmål: I 1C 8.1, hva er den beste måten å plassere infobaser, hvis det er flere av dem, i en klynge eller opprette en egen klynge for hver database? A: Ved stort volum eller belastning må testdatabaser plasseres i separate klynger!

Spørsmål: SPØRSMÅL: Er 1C:Enterprise 8.1-arbeidsflyten en enkelt- eller flertråds applikasjon? De. kan mange kjerner lastes med én tilkoblet bruker? Med flere? Hva med 1C:Enterprise 8.2-arbeidsflyten? Takk skal du ha.
A: 1Сv8.exe og rphost.exe i versjon 8.1 forbrukte 1 kjerne. Siden klientforbindelsen i 8.1 er strengt knyttet til arbeidsprosessen, kan vi betinget anta at 1C-klientbehandling utføres innenfor en enkelt kjerne. Unntaket er DBMS, som bruker kjerner uavhengig av hvordan 1C-serveren fungerer.

I versjon 8.2 er tilkoblinger erstattet av økter. Økter kan allerede kjøre i forskjellige arbeidsprosesser. Derfor er det sannsynligvis ikke riktig å kalle 8.2 entrådet. Client 8.2 laster også visuelt flere kjerner, så dette:

Plattform 8.2 implementerer ikke alle egenskapene til et flertråds system, men den utnytter maskinvarekapasiteten mye bedre sammenlignet med 8.1, inkludert når det gjelder parallellitet.

Spørsmål: Er det nødvendig å ha flere 1C:Enterprise 8.1 arbeidsprosesser for databaseserveren (MS SQL) for å laste flere kjerner? (Det bemerkes at MS SQL vanligvis "laster" bare en kjerne, dvs. "parallellering" av behandlingen av en forespørsel på tvers av flere kjerner skjer som regel ikke.) Takk.
A: Det er ikke nødvendig å spesifikt administrere MS SQL, det er et ganske selvjusterende system som bruker ressurser etter behov. Du kan kontrollere utførelsesparallellisme:

EXEC sys.sp_configure N’max grad av parallellisme’, N’5′

REKONFIGURER MED OVERRID

Du kan opprette flere arbeidsprosesser på 1C-serveren basert på at én arbeidsprosess ikke gir mulighet for brukere å koble til på nytt i tilfelle arbeidsprosessen krasjer. Prosess 2 (på 8.2 er det bedre å gjøre det "backup") løser dette problemet. Men det er fornuftig å legge til en tredjedel eller flere arbeidsprosesser bare hvis de to første arbeidsprosessene er tungt belastet (mer enn 90%). Det er ingen vits i å multiplisere arbeidsprosesser unødvendig, dette kan forringe produktiviteten.

A: Det må være minst 1 backup arbeidsprosess i 8.2.

Failover-klynge

Spørsmål: Spørsmål om aktivering av redundans for 1s 8.2-klynger. Hvis serveren vår krasjet (rengjøringsdamen trakk ut ledningen), vil nettverksnavnet, for eksempel "server:2540" være utilgjengelig. Hvordan vet en klient hvis tilkoblingsstreng sier "server:2540" at den må koble til backup-klyngen? hvor får han navnet på den andre serveren? Hva om du skriver klynger atskilt med komma i databasetilkoblingsstrengen?
A: Flere klynger er kombinert til en "redundansgruppe". For dette formålet er det en "reservasjonsliste" i klyngens snap-in.

Når en klient først får tilgang til en klynge, får den en liste over klynger som er inkludert i redundansgruppen.

Hvis klienten aldri har kontaktet deg, må du i dette tilfellet spesifisere adressene til alle klynger manuelt, for eksempel storm:2541,monster:2541.

Synkroniserte data utveksles mellom redundansklynger.

Spørsmål: Hva skjer etter at hovedklyngen er gjenopprettet? når brukere byttet til backup.

A: De skal tilbake. Det kan være pauser under bytte mens du synkroniserer disse klyngene.

Bakgrunnsjobber

Spørsmål: Hvordan sletter jeg en bakgrunnsjobb som kjører på serverne 1C:8.1 og 1C:8.2?

Sv: Muligheten til å avbryte en rutineoppgave fungerer bare hvis koden kjøres i det innebygde 1C:Enterprise-språket. Hvis koden kjøres i eksterne biblioteker, kan ikke en slik oppgave kanselleres med unntak av å avslutte arbeidsflyten med makt. Hvis det i prosessen er en blokk StartTransaction() - CommitTransaction(), så er det usannsynlig. Andre bakgrunnsjobber kan slettes via jobbkonsollen.

Reguleringsprosedyrer

Spørsmål: Er det mulig å ødelegge basen under T&I?

A: Jeg er ikke klar over slike tilfeller, men IMHO alt er mulig. Derfor vil det være en god idé å ta en sikkerhetskopi før T&I.

Spørsmål: Vyacheslav, av hvilke grunner utfører du ikke reindeksering ved å bruke 1C Testing and Correction?
A: DBMS-funksjoner er bedre egnet for disse formålene, siden de i hovedsak også gjenoppbygger indekser, men ikke krever eksklusivt beslagleggelse av databasen.

Teknologimagasin

Q: God ettermiddag. Spørsmål fra et teknologimagasin: Jeg trenger å motta kopier av arbeidsstasjonsskjermer i tilfelle 1C-feil. Må jeg sette opp en teknologisk logg på arbeidsstasjoner for dette, eller er det kun for serveren?
A: Du kan bare konfigurere mottak av et skjermbilde når plattformen faller, og ikke når det er noen feil. Det er imidlertid ikke mye nytte i en slik operasjon, det er nok å samle unntakssituasjoner ved hjelp av en teknologisk logg. Samtidig kan de fleste feilene sees ved bruk av TZ på 1C-serversiden. Et unntak vil være hendelser som en "formatstrømfeil" knyttet til en utdatert metadatabuffer.

Problemer og feil

Spørsmål: Har du støtt på et problem - forsvinningen av rapportinnstillinger for brukere ved dynamisk oppdatering av konfigurasjoner på 8.2-plattformen. Noen anbefalinger til hvordan man kan håndtere dette?
A: Problemer knyttet til dynamisk oppdatering gjenspeiles i "1C-servere: Enterprise 8.1 og 8.2 - hva du skal spise med "), lysbilde nummer 60. Tøm cache. Kanskje i noen tilfeller er det nødvendig å forstå hvor nøyaktig brukerinnstillingene er lagret. Lagre eventuelt som binære data i informasjonsregisteret.

Spørsmål: Et relatert spørsmål, fordi... dette er relevant for filmodus: hvilke feil retter chdbfl.exe?
A: Dette er et feilkorrigeringsverktøy for datalagringsstruktur. Dette kan være en situasjon der for eksempel "Databasefilen er skadet.../1Cv8.1CD" vises. De. fikser korrupsjon av databasefil. Den utfører imidlertid ikke T&I-funksjoner. Jeg kjører chdbfl.exe hvis T&I ikke kjører vellykket.

Spørsmål: Fortell meg hvis du har støtt på et slikt problem. når det er et stort antall brukere i databasen (ca. 40) ved behandling av store dokumenter, for eksempel som gjenspeiler PO i reg. Står for ca 8000 linjer. Feilmeldingen er at det ikke er nok minne på enterprise 1C-serveren og brukeren som startet dette dokumentet faller av. Dokumentet kan deretter behandles først etter omstart av 1C-serveragenten.
A: Ser ut som minnelekkasjer:

1. Start 1C-serveren på nytt, øk antallet arbeidsprosesser, og behold bare denne ene databasen i klyngen.

2. Slå beholdningen i porsjoner, si 1000 linjer om gangen. Ved å bruke TZ, spor objekter som opptar minne ved begynnelsen av en operasjon, men frigjør ikke minne ved fullføring.

3. Installer x64-versjonen, øk mengden RAM, bytt til 8.2.

Spørsmål: Spørsmål om testing og ledelse. Er det mulig å kjøre "Referential Integrity Check" basert på URDB med valg basert på de overførte dataene? (dvs. i noen noder er det fysisk ingen objekter, men det er lenker til dem). Takk skal du ha!
A: Dette er dessverre ikke mulig ennå.

Spørsmål: Hvorfor løser ikke testing og fiksing alle problemene på en gang, må du kjøre det flere ganger?

A: Bare utviklere kan svare nøyaktig. Jeg driver T&I i henhold til regelverket (syklisk), så denne problemstillingen er lite relevant for meg. T&I må gjøres ikke bare én gang, men konstant, som "MOT for en bil."

Spørsmål: Er det forskjell mellom T&I 8.1 og 8.2?

A: I øyeblikket jeg skrev svaret og utgivelsen 8.2.10, vet jeg ikke forskjellen.

Spørsmål: Er det nødvendig å reindeksere under restrukturering?
A: Ikke nødvendig.

Annen

Spørsmål: Kjære herrer, har noen prøvd å speile databaser med MSSql 2008. Er det mulig?

Spørsmål om å tvinge frem delt minne på server 1s 8.2

A: Det er ikke nødvendig å tvinge noe, vil serveren forstå.

Spørsmål: For 1C:Enterprise 8.1 har det blitt lagt merke til situasjoner når filserverversjonen med "tunge" operasjoner på samme maskinvare og en enkelt bruker fungerer mye raskere enn klient-serverversjonen, når alle "lenker" (database server, 1C server :Enterprise og klient) er installert på samme server. Dessuten, når du utfører denne "tunge" operasjonen, er det ingen åpenbare maskinvareoverbelastninger (belastningen på prosessoren, minnet og harddiskene er minimal). Det vil si at det er mange maskinvareressurser, men det fungerer sakte. Hva kan vi "hvile mot"? Takk skal du ha.
A: Fordelen med klient-server-arkitekturen fra et ytelsessynspunkt er muligheten til å behandle klientforespørsler om data i PARALLELL. De. Strømningshastighet er ikke en indikator for å trekke generelle konklusjoner. Mekanismer som forbedrer samtidighet kan fortsatt redusere ytelsen noe innenfor en enkelt tråd.

For entydig å finne flaskehalsen i ditt tilfelle, må du skaffe arbeidsmengden til serverutstyret og sammenligne den i tid med de lengste operasjonene i klient-server-modus. Ofte er dette en overdreven overføring av data til klientsiden. De. I stedet for å utføre operasjoner på 1C-serveren, overføres data fra databasen gjennom serveren til klienten.

Hastigheten i én tråd av klient-server-versjonen vil bare innhente ytelsen til filversjonen. Det er verdt å takle dette problemet hvis operasjonstiden i absolutte tall måles på ikke mindre enn minutter. Optimalisering innen 1-3 sekunders spørringer er tvilsomt.

Spørsmål: Om forskjellen mellom Windows-terminalen og 1C-tynnklienten.
A: Inntil de fleste løsninger er HELT oversatt til 8.2, er det definitivt vanskelig å snakke om en praktisk sammenligning av disse teknologiene.

Det er klart at 1C-tynnklienten bør forbruke mindre trafikk og gi muligheten til å jobbe via nettet. Men dette er noe som ennå ikke er implementert, og terminalløsninger blir brukt veldig mye nå.

For konservative, pragmatiske prosjektledere som konverterer 8.1 til 8.2 - en terminalløsning. For små prosjekter med lave feilkostnader og en konfigurasjon implementert umiddelbart med administrerte skjemaer og tilgangskontrollsystemer, er en tynn klient å foretrekke IMHO.

Spørsmål: Hvordan gjennomføre belastningstesting nær reelle forhold? Tross alt kan du ikke tvinge brukere til å "klikke på noe."

A: 1C: Testsenter med et utvalg av de vanskeligste operasjonene, 100% reproduksjon er ikke nødvendig, klikkene i seg selv er ikke vanskelige, hovedsakelig gjennomføre og be om rapporter. Det vil være et eget webinar om testing. Jeg vil også fortelle deg mer detaljert.

05.04.2017 |

Klynge 1C 8.3

Først av alt, etter å ha installert 1C-klyngen, var det nødvendig å lage arbeidsflyter. Som det viste seg, begynte klyngeprosesser å bli opprettet automatisk avhengig av belastningen på databasen.

En testkjøring av bakgrunnsjobber i hoveddatabasen førte til at 1C-klyngen uendelig overbelastet rphost.exe og den ekstra rphost.exe ønsket ikke å bli opprettet. Etter å ha gravd gjennom innstillingene ble alt klart.

Maksimalt arbeidsflytminne er mengden minne som arbeidsprosesser kan bruke sammen. Du må være veldig forsiktig når du angir parameteren, målt i byte. Hvis du angir feil verdi (utilstrekkelig for normal brukerdrift), vil brukere få feilmeldingen "Ikke nok ledig minne på 1C-serveren." Du kan også få denne feilen når minnekvoten på 1C-serveren er tom.

Sikkert minneforbruk per samtale- lar deg kontrollere minneforbruket under et serveranrop, målt i byte. Hvis en samtale bruker mer minne enn forventet, vil denne samtalen bli fullført i 1C-klyngen uten å starte arbeidsprosessen på nytt (rphost.exe). Følgelig vil "taperen" som foretok serveranropet miste økten med 1C-databasen uten å påvirke arbeidet til andre brukere.

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

Mengden minne for arbeidsprosesser opp til som serveren anses som produktiv - hvis denne parameteren overskrides, vil serveren i 1C-klyngen slutte å akseptere nye tilkoblinger.

Antall informasjonssikkerhet per prosess- lar deg isolere informasjonsbaser for arbeidsprosesser. Som standard var den nåværende 1C-klyngen satt til "8", men i løpet av flere timers drift ble serveren veldig ustabil, brukerøkter frøs. Etter å ha isolert hver infobase (verdi - "1") forsvant problemene.

Antall tilkoblinger per prosess- Standardverdien er "128". Siden dagens database har en svært stor belastning av bakgrunnsoppgaver (logistikkberegninger, prislisteanalyse, konkurrentanalyse osv.), ble det besluttet å redusere antallet til "25".

Innstillingene til selve 1C-klyngen har endret seg litt:

Feiltoleransenivå- dette er antallet fungerende servere som kan svikte samtidig uten å få brukere til å krasje. Sikkerhetskopieringstjenester lanseres automatisk i det beløpet som er nødvendig for å sikre den angitte feiltoleransen. I sanntid blir den aktive tjenesten replikert til backuptjenestene.

Last delingsmodus- det er to alternativer for parameteren: "Prioritet etter ytelse" - mer serverminne brukes og ytelsen er høyere, "Prioritet etter minne" - 1C-klyngen sparer serverminne.

Server 8.3 er preget av en nylig redesignet intern kode, selv om det "fra utsiden" kan virke som om det er en litt modifisert 8.2.

Serveren har blitt mer "autokonfigurerbar" noen parametere, for eksempel antall arbeidsprosesser, opprettes ikke lenger manuelt, men beregnes basert på beskrivelsene av kravene til feiltoleranse og pålitelighetsoppgaver.

Dette reduserer sannsynligheten for feilkonfigurering av serveren og reduserer kvalifikasjonskravene for administratorer.

Det er utviklet en lastbalanseringsmekanisme, som kan brukes enten til å øke ytelsen til systemet som helhet, eller for å bruke en ny "minnesparing"-modus, som lar deg jobbe "med begrenset minne" i tilfeller der konfigurasjonen brukt "liker å spise opp hukommelsen."

Driftsstabilitet ved bruk av store mengder minne vil bli bestemt av de nye parameterne til produksjonsserveren.

Parameteren "sikkert minneforbruk per samtale" er spesielt interessant. For de som har liten anelse om hva det er, er det bedre å ikke trene på en "produktiv" basis. Parameteren "Maksimal minnestørrelse for arbeidsprosesser" tillater, i tilfelle "overflyt", ikke å krasje hele arbeidsprosessen, men bare én økt "med taperen". "Mengden arbeidsprosessminne opp til som serveren anses som produktiv" lar deg blokkere nye tilkoblinger så snart denne minneterskelen er overskredet.

Jeg anbefaler å isolere arbeidsprosesser etter informasjonsbase, for eksempel ved å spesifisere parameteren "Antall informasjonssikkerhet per prosess = 1". Med flere høyt belastede databaser vil dette redusere gjensidig påvirkning både i pålitelighet og ytelse.

Et eget bidrag til systemets stabilitet er gitt av "utgifter" av lisenser/nøkler. I 8.3 ble det mulig å bruke en "software license manager", som minner om "aladin" manager. Målet er å kunne plassere nøkkelen på en egen maskin.

Den implementeres som en annen "tjeneste" i klyngelederen. Du kan for eksempel bruke en "gratis" bærbar datamaskin. Legg den til 1C 8.3-klyngen, opprett en egen administrator på den med "lisensieringstjenesten". Du kan sette inn en hasp-nøkkel for maskinvare i den bærbare datamaskinen, eller aktivere programvarelisenser.

Av størst interesse for programmerere bør være "Functionality Assignment Requirements".

Krav til den tildelte funksjonaliteten til 1c

Så på en bærbar datamaskin med en sikkerhetsnøkkel, for ikke å starte brukere på klyngeserveren, må du legge til "krav" for kravobjektet "Klientforbindelse til informasjonssikkerhet" - "Ikke tilordne", dvs. forhindre at arbeidsprosesser på denne serveren behandler klientforbindelser.

Enda mer interessant er muligheten til å kjøre "bare bakgrunnsjobber" på produksjonsserveren til klyngen uten brukerøkter. På denne måten kan høyt belastede oppgaver (kode) overføres til en egen maskin. Dessuten kan du kjøre en bakgrunnsoppgave med å "lukke måneden" ved å bruke "Verdi av en ekstra parameter" på en datamaskin, og bakgrunnsoppgaven "Oppdatering av fulltekstindeksen" på en annen skjer gjennom indikasjonen "Verdi av en ekstra parameter". Hvis du for eksempel angir BackgroundJob.CommonModule som en verdi, kan du begrense arbeidet til arbeiderserveren i klyngen til bare bakgrunnsjobber med noe innhold. BackgroundJob.CommonModule verdi.<Имя модуля>.<Имя метода>- vil indikere en bestemt kode.

Klynge 1C 8.2

Økter muliggjør belastningsbalansering og feiltoleranse i en administrert applikasjon.

Klyngelederen er nå blitt mer kompleks. Noen funksjoner kan nå separeres i en egen prosess og til og med plasseres på en annen fungerende server i klyngen. Dette lar deg balansere serverbelastningen.

Server 8.2-feiltoleranse oppnås gjennom:

  • Lagre informasjon om brukerens økt.
  • Brukeren er ikke lenger bundet til arbeidsflyten.
  • Reservering av arbeidsprosesser i en klynge.
  • Det bør være flere arbeidsprosesser, inkludert overflødige
  • Klyngereservasjon.

En reserveklynge er indikert når de er tilkoblet, de er oppført i tilkoblingslinjen

Dette lar deg sikre kontinuitet i arbeidet!

Hvis klientens fysiske forbindelse til klyngen er brutt (rengjøringsdamen trakk ut kabelen, strømmen til nettverksutstyret ble slått av, det var et problem med leverandøren), er det ikke nødvendig å koble til infobasen igjen og starte alt arbeidet på nytt. Etter at den fysiske tilkoblingen er gjenopprettet, kan brukeren fortsette å jobbe fra punktet der den ble avbrutt.

Hvis det er nødvendig med vedlikehold av klyngedatamaskiner, kan de slås av under drift uten å hindre brukere i å arbeide med informasjonsbasen.

Hvis en server i klyngen svikter, vil ikke brukerarbeidet stoppe det automatisk overført til backup-klyngen og/eller backuparbeidsprosessene. For brukere vil en slik overgang være usynlig.

Hvis en av klyngens arbeidsprosesser mislykkes, vil brukere som er koblet til den, automatisk bli overført til andre eller backup-arbeidsprosesser. En slik overgang vil også være usynlig for brukerne.

Ofte kjører andre tjenester på maskinen sammen med 1C:Enterprise-serveren - en terminalserver, SQL-server, etc. Og på et tidspunkt spiser 1C:Enterprise-serveren, eller rettere sagt rphost-arbeiderprosessen, opp mer minne enn planlagt eller alt minnet. Noe som fører til en nedgang i andre tjenester og zombier på serveren. For å unngå slike situasjoner må du konfigurere automatisk omstart av 1C:Enterprise-serverarbeidsflyter

Løsning

1. Åpne administrasjonskonsollen til 1C Enterprise-servere;
2. Utvid det sentrale servertreet til klynger og velg klyngen som interesserer oss. I eksemplet er det bare én klynge;
3. Åpne egenskapene til den valgte klyngen og se følgende skjema

Egenskaper til 1C:Enterprise 8.3-serverklyngen

La oss se på eksemplet vist på bildet:

Restartintervall— tid etter at rphost-prosessen vil bli tvunget til å starte på nytt. Før prosessen avsluttes, startes en ny rphost-prosess, som alle tilkoblinger overføres til, og først da vil den gamle prosessen avsluttes. Dette vil ikke påvirke brukerens opplevelse på noen måte. Intervallet er angitt i sekunder, i eksemplet er 24 timer angitt.

Tillatt minnestørrelse— hvor mye minne arbeidsflyten kan fungere i uten problemer. Volumet er angitt i kilobyte, i eksemplet er verdien 20 gigabyte (faktisk er tallet for stort, og du må starte fra det spesifikke systemet, men gjennomsnittstallet er 4 GB). Så snart minnet som er opptatt av arbeidsprosessen overskrider den angitte verdien, begynner nedtellingen.

Intervall for overskridelse av tillatt minnekapasitet— etter at tidtakeren som ble startet etter å ha overskredet den tillatte mengden minne, teller ned den angitte tiden, vil en ny arbeidsprosess bli lansert, som alle tilkoblinger overføres til, den gamle prosessen er merket som deaktivert. Intervallet er angitt i sekunder, i eksemplet er 30 sekunder angitt.

Stopp deaktiverte prosesser etter— tiden etter at arbeidsflyten som er merket som deaktivert, stoppes hvis verdien er 0, vil prosessen ikke bli fullført. Intervallet er spesifisert i sekunder, i eksemplet er 60 sekunder angitt.

Etter å ha brukt innstillingene, trenger du ikke å starte servertjenesten på nytt, de brukes dynamisk.

Total

Slik setter vi opp automatisk omstart av 1C:Enterprise-serverarbeidsprosesser og får et mer stabilt system dersom det oppstår en minnelekkasje, vil arbeidet til en spesifikk sesjon avsluttes.

I noen situasjoner kan du også leke med innstillingene og forhindre en mulig serverkrasj hvis du gjør feil.

Først av alt, etter å ha installert 1C-klyngen, var det nødvendig å lage arbeidsflyter. Som det viste seg, begynte klyngeprosesser å bli opprettet automatisk avhengig av belastningen på databasen.

En testkjøring av bakgrunnsjobber i hoveddatabasen førte til at 1C-klyngen uendelig overbelastet rphost.exe og den ekstra rphost.exe ønsket ikke å bli opprettet. Etter å ha gravd gjennom innstillingene ble alt klart.

Maksimalt arbeidsflytminne er mengden minne som arbeidsprosesser kan bruke sammen. Du må være veldig forsiktig når du angir parameteren, målt i byte. Hvis du angir feil verdi (utilstrekkelig for normal brukerdrift), vil brukere få feilmeldingen "Ikke nok ledig minne på 1C-serveren." Du kan også få denne feilen når minnekvoten på 1C-serveren er tom.

Sikkert minneforbruk per samtale– lar deg kontrollere minneforbruket under et serveranrop, målt i byte. Hvis en samtale bruker mer minne enn forventet, vil denne samtalen bli fullført i 1C-klyngen uten å starte arbeidsprosessen på nytt (rphost.exe). Følgelig vil "taperen" som foretok serveranropet miste økten med 1C-databasen uten å påvirke arbeidet til andre brukere.

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

Mengden minne for arbeidsprosesser opp til som serveren anses som produktiv - hvis denne parameteren overskrides, vil serveren i 1C-klyngen slutte å akseptere nye tilkoblinger.

Antall informasjonssikkerhet per prosess– lar deg isolere informasjonsbaser for arbeidsprosesser. Som standard ble gjeldende 1C-klynge satt til " 8 ", men i løpet av flere timers drift oppførte serveren seg veldig ustabilt, brukerøkter frøs. Etter å ha isolert hver infobase (verdi – “1”) forsvant problemene.

Antall tilkoblinger per prosess- standardverdi " 128 «. Siden dagens database har en svært stor belastning av bakgrunnsoppgaver (logistikkberegninger, prislisteanalyse, konkurrentanalyse osv.), ble det besluttet å redusere antallet til "25".

Innstillingene til selve 1C-klyngen har endret seg litt:

Feiltoleransenivå– dette er antallet fungerende servere som samtidig kan svikte, og dette vil ikke føre til unormal oppsigelse av brukere. Sikkerhetskopieringstjenester startes automatisk i det beløpet som er nødvendig for å sikre den angitte feiltoleransen. I sanntid replikeres den aktive tjenesten til backuptjenestene.

Last delingsmodus– det er to alternativer for parameteren: "Prioritet etter ytelse" - mer serverminne brukes og ytelsen er høyere, "Prioritet etter minne" - 1C-klyngen sparer serverminne.

Server 8.3 er preget av en nylig redesignet intern kode, selv om det "fra utsiden" kan virke som om det er en litt modifisert 8.2.

Serveren har blitt mer "autokonfigurerbar" noen parametere, for eksempel antall arbeidsprosesser, opprettes ikke lenger manuelt, men beregnes basert på beskrivelsene av kravene til feiltoleranse og pålitelighetsoppgaver.

Dette reduserer sannsynligheten for feilkonfigurering av serveren og reduserer kvalifikasjonskravene for administratorer.

Det er utviklet en lastbalanseringsmekanisme, som kan brukes enten til å øke ytelsen til systemet som helhet, eller for å bruke en ny "minnesparing"-modus, som lar deg jobbe "med begrenset minne" i tilfeller der konfigurasjonen brukt "liker å spise opp hukommelsen."

Driftsstabilitet ved bruk av store mengder minne vil bli bestemt av de nye parameterne til produksjonsserveren.

Parameteren "sikkert minneforbruk per samtale" er spesielt interessant. For de som har liten anelse om hva det er, er det bedre å ikke trene på en "produktiv" basis. Parameteren "Maksimal minnestørrelse for arbeidsprosesser" tillater, i tilfelle av "overflyt", ikke å krasje hele arbeidsprosessen, men bare én økt "med taperen". "Mengden arbeidsprosessminne opp til som serveren anses som produktiv" lar deg blokkere nye tilkoblinger så snart denne minneterskelen er overskredet.

Jeg anbefaler å isolere arbeidsprosesser etter informasjonsbase, for eksempel ved å spesifisere parameteren "Antall informasjonssikkerhet per prosess = 1". Med flere høyt belastede databaser vil dette redusere gjensidig påvirkning både i pålitelighet og ytelse.

Et eget bidrag til systemets stabilitet er gitt av "utgifter" av lisenser/nøkler. I 8.3 ble det mulig å bruke en "software license manager", som minner om "aladin" manager. Målet er å kunne plassere nøkkelen på en egen maskin.

Den implementeres som en annen "tjeneste" i klyngelederen. Du kan for eksempel bruke en "gratis" bærbar datamaskin. Legg den til 1C 8.3-klyngen, opprett en egen administrator på den med "lisensieringstjenesten". Du kan sette inn en hasp-nøkkel for maskinvare i den bærbare datamaskinen, eller aktivere programvarelisenser.

Av størst interesse for programmerere bør være "Functionality Assignment Requirements".

Krav til den tildelte funksjonaliteten til 1c

Så, på en bærbar datamaskin med en sikkerhetsnøkkel, for ikke å starte brukere på klyngeserveren, må du legge til "krav" for kravobjektet "Klientforbindelse til informasjonssikkerhet" - "Ikke tilordne", dvs. forhindre at arbeidsprosesser på denne serveren behandler klientforbindelser.

Enda mer interessant er muligheten til å kjøre "bare bakgrunnsjobber" på produksjonsserveren til klyngen uten brukerøkter. På denne måten kan høyt belastede oppgaver (kode) overføres til en egen maskin. Dessuten kan du kjøre en bakgrunnsoppgave med å "lukke måneden" ved å bruke "Verdi av en ekstra parameter" på en datamaskin, og bakgrunnsoppgaven "Oppdatering av fulltekstindeksen" på en annen skjer gjennom indikasjonen "Verdi av en ekstra parameter". Hvis du for eksempel angir BackgroundJob.CommonModule som en verdi, kan du begrense arbeidet til arbeiderserveren i klyngen til bare bakgrunnsjobber med noe innhold. BackgroundJob.CommonModule verdi.<Имя модуля>.<Имя метода>– vil indikere en bestemt kode.