De externe host heeft de bestaande octopus-verbinding met geweld beëindigd. De externe host heeft de bestaande verbinding met geweld beëindigd

Foutbeschrijving

server_addr=tcp://<имясервера>:1562 descr=Fout netwerktoegang tot de server (Windows Sockets - 10054(0x00002746). De externe host heeft de bestaande verbinding geforceerd beëindigd.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp

Hoe om te gaan met dit probleem

Stel het technologische logboek in en ontleed de logboeken.
Meest algemene oorzaken er zijn crashes van het servergedeelte van 1C: Enterprise.
U kunt ook controleren of er dumps worden gemaakt (kijk naar het pad logcfg.xml, als er geen dumpinstelling in staat, dan in de map %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps, bijvoorbeeld C :\ Documenten en instellingen\<Имя пользователя>\Local Settings\Application Data\1C\1Cv81\dumps. Platformcrashes kunnen meestal optreden als gevolg van verzoeken met niet-standaard parameters. Stuur dumps naar e-mail voor technische ondersteuning van 1C: [e-mail beveiligd].
1. Meestal kwam ik een probleem tegen in het journaal met documenten in de selectieverzoeken die vergelijkbaar waren met dit:

SELECTEER TOEGESTAAN TOP 35 R.Date_Time A1,
R.Nummer A2,
R.Fld9608A3,
R.Fld9613 A4,
R.Fld9606A5,
R.Fld9610 A6,
R.Fld9611A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609A12,
R.Fld9605 A13,
R.Document A14,
R. Gemarkeerd A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Beschrijving
A17,CAST(R.Fld9606 ALS REF(Referentie52)).Beschrijving A18,CAST(R.Fld9611
AS REF(Reference93)).Beschrijving A19, CASE WANNEER R.Fld9609 REFS
Referentie53 DAN CAST(R.Fld9609 AS REF(Referentie53)).Beschrijving WANNEER
R.Fld9609 REFS Referentie150 DAN CAST(R.Fld9609 AS
REF(Referentie150)).Beschrijving WANNEER R.Fld9609 REFS Referentie63 DAN
CAST(R.Fld9609 AS REF(Reference63)).Beschrijving WANNEER R.Fld9609 REFS
Referentie114 DAN CAST(R.Fld9609 AS REF(Referentie114)).Beschrijving EINDE
A20,CAST(R.Fld9605 ALS REF(Referentie79)).Beschrijving A21
VAN DocumentJournal9604 R WAAR
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) EN
(R.Date_Time > DATETIME(2006,12,31,12,0,0) OF (R.Date_Time =
DATETIME(2006,12,31,12,0,0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
BESTELLEN PER A1 ASC, A14 ASC'

2. Een voorbeeld van een TJ-logboek waarin de oorzaak van servercrashes wordt weergegeven bij het bijwerken van zoeken in volledige tekst
11:40.9690-0,EXCP,1,proces=rphost,p:procesnaam=<база данных>,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:\Program Files (x86)\1cv81\dumps\rphost_8.1.13.41_7d4e2366_20090609021136_10236.mdmp,Context='
GeneralModule.RegularAssignmentModule: 46: FullTextSearch.UpdateIndex(False, True);'

De uiteindelijke oplossing in dit voorbeeld zou zijn om het achtergrondproces in de probleembasis uit te schakelen. Wacht op een nieuwe release van het platform en update.
Zie mijn blog voor meer informatie over platformcrashes.
3. Voorbeeld van TJ voor cyclische herstart van processen. Om deze gebeurtenis op de computer van de 1C:Enterprise-server te analyseren, moet u opname inschakelen in het PROC-gebeurtenislogboek (voorbeeld van het bestand logcfg.xml).
Wanneer een proces wordt afgesloten, wordt een PROC-gebeurtenis uitgezonden met de eigenschap Txt=Proces wordt uitgeschakeld.
Wanneer een proces wordt beëindigd, wordt een PROC-gebeurtenis uitgezonden met de eigenschap Txt=Proces beëindigd. Alle clients eindigden met een fout. Als gebruikerscrashes samenvallen met de uitvoer van deze gebeurtenis, is de reden dat het werkproces is gedwongen te stoppen door de beheerder (via de clusterconsole) of vanwege een automatische herstart.
4. Zorg ervoor dat de oorzaak wel/niet de acties van de beheerder in de console zijn

—————————-

Hieronder de oplossing van een collega.

Iedereen geïnteresseerd bij het oplossen van problemen met platformcrashes met fouten:

10051, 10053, 10054, 10064

Zoals blijkt uit de debriefing over platformvallen, van bovenaf aangegeven fouten:

- De meeste crashes worden precies veroorzaakt door het werk van achtergrondbanen, zoals gesuggereerd in het onderwerp.

- gebrek aan grip schijf ruimte

- Aanwezigheid een groot aantal onvolledige transacties in het 1C-journaal

- Voordat u het technologische logboek analyseert, analyseert u de achtergrondtaken die in de configuratie worden gebruikt en schakelt u de taken uit die u niet nodig hebt om te werken, de configuratie (het is afgezaagd, het analyseren van 14 GB aan afval kan als een tijdverdrijf worden beschouwd als u niets te doen heeft ... :))))

— Analyseer en corrigeer de achtergrondtaken die u hebt toegevoegd, zorg ervoor dat ze worden voltooid met een normale exitcode (geen fouten en geen gesloten transacties)

- Introduceer codefragmenten in de algoritmen van achtergrondtaken die beschermen, met geweld, het geheugen dat wordt gebruikt tijdens hun werk (je moet niet hopen dat 1C het gebruikte geheugen aan het einde vrijgeeft)

— Analyseer en verhelp FUNCTIONELE PROBLEMEN in typische configuratietaken op de achtergrond

- Voer routinematige procedures uit met de database, vergeet niet via het menu-item Administratie-Tests en correcties Nodig, comprimeer de database

- Analyseer de hoeveelheid gebruikte ruimte SQL-server, is het waarschijnlijk dat de server simpelweg niet genoeg geheugen heeft

- Controleer de beleidsinstellingen Active Directory

- En ook het logboek comprimeren/wissen SQL-transacties Hier is zoiets als deze code (voor SQL 2000):

Optie 1:DBCC SHRINKFILE(pubs_log, 2)
(Als juiste maat niet bereikt probeer optie 2) Optie 2:BACK-UP LOG-pubs MET TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

Waar pub_log de naam is van uw database

Optie 3:
sp_detach_db - ontkoppel de basis met deze procedure, en sp_attach_db - maak opnieuw verbinding. Het transactielogboek wordt gewist.
(Zie MSDN Q256650 (voor SQL 7.0) en Q272318 (voor SQL 2000) voor meer details.)

Optie 4: (voor 7.0)
DBCC SHRINKFILE (bestandsnaam, doelgrootte)
DBCC SHRINKDATABASE(databasenaam, doelpercentage)
BACK-UP LOGBOEK database naam MET TRUNCATE_ONLY

Als na deze operaties de watervallen aanhouden, volg dan de aanbevelingen:

- Probeer wijzigingen aan te brengen HOST-bestanden besturingssysteem(hoogstwaarschijnlijk is het voldoende om de associatie alleen in bestanden op een of twee machines te registreren, waar crashes het vaakst voorkomen)

- Probeer de 1C enterprise- en SQL-servers te scheiden als u ze op dezelfde machine hebt staan.

- Of vice versa, installeer ze op dezelfde machine (als er voldoende bronnen zijn) Er zijn gevallen waarin het de overdracht van servers naar één server was die hielp (naar mijn mening is het zeer twijfelachtig en meer precies gerelateerd aan de reden voor beginnen met werken, dit is de compressie van transactielogboeken)

- Controleer de reactietijd van de server (hoogstwaarschijnlijk zal alles binnen het normale bereik vallen, en zeldzame dalingen in de servicetijd kunnen de werking van de bedrijfsserver niet zo veel beïnvloeden)

- Controleer de werking van routers op het netwerk (zelden, maar het komt voor dat het hun herconfiguratie is die het aantal drops beïnvloedt)

- Controleer apparatuurconflicten op het netwerk (dit is de vraag waarom het wenselijk is om apparatuur van dezelfde leverancier op het netwerk te hebben. Wie wil kan bijvoorbeeld controleren in de technische documentatie van 3COM dat staat: als de netwerkkaart detecteert dat het in wisselwerking staat met een soortgelijk netwerk kaart, dan kan het worden omgeschakeld naar een productievere modus door over te schakelen naar een geoptimaliseerd verwerkingsalgoritme netwerk pakketten, gecontroleerd op persoonlijke ervaring prestatiesprong tot 50%)

- Controleer signaalniveaus bij consumenten / eindcomputers (misschien afgezaagd, laag niveau signalen, constant opnieuw aanvragen van blokken, een vertraging in de wachtrij van de netwerkservice en daarom uiteindelijk een bericht ontvangen dat de eindserver de verbinding heeft verbroken wanneer het aantal pogingen de signaalwachttijd overschrijdt. Als je het wilt begrijpen deze kwestie raadpleeg het Ethernet/CSMA CD/CSMA-werkingsprotocol. Het aantal pogingen om een pakket te verzenden dit protocol niet oneindig ...))) En de buffer in de kaarten is ook niet onbeperkt.)

- Voeg geheugen toe aan servers

- Verplaats enkele/alle gebruikers naar terminalmodus (dwz geef wat VEEL gebruikers definiëren als THIN CLIENT 1C). Als zo'n server zou ik Citrix Metaframe of Terminal Server MS aanraden

Wanneer u deze aanbevelingen opvolgt, met uitzondering van het analyseren van problemen met hardware, zal de stabiliteit van het werk hoogstwaarschijnlijk zo sterk toenemen dat platformcrashes zeer zeldzaam zullen worden, wat technologische hiaten in database-onderhoud zal blokkeren, die nog steeds VERPLICHT zijn en niet denk dat die aanbevelingen die hierboven zijn aangegeven Panacee voor alle problemen.

Ze zullen veel, maar niet alle problemen oplossen.

En je bent gelukkig, als je zulke problemen niet hebt, zal degene die ze heeft me begrijpen.

———————————

Onderzoek "Gebruikers"-rollen, indien van toepassing. typische configuratie natuurlijk, en in het bijzonder na het rekenen probleem documenteren met , moet u de problematische rol vinden (wie klaagt).
Vervolgens kijken we voor de rol van de gebruiker naar de radar van het document, als geavanceerde instellingen nee (puur) dan klik met de rechtermuisknop erop - zoek naar links naar het object en zoek achtereenvolgens door de radar naar de rol "Gebruiker" voor elk object.

In sommige gevallen wordt een hoge gebruikersintensiteit verward met een protocolaanval.
>Voer regedit.exe uit, voeg een nieuwe DWORD-waarde met de naam SynAttackProtect toe aan de registersleutel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ en stel deze in op 00000000
Het is zinvol om dit voor Windows 2003 SP1 te doen (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx

Server 1C en DB op dezelfde machine onder Debian-beheer Knijpen.

Oplossing: Stel de kernelparameter tcp_syncookies in op 0.

[e-mail beveiligd]:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(auteur Vadim Ivakhin)

Een vrij veel voorkomende fout bij het gebruik van 1C 8.2 in client-server-modus is dat de externe host de bestaande verbinding met geweld heeft verbroken. In de regel gelden bewindvoerders van opdrachtgevers uit het bedrijfsleven, d.w.z. waar 20 of meer banen worden uitgevoerd.

In 98% van de gevallen is deze fout te wijten aan het herstarten van de workflow. Er kunnen verschillende redenen zijn waarom het opnieuw opstart, maar de meest voorkomende is een banale geplande herstart. Vanwege de groei van het werkstroombestand rphost en de daaropvolgende scherpe vertraging van het werk na deze groei, proberen beheerders het probleem op te lossen door werkprocessen opnieuw op te starten, en worden ze onmiddellijk geconfronteerd met een ander: het loskoppelen van werkende gebruikers. Het creëren van een extra workflow doet niets. ondanks officiële documentatie het overschakelen van een thick client naar een ander werkproces gebeurt niet. Bovendien is er een verhoogde belasting van de processor - het is noodzakelijk om de contextwisseling af te handelen. Overigens raadt 1C zelf één workflow aan voor 50-100 gebruikers.

1) om het geheugen vrij te maken dat wordt ingenomen door de 1C-workflow, gebruikt u automatische herstart werk processen. Het wordt aanbevolen om werkprocessen eenmaal per dag opnieuw te starten (elke 86400 seconden). Tegelijkertijd wordt de workflow eerst uitgeschakeld (nieuwe verbindingen zijn onmogelijk, oude blijven werken) en wordt een nieuwe gestart. Wanneer alle verbindingen met het oude proces zijn verbroken, wordt het proces beëindigd. Let er tegelijkertijd op dat het aftellen van diezelfde 86400 begint vanaf het moment dat de service start Serveragent 1C Enterprise. Die. het is wenselijk om het 's nachts te starten.

2) gebruik niet meer dan één werkproces als u maximaal 100 gebruikers heeft. Bij meer werkprocessen besteden CPU-tijd aan het schakelen tussen contexten.

3) gebruikt geheugen wissen. De snelle groei van het geheugen dat wordt ingenomen door het rphost-proces wordt meestal veroorzaakt door onzorgvuldig geschreven configuratie, vaak nemen programmeurs niet de moeite om het bezette geheugen op te ruimen, vooral onder waarde tabellen, opsommingen en arrays. Dit is vooral duidelijk wanneer het voorkomt in achtergrond banen. Daarom is het bij het analyseren van het probleem van geheugenlekken noodzakelijk om ermee te beginnen, bijvoorbeeld door ze uit te schakelen in de eigenschappen informatiebasis al enige tijd.

4) gebruik afzonderlijke servers voor SQL en 1C. Zoals u weet, is er nooit te veel geheugen voor SQL.

Let op de bekende gevallen van de fout "De externe host heeft de verbinding met geweld verbroken". hoge recycling netwerk uitrusting . Wanneer de reactietijd van de server toeneemt tot 150-300 ms of meer, wordt de verbinding verbroken door een time-out. Dit gebeurde bijvoorbeeld wanneer meerdere gebruikers tegelijkertijd de router, waarop ook de 1C-server is aangesloten, laden door bestanden te kopiëren grote maten. Beheerders moeten rekening houden met de mogelijkheid van deze situatie en letten op de snelheid van de switch-structuur bij het kopen van routers.

Tot slot wil ik hieraan toevoegen dat het installeren en configureren van een server een verantwoorde aangelegenheid is die kennis en ervaring vereist, het is beter om het aan professionals toe te vertrouwen. Onze specialisten voeren een turnkey installatie van de server uit, zie de sectie voor meer details.

Deze fout met code 10054, van kritieke aard, manifesteert zich bij gebruikers op het moment van opname. Meestal gevonden in oudere releases van 1C 8.2.

Screenshot van fout 10054:

Over het algemeen geeft het verschijnen van deze fout aan dat er een onverwachte actie voor de 1C-serverontwikkelaar plaatsvindt:

er komt een ongeldig verzoek binnen;
incorrecte data;
een vraag die om een grote selectie vraagt waaraan niet kan worden voldaan;
speciaal geval: het documentnummer was groter dan de lengte opgegeven in de teller;
controleer het werk met uitgeschakelde antivirussen of firewalls

Correctie:

Het bestaat uit het zoveel mogelijk lokaliseren van het probleem:

het bepalen van het type document,
het register waarmee de fout optreedt,
gebruiker,
computer.

Vervolgens wordt er een kopie van de database gemaakt (met behulp van 1C of DBMS).

Als het opnieuw opstarten van de server het probleem oplost, ga dan door met monitoren. Voeg een script toe om de service 's nachts na kantooruren opnieuw op te starten.

Als het opnieuw opstarten cyclisch is, controleer dan of automatisch opnieuw opstarten is geconfigureerd in de clustereigenschappen:

Er wordt getest en gecorrigeerd met herberekening van totalen en herindexering van tabellen.

De vorige kopie van de database waarin het probleem wordt waargenomen, wordt aan de orde gesteld, de verschillen worden gecontroleerd, misschien leidt dit tot de oorzaak.

Als het probleem niet kan worden opgelost, is de volgende stap het opzetten en analyseren van het productielogboek.

Wat is er te vinden in het proces:

Als de belasting van de server bijna 100% is, overweeg dan om de databaseserver en de 1C-server te scheiden, dit vertraagt meestal, maar stabiliseert het werk (in 8.3 is er een mechanisme gedeelde herinnering, wat de servercommunicatie versnelt en).

Voeg indien mogelijk geheugen toe aan de server.
Een mogelijke oplossing zou zijn om de server te vervangen door een 64-bits server, maar controleer eerst de prestaties van je vrienden, waar deze is.
Dezelfde controle op 32-bit kan geen kwaad om de fout in de gegevens of een specifieke server te begrijpen.
Lossen met laden kan manifestatie elimineren.
Overweeg in laatste instantie om data over te zetten via dataconversie of data in een werkkopie te laden (lange procedure)