Denne feilen med kode 10054, av kritisk karakter, manifesterer seg hos brukere på opptakstidspunktet. Finnes oftest i gamle utgivelser av 1C 8.2.
Skjermbilde av feil 10054:
Generelt indikerer utseendet på denne feilen at en handling uventet for utvikleren av 1C-serveren finner sted:
- en feil forespørsel kommer;
- feil data;
- en forespørsel som forårsaker en stor prøve som den ikke kan oppfylle;
- spesialtilfelle: dokumentnummeret var større enn lengden angitt i telleren;
- sjekk arbeidet med deaktiverte antivirus eller brannmurer
Korreksjon:
Er å lokalisere problemet så mye som mulig:
- bestemme type dokument,
- registeret som feilen oppstår med,
- bruker,
- datamaskin.
Deretter lages en kopi av databasen (ved hjelp av 1C eller DBMS).
Hvis omstart av serveren løser problemet, fortsett overvåkingen. Legg til et skript for å starte tjenesten på nytt om natten utenom åpningstidene.
Hvis omstarten er syklisk, sjekk om du har konfigurert automatisk omstart i klyngeegenskapene:
Det gjennomføres testing og korrigering med omberegning av totaler og reindeksering av tabeller. 
Den gamle kopien av databasen er hevet, der problemet observeres, forskjellene kontrolleres, kanskje dette vil føre til årsaken.
Hvis problemet vedvarer, er neste trinn å konfigurere og analysere teknologiloggen.
Hva kan bli funnet ut i prosessen:
Hvis belastningen på serveren er på grensen til 100 %, vurder muligheten for å skille databaseserveren og 1C-serveren, dette bremser vanligvis ned, men stabiliserer arbeidet (i 8.3 er det en delt minnemekanisme som øker hastigheten på interaksjonen mellom serveren og).
- Legg til minne til serveren hvis mulig.
- En mulig løsning vil være å erstatte serveren med en 64-biters, men sjekk først funksjonaliteten med vennene dine, hvor den står.
- Den samme kontrollen på 32-bit skader ikke for å forstå en feil i dataene eller en spesifikk server.
- Lossing med lasting kan eliminere manifestasjonen.
- Som en siste utvei bør du vurdere å migrere data ved å konvertere data eller laste inn data på nytt til en arbeidskopi (lang prosedyre)
Sjekk Windows-loggene for systemfeil:
- i nettverket
- utstyr
- vedlegg
- start rutere, brytere på nytt (sjelden, men det er problemer i dem)
Hvis problemet ikke er løst på kort tid, kan det hende du trenger hjelp fra sertifiserte administratorer eller 1C-eksperter.
Feilbeskrivelse
server_addr = tcp: //<имясервера>: 1562 descr = Feil i nettverkstilgang til server (Windows Sockets - 10054 (0x00002746). Ekstern vert tvangsavsluttet eksisterende tilkobling.) Linje = 1031 fil =. \ Src \ DataExchangeTcpClientImpl.cpp
Hvordan håndtere dette problemet
Konfigurer den teknologiske loggen og analyser loggene.
De vanligste årsakene er fallet av serverdelen av 1C: Enterprise.
Du kan også forsikre deg om ved å se om dumps blir opprettet (se på banen logcfg.xml, hvis dump-innstillingen er fraværende i den, så i % USERPROFILE% \ Local Settings \ Application Data \ 1C \ 1Cv81 \ Dumps-katalogen, for eksempel C: \ Dokumenter og innstillinger \<Имя пользователя>\ Local Settings \ Application Data \ 1C \ 1Cv81 \ dumps. Plattformkrasj kan oftest oppstå på grunn av forespørsler med ikke-standard parametere. Send dumps til 1C teknisk støtte e-post: [e-postbeskyttet]
1. Oftest møtte jeg et problem i dokumentloggen i valgene, forespørslene var lik denne:
VELG TILLATT TOPP 35 R.Date_Time A1,
R.nummer A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
R.Fld9605 A13,
R.Dokument A14,
R. Merket A15,
R.Posted A16, CAST (R.Fld9608 AS REF (Reference9)). Beskrivelse
A17, CAST (R.Fld9606 AS REF (Reference52)). Beskrivelse A18, CAST (R.Fld9611)
SOM REF (Referanse93)) Beskrivelse A19, CASE NÅR R.Fld9609 REFS
Reference53 SÅ CAST (R.Fld9609 AS REF (Reference53)) Beskrivelse NÅR
R.Fld9609 REFS Referanse150 SÅ CAST (R.Fld9609 AS
REF (Reference150)) Beskrivelse NÅR R.Fld9609 REFS Reference63 THEN
CAST (R.Fld9609 SOM REF (Reference63)). Beskrivelse NÅR R.Fld9609 REFS
Referanse114 SÅ CAST (R.Fld9609 SOM REF (Referanse114)) Beskrivelse SLUTT
A20, CAST (R.Fld9605 AS REF (Reference79)) Beskrivelse A21
FRA DocumentJournal9604 R HVOR
((R.Fld9605 = 79:)) OG
(R.Date_Time> DATETIME (2006,12,31,12,0,0) ELLER (R.Date_Time =
DATOTIME (2006,12,31,12,0,0) OG (R.Document> =
343:)))
BESTILL ETTER A1 ASC, A14 ASC '
2. Et eksempel på TJ-loggen som viser årsaken til serverkrasj ved oppdatering av fulltekstsøk
11: 40.9690-0, EXCP, 1, prosess = rphost, p: prosessnavn =<база данных>, t: clientID = 3, t: applicationName = BackgroundJob, t: connectID = 27, Usr = DefUser, DumpFile = C: \ Program Files (x86) \ 1cv81 \ dumps \ rphost_8.1.13.41_7d4e2366_0902 = Context1 '0902 '.
CommonModule.RegularJobs-modul: 46: Full-textSearch.UpdateIndex (False, True); '
Den endelige løsningen i dette eksemplet er å deaktivere bakgrunnsprosessen i problemdatabasen. Vent på den nye plattformutgivelsen og oppdateringen.
For mer informasjon om plattformkrasj, se bloggen min.
3. Et eksempel på TJ for syklisk omstart av prosesser. For å analysere denne hendelsen på datamaskinen til 1C: Enterprise-serveren, må du aktivere en oppføring i PROCs teknologiske hendelseslogg (eksempel på logcfg.xml-filen).
Når prosessen er stengt, vil en PROC-hendelse med egenskapen Txt = Process become disable vises.
Når prosessen stopper, vil en PROC-hendelse vises med egenskapen Txt = Process terminated. Eventuelle ferdige klienter med feil. Hvis brukerkrasj faller sammen med utdata fra denne hendelsen, er årsaken tvungen stopp av arbeidsflyten enten av administratoren (via klyngekonsollen) eller på grunn av en automatisk omstart.
4. Pass på at årsaken ikke er/er administratorens handlinger i konsollen
—————————-
Nedenfor er en variant av en kollegas løsning.
Til alle interessert i å løse problemer med plattformkrasj med feil:
10051, 10053, 10054, 10064
Som vist ved analyse av flyreiser på plattformfall, med feilene ovenfor:
– De fleste krasjene skyldes nettopp arbeidet med bakgrunnsjobber, som foreslått i temaet.
- Ikke nok lagringsplass
- Tilstedeværelsen av et stort antall ufullstendige transaksjoner i 1C-loggen
- Før du analyserer en teknologisk logg, analyser bakgrunnsjobbene som brukes i konfigurasjonen og deaktiver de du ikke trenger for arbeid, konfigurasjoner (forsvinnende, å analysere 14 GB søppel kan betraktes som et tidsfordriv hvis du ikke har noe å gjøre ... : ))))
- Analyser og foreta rettelser til bakgrunnsoppgavene du har lagt til, sørg for at de fullføres med en normal utgangskode (ingen feil og ikke lukkede transaksjoner)
- Legg til kodebiter til bakgrunnsjobbalgoritmene som med makt minne brukt under arbeidet
- Analyser og LØS YTELSESPROBLEMER for typiske bakgrunnskonfigurasjonsjobber
- Utfør rutineprosedyrer med databasen, gjennom menypunktet Administrasjon-Test og reparasjon, ikke glem nødvendigvis, komprimer databasen
- Analyser hvor mye plass som brukes av SQL-serveren, det er sannsynlig at serveren rett og slett er tom for minne
- Sjekk Active Directory-konfigurasjonspolicyer
- Og også krympe / skylle SQL-transaksjonsloggen med noe sånt som dette (for SQL 2000):
Valg 1:DBCC SHRINKFILE (pubs_log, 2)
(Hvis ønsket størrelse ikke oppnås, prøv alternativ 2) Alternativ 2:BACKUP LOGG puber MED TRUNCATE_ONLY
DBCC SHRINKFILE (pubs_log, 2)
Der pub_log er navnet på databasen din
Alternativ 3:
sp_detach_db - koble fra databasen med denne prosedyren, og sp_attach_db - koble til igjen. Dette vil tømme transaksjonsloggen.
(For mer informasjon, se MSDN-seksjonene Q256650 (for SQL 7.0) og Q272318 (for SQL 2000).)
Alternativ 4: (For 7.0)
DBCC SHRINKFILE (filnavn, målstørrelse)
DBCC SHRINKDATABASE (databasenavn, målprosent)
BACKUP LOGG databasenavn MED TRUNCATE_ONLY
Hvis fallet fortsetter etter disse operasjonene, fortsett å følge anbefalingene:
- Prøv å gjøre endringer i HOSTS-filene til operativsystemet (mest sannsynlig vil det være nok å skrive assosiasjonen kun til filer på en eller to maskiner, der krasjer oppstår oftest)
- Prøv å spre serverne 1C Enterprise og SQL, hvis de er på samme maskin.
- Eller tvert imot, installer dem på samme maskin (hvis det er nok ressurser) Det er tilfeller når det var overføring av servere til en server som hjalp (Etter min mening er det veldig tvilsomt og forholder seg mer presist til grunn til å starte arbeidet, dette er komprimering av transaksjonslogger)
- Sjekk serverens responstid (mest sannsynlig vil alt være innenfor normale grenser, og sjeldne feil i tjenestetiden kan ikke påvirke driften av bedriftsserveren så mye)
- Sjekk driften av ruterne i nettverket (sjelden, men det hender at rekonfigureringen deres påvirker antall krasj)
- Sjekk for maskinvarekonflikter i nettverket (dette er på spørsmålet om hvorfor det er ønskelig å ha utstyr fra én leverandør på nettverket. Hvem ønsker å sjekke f.eks. i 3COM teknisk dokumentasjon står det skrevet: om et nettverkskort oppdager at det samhandler med et lignende nettverkskort, så kan det byttes til en mer produktiv modus, på grunn av overgangen til en optimalisert algoritme for behandling av nettverkspakker, testet på personlig erfaring et hopp i ytelse på opptil 50 %)
- Sjekk signalnivåene til forbrukere / sluttdatamaskiner (det kan være trivielt, lavt signalnivå, konstant gjentatte blokkeringsforespørsler, forsinkelser i tjenestekøen i nettverket, og derfor til slutt motta en melding om at sluttserveren droppet tilkobling når antall forsøk overstiger ventetiden Hvis du vil forstå dette problemet, se Ethernet / CSMA CD / CSMA-protokollen Antall forsøk på å overføre en pakke ved hjelp av denne protokollen er ikke uendelig ...))) Og bufferen i kortene er heller ikke ubegrenset.)
- Legg til minne til serveren
- Sett noen/alle brukere i terminalmodus (dvs. sørg for at MANGE brukere definerer det som en THIN CLIENT 1C). Som en slik server vil jeg anbefale Citrix Metaframe eller Terminal Server MS
Mest sannsynlig, når du følger disse anbefalingene, med unntak av å analysere problemer med maskinvare, vil stabiliteten i arbeidet øke så mye at plattformfall vil bli svært sjeldne, noe som vil blokkere de teknologiske hullene for databasevedlikehold, som du fortsatt MÅ utføre og tror ikke at de anbefalingene som er angitt ovenfor Et universalmiddel for alle problemer.
De vil løse mange, men ikke alle, problemer.
Og du er glad, hvis du ikke har slike problemer, vil den som har dem forstå meg.
———————————
Undersøk rollene til "Brukeren", hvis de er i den typiske konfigurasjonen, selvfølgelig, og spesielt etter beregning problem dokumentbruker, må du finne den problematiske rollen (hvem klager).
Deretter, for brukerrollen, ser vi på radaren til dokumentet, hvis det ikke er noen ekstra innstillinger (rent), høyreklikk på den - søk etter lenker til objektet, og se sekvensielt radaren for "Brukeren" rolle for hvert objekt.
Misforståelse av høy brukerintensitet for protokollangrep i noen Windows-tilfeller.
> Kjør regedit.exe, legg til en ny DWORD-verdi kalt SynAttackProtect til registernøkkelen HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ og tilordne den verdien 00000000
Det er fornuftig å gjøre for Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx
1C-server og database på én maskin som kjører Debian Squeeze.
Løsning på problemet: sett tcp_syncookies kjerneparameter til 0.
[e-postbeskyttet]: ~ # echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(forfatter Vadim Ivakhin)
En ganske vanlig feil ved bruk av 1C 8.2 i klient-server-modus er at den eksterne verten tvangsavbrutt den eksisterende tilkoblingen. Typisk tar kundeadministratorer fra bedriftssektoren kontakt, d.v.s. hvor 20 eller flere jobber drives.
I 98 % av tilfellene er denne feilen knyttet til omstart av arbeidsflyten. Det kan være flere grunner til at den starter på nytt, men den vanligste er en banal planlagt omstart. På grunn av veksten av arbeidsflytfilen rphost og den påfølgende kraftige nedgangen i arbeidet som fulgte denne veksten, prøver administratorer å løse problemet ved å starte arbeidsprosesser på nytt, og umiddelbart møte en annen - frakoblingen av arbeidsbrukere. Å lage en ekstra arbeidsflyt gjør ingenting fordi i motsetning til den offisielle dokumentasjonen for å bytte en tykk klient til en annen arbeidsflyt skjer ikke... Dessuten er det en økt belastning på prosessoren - det er nødvendig å håndtere kontekstbryteren. 1C anbefaler forresten selv én arbeidsflyt for 50-100 brukere.
1) for å frigjøre minnet som er okkupert av 1C-arbeidsprosessen, bruk den automatiske omstarten av arbeidsprosessene. Det anbefales å starte arbeiderprosessene på nytt én gang om dagen (hvert 86400 sekund). Samtidig slås først arbeidsflyten av (nye tilkoblinger til den er umulige, gamle fortsetter å fungere) og en ny startes. Deretter, når alle tilkoblinger til den gamle prosessen er lukket, avsluttes prosessen. Vær samtidig oppmerksom på at nedtellingen av de samme 86400 begynner fra det øyeblikket tjenesten starter. Serveragent 1C Enterprise... De. det er ønskelig å starte den om natten.
2) ikke bruk mer enn én arbeidsflyt hvis du har opptil 100 brukere. Med et større antall arbeidsprosesser blir CPU-tid bortkastet på kontekstbytte mellom dem.
3) tømme brukt minne... I den raske veksten av minnet som er okkupert av rphost-prosessen, er uforsiktig skrevet konfigurasjon oftest skylden; ofte gidder ikke programmerere å tømme det okkuperte minnet, spesielt under verditabeller, oppregninger og matriser. Dette er spesielt tydelig når det skjer i bakgrunnsjobber. Derfor, når du analyserer problemet med minnelekkasjer, er det nødvendig å starte med dem, for eksempel ved å deaktivere dem i infobase-egenskapene i noen tid.
4) bruk separate servere for SQL og 1C. Som du vet, er det aldri mye minne for SQL.
Du bør være oppmerksom på de bemerkede tilfellene av "Ekstern vert tvangskoblet fra" feilen pga høy utnyttelse av nettverksutstyr... Når serverens responstid øker til 150-300 ms eller mer, kobles tilkoblingen fra på grunn av tidsavbrudd. Dette skjedde for eksempel når flere brukere samtidig laster ruteren som også 1C-serveren er koblet til ved å kopiere store filer. Administratorer bør vurdere muligheten for en slik situasjon, og ta hensyn til hastigheten på byttestoffet når de kjøper rutere.
Avslutningsvis vil jeg legge til at installasjonen og konfigurasjonen av serveren er en ansvarlig virksomhet, som krever kunnskap og erfaring, det er bedre å overlate det til fagfolk. Ekspertene våre utfører en nøkkelferdig serverinstallasjon, for flere detaljer se avsnittet.
