โฮสต์ระยะไกลบังคับให้ปิดการเชื่อมต่อ โฮสต์ระยะไกลบังคับให้ยุติการเชื่อมต่อที่มีอยู่

คำอธิบายของข้อผิดพลาด

server_addr=tcp://<имясервера>:1562 descr=ข้อผิดพลาดในการเข้าถึงเครือข่ายไปยังเซิร์ฟเวอร์ (Windows Sockets - 10054(0x00002746) โฮสต์ระยะไกลบังคับให้ปิดการเชื่อมต่อที่มีอยู่) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp

วิธีจัดการกับปัญหานี้

ตั้งค่าบันทึกเทคโนโลยีและแยกวิเคราะห์บันทึก
สาเหตุที่พบบ่อยที่สุดคือการล่มของส่วนเซิร์ฟเวอร์ 1C:Enterprise
คุณสามารถตรวจสอบให้แน่ใจว่ามีการสร้างดัมพ์หรือไม่ (ดูที่พาธ logcfg.xml หากไม่มีการตั้งค่าดัมพ์ จากนั้นในไดเร็กทอรี %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps เช่น C:\ Documents and Settings\<Имя пользователя>\การตั้งค่าท้องถิ่น\ข้อมูลแอปพลิเคชัน\1C\1Cv81\dumps แพลตฟอร์มล่มมักเกิดขึ้นเนื่องจากการร้องขอที่มีพารามิเตอร์ที่ไม่ได้มาตรฐาน ส่งดัมพ์ไปยังอีเมลสนับสนุนทางเทคนิคของ 1C: [ป้องกันอีเมล].
1. บ่อยครั้งที่ฉันพบปัญหาในบันทึกเอกสารในการเลือก ข้อความค้นหาจะคล้ายกับสิ่งนี้:

เลือกที่อนุญาตสูงสุด 35 R.Date_Time A1,
R.หมายเลข 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,
ร.เอกสาร A14,
ร.ทำเครื่องหมาย A15,
R.โพสต์ A16,CAST(R.Fld9608 AS REF(อ้างอิง 9)).คำอธิบาย
A17,CAST(R.Fld9606 AS REF(Reference52)).คำอธิบาย A18,CAST(R.Fld9611
AS REF(Reference93)).คำอธิบาย A19, CASE WHEN R.Fld9609 REFS
การอ้างอิง 53 แล้วหล่อ (R.Fld9609 AS REF (อ้างอิง 53)) คำอธิบายเมื่อ
R.Fld9609 REFS Reference150 แล้วส่ง (R.Fld9609 AS
REF(Reference150)).คำอธิบายเมื่อ R.Fld9609 REFS Reference63 แล้ว
นักแสดง(R.Fld9609 AS REF(อ้างอิง 63)) คำอธิบายเมื่อ R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).คำอธิบาย END
A20,CAST(R.Fld9605 AS REF(Reference79)).คำอธิบาย A21
จาก DocumentJournal9604 R ที่ไหน
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) และ
(R.Date_Time > DATETIME(2006,12,31,12,0,0) หรือ (R.Date_Time =
DATETIME(2006,12,31,12,0,0) และ (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
เรียงลำดับตาม A1 ASC, A14 ASC'

2. ตัวอย่างของบันทึก TJ ที่แสดงสาเหตุที่เซิร์ฟเวอร์ล่มเมื่ออัปเดตการค้นหาข้อความแบบเต็ม
11:40.9690-0,EXCP,1,กระบวนการ=rphost,p:ชื่อกระบวนการ=<база данных>,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,บริบท=’
GeneralModule.Module ของงานปกติ: 46: Full-TextSearch.UpdateIndex (False, True);'

วิธีแก้ปัญหาสุดท้ายในตัวอย่างนี้คือการปิดการใช้งานกระบวนการเบื้องหลังในฐานข้อมูลที่มีปัญหา รอการเปิดตัวแพลตฟอร์มใหม่และอัปเดต
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการขัดข้องของแพลตฟอร์ม โปรดดูบล็อกของฉัน
3. ตัวอย่างของ TC สำหรับการรีสตาร์ทกระบวนการแบบวนรอบ ในการวิเคราะห์เหตุการณ์นี้บนคอมพิวเตอร์เซิร์ฟเวอร์ 1C:Enterprise คุณต้องเปิดใช้งานรายการในบันทึกเหตุการณ์ทางเทคโนโลยี PROC (ตัวอย่างไฟล์ logcfg.xml)
เมื่อกระบวนการปิดตัวลง เหตุการณ์ PROC จะถูกยกขึ้นโดยมีคุณสมบัติ Txt=Process กลายเป็นปิดใช้งาน
เมื่อกระบวนการถูกยกเลิก เหตุการณ์ PROC จะถูกออกพร้อมกับคุณสมบัติ Txt=Process สิ้นสุดลง ลูกค้าท่านใดที่ทำเสร็จแล้วมีข้อผิดพลาด หากผู้ใช้หยุดทำงานตรงเวลากับเอาต์พุตของเหตุการณ์นี้ สาเหตุคือการบังคับปิดเวิร์กโฟลว์โดยผู้ดูแลระบบ (ผ่านคอนโซลคลัสเตอร์) หรือเนื่องจากการรีสตาร์ทอัตโนมัติ
4. ตรวจสอบให้แน่ใจว่าสาเหตุเป็น/ไม่ใช่การกระทำของผู้ดูแลระบบในคอนโซล

—————————-

ด้านล่างนี้เป็นเวอร์ชันของโซลูชันของเพื่อนร่วมงาน

ทุกคน สนใจในการแก้ไขปัญหาแพลตฟอร์มล่มด้วยข้อผิดพลาด:

10051, 10053, 10054, 10064

ดังที่การซักถามเกี่ยวกับข้อขัดข้องของแพลตฟอร์มแสดงให้เห็น โดยมีข้อผิดพลาดข้างต้น:

— การแครชส่วนใหญ่มีสาเหตุมาจากงานเบื้องหลังตามที่คาดไว้ในหัวข้อ

- ขาดพื้นที่ดิสก์

— มีธุรกรรมที่ยังไม่เสร็จจำนวนมากในบันทึก 1C

— ก่อนที่จะแยกวิเคราะห์บันทึกทางเทคโนโลยี ให้วิเคราะห์งานพื้นหลังที่ใช้ในการกำหนดค่าและปิดใช้งานงานที่คุณไม่ต้องการสำหรับงานหรือการกำหนดค่า (ไม่สำคัญ การวิเคราะห์ขยะขนาด 14 GB ถือเป็นงานอดิเรกหากคุณไม่มีอะไรทำดีไปกว่านี้.. . :))))

— วิเคราะห์และแก้ไขงานพื้นหลังที่คุณเพิ่ม ตรวจสอบให้แน่ใจว่างานเหล่านั้นเสร็จสมบูรณ์ด้วยโค้ดการทำงานปกติ (ไม่มีข้อผิดพลาดหรือธุรกรรมที่ปิดแล้ว)

— เพิ่มส่วนของโค้ดให้กับอัลกอริธึมงานพื้นหลังที่มีข้อบกพร่อง บังคับหน่วยความจำที่ใช้ระหว่างการดำเนินการ (คุณไม่ควรหวังว่า 1C จะจัดสรรหน่วยความจำที่ใช้เมื่อเสร็จสิ้น)

— วิเคราะห์และแก้ไขปัญหาประสิทธิภาพการทำงานที่ถูกต้องของงานการกำหนดค่าพื้นหลังทั่วไป

— ปฏิบัติตามขั้นตอนกำกับดูแลกับฐานข้อมูลผ่านรายการเมนู Administration-Testing and Correction อย่าลืม จำเป็น, ทำการบีบอัดฐานข้อมูล

— วิเคราะห์จำนวนพื้นที่ที่ใช้โดยเซิร์ฟเวอร์ SQL มีแนวโน้มว่าเซิร์ฟเวอร์จะมีหน่วยความจำไม่เพียงพอ

— ตรวจสอบนโยบายการกำหนดค่า Active Directory

— และยังบีบอัด/ล้างบันทึกธุรกรรม SQL ด้วยโค้ดลักษณะนี้ (สำหรับ SQL 2000):

ตัวเลือกที่ 1:DBCC SHRINKFILE(pubs_log, 2)
(หากไม่ถึงขนาดที่ต้องการให้ลองใช้ทางเลือกที่ 2) ตัวเลือก 2:สำรองข้อมูลบันทึกผับด้วย TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

โดยที่ pub_log คือชื่อของฐานข้อมูลของคุณ

ตัวเลือก 3:
sp_detach_db - เราจะตัดการเชื่อมต่อฐานข้อมูลด้วยขั้นตอนนี้ และ sp_attach_db - เราจะเชื่อมต่ออีกครั้ง บันทึกธุรกรรมจะถูกล้าง
(สำหรับข้อมูลเพิ่มเติม โปรดดูหัวข้อ MSDN Q256650 (สำหรับ SQL 7.0) และ Q272318 (สำหรับ SQL 2000))

ตัวเลือก 4: (สำหรับ 7.0)
DBCC SHRINKFILE(ชื่อไฟล์, target_size)
DBCC SHRINKDATABASE (ชื่อฐานข้อมูล, target_percent)
บันทึกการสำรองข้อมูลฐานข้อมูล_ชื่อ ด้วย TRUNCATE_ONLY

หากล้มต่อไปหลังการดำเนินการเหล่านี้ ให้ปฏิบัติตามคำแนะนำต่อไป:

— ลองเปลี่ยนแปลงไฟล์ HOSTS ของระบบปฏิบัติการ (ส่วนใหญ่น่าจะเพียงพอที่จะลงทะเบียนการเชื่อมโยงเฉพาะในไฟล์ในเครื่องหนึ่งหรือสองเครื่องที่เกิดปัญหาบ่อยที่สุด)

— ลองแยก 1C Enterprise และเซิร์ฟเวอร์ SQL หากคุณมีไว้ในเครื่องเดียวกัน

- หรือในทางกลับกันให้ติดตั้งไว้ในเครื่องเดียว (หากคุณมีทรัพยากรเพียงพอ) มีหลายกรณีที่การย้ายเซิร์ฟเวอร์ไปยังเซิร์ฟเวอร์เดียวช่วยได้ (ในความคิดของฉันมันเป็นที่น่าสงสัยมากและเกี่ยวข้องกับเหตุผลในการเริ่มต้นงานนี้มากกว่า คือการบีบอัดบันทึกธุรกรรม)

— ตรวจสอบเวลาตอบสนองของเซิร์ฟเวอร์ (ส่วนใหญ่แล้วทุกอย่างจะอยู่ภายในขีดจำกัดปกติ และความล้มเหลวที่เกิดขึ้นได้ยากในเวลาบริการไม่สามารถส่งผลกระทบที่รุนแรงต่อการทำงานของเซิร์ฟเวอร์องค์กรได้)

— ตรวจสอบการทำงานของเราเตอร์บนเครือข่าย (ไม่ค่อยมี แต่เกิดขึ้นว่าเป็นการกำหนดค่าใหม่ที่ส่งผลต่อจำนวนข้อขัดข้อง)

— ตรวจสอบข้อขัดแย้งของอุปกรณ์บนเครือข่าย (เป็นเรื่องเกี่ยวกับคำถามว่าทำไมจึงแนะนำให้มีอุปกรณ์จากซัพพลายเออร์รายหนึ่งบนเครือข่าย ใครก็ตามที่ต้องการสามารถตรวจสอบได้ ตัวอย่างเช่น ในเอกสารทางเทคนิคของ 3COM มีเขียนไว้ว่า ถ้าเครือข่าย การ์ดตรวจพบว่ากำลังโต้ตอบกับการ์ดเครือข่ายที่คล้ายกัน จากนั้นอาจเปลี่ยนเป็นโหมดที่มีประสิทธิผลมากขึ้น เนื่องจากการเปลี่ยนไปใช้อัลกอริธึมที่ได้รับการปรับปรุงสำหรับการประมวลผลแพ็กเก็ตเครือข่าย ประสิทธิภาพที่เพิ่มขึ้นสูงสุดถึง 50% ได้รับการยืนยันจากประสบการณ์ส่วนตัว)

- ตรวจสอบระดับสัญญาณของผู้บริโภค/คอมพิวเตอร์ปลายทาง (อาจเป็นเรื่องเล็กน้อย ระดับสัญญาณต่ำ คำขอบล็อกซ้ำอย่างต่อเนื่อง ความล่าช้าในคิวสำหรับการบริการบนเครือข่าย และในที่สุดก็ได้รับข้อความว่าเซิร์ฟเวอร์ปลายทางได้ปิดการเชื่อมต่อเมื่อ จำนวนความพยายามเกินกว่าการรับสัญญาณหมดเวลา หากคุณต้องการทำความเข้าใจปัญหานี้ โปรดดูโปรโตคอล Ethernet/CSMA CD/CSMA บัฟเฟอร์ในการ์ดก็ไม่จำกัดเช่นกัน)

— เพิ่มหน่วยความจำให้กับเซิร์ฟเวอร์

— โอนผู้ใช้บางส่วน/ทั้งหมดไปยังโหมดเทอร์มินัล (เช่น ระบุสิ่งที่ผู้ใช้จำนวนมากกำหนดว่าเป็น THIN CLIENT 1C) สำหรับเซิร์ฟเวอร์ดังกล่าว ฉันขอแนะนำ Citrix Metaframe หรือ Terminal Server MS

เป็นไปได้มากว่าเมื่อคุณปฏิบัติตามคำแนะนำเหล่านี้ ยกเว้นการวิเคราะห์ปัญหาเกี่ยวกับฮาร์ดแวร์ ความเสถียรของงานจะเพิ่มขึ้นมากจนการล่มของแพลตฟอร์มจะหายากมาก ซึ่งจะครอบคลุมช่องว่างทางเทคโนโลยีในการบำรุงรักษาฐานข้อมูลซึ่งยังคงต้องมี ปฏิบัติตามแล้วไม่คิดว่าคำแนะนำข้างต้นเป็นยาครอบจักรวาลสำหรับทุกปัญหา

พวกเขาจะแก้ปัญหาได้หลายอย่าง แต่ไม่ใช่ทั้งหมด

และคุณมีความสุขถ้าคุณไม่มีปัญหาเช่นนั้นใครก็ตามที่มีปัญหาจะเข้าใจฉัน

———————————

สำรวจบทบาท "ผู้ใช้" หากมีอยู่ในการกำหนดค่าทั่วไป และโดยเฉพาะหลังจากที่คุณคำนวณแล้ว ปัญหาเอกสารที่ใช้ คุณต้องค้นหาบทบาทที่เป็นปัญหา (ใครกำลังบ่น)
ถัดไป สำหรับบทบาทผู้ใช้ ให้ดูที่เรดาร์ของเอกสาร หากไม่มีการตั้งค่าเพิ่มเติม (ล้วนๆ) จากนั้นให้คลิกขวาเพื่อค้นหาลิงก์ไปยังวัตถุ และดูที่เรดาร์สำหรับ "ผู้ใช้" ตามลำดับ บทบาทสำหรับแต่ละวัตถุ

เข้าใจผิดว่าผู้ใช้มีความเข้มข้นสูงในการโจมตีโปรโตคอลในบางกรณี Windows
> เรียกใช้ regedit.exe เพิ่มค่า DWORD ใหม่ที่เรียกว่า SynAttackProtect ให้กับคีย์รีจิสทรี HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ และให้ค่าเป็น 00000000
มันสมเหตุสมผลที่จะทำกับ Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx

เซิร์ฟเวอร์ 1C และฐานข้อมูลบนเครื่องเดียวที่ใช้ Debian Squeeze

วิธีแก้ปัญหา: ตั้งค่าพารามิเตอร์เคอร์เนล tcp_syncookies เป็น 0

root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(ผู้เขียน วาดิม อิวาคิน)

ข้อผิดพลาดที่พบบ่อยพอสมควรเมื่อใช้ 1C 8.2 ในโหมดไคลเอนต์ - เซิร์ฟเวอร์คือโฮสต์ระยะไกลบังคับให้ยุติการเชื่อมต่อที่มีอยู่ ตามกฎแล้ว ผู้ดูแลระบบของลูกค้าจากภาคองค์กรจะนำไปใช้ เช่น ที่มีสถานที่ทำงานตั้งแต่ 20 แห่งขึ้นไป

ใน 98% ของกรณี ข้อผิดพลาดนี้เกี่ยวข้องกับการรีสตาร์ทเวิร์กโฟลว์ อาจมีสาเหตุหลายประการที่ทำให้รีสตาร์ท แต่สาเหตุที่พบบ่อยที่สุดคือการรีสตาร์ทซ้ำๆ ตามกำหนดเวลา เนื่องจากการเติบโตของไฟล์เวิร์กโฟลว์ rphostและการชะลอตัวอย่างรวดเร็วตามมาในการทำงานซึ่งตามการเติบโตนี้ ผู้ดูแลระบบพยายามแก้ไขปัญหาด้วยการรีสตาร์ทกระบวนการทำงาน และเผชิญกับปัญหาอื่นทันที - ตัดการเชื่อมต่อผู้ใช้ที่ทำงาน การสร้างเวิร์กโฟลว์เพิ่มเติมไม่ได้ให้อะไรเลยเพราะ... ตรงกันข้ามกับเอกสารอย่างเป็นทางการของการเปลี่ยนไคลเอ็นต์แบบหนาเป็นเวิร์กโฟลว์อื่น ไม่เกิดขึ้น- ยิ่งไปกว่านั้น ยังมีภาระบนโปรเซสเซอร์เพิ่มขึ้น - จำเป็นต้องจัดการการสลับบริบท อย่างไรก็ตาม 1C แนะนำเวิร์กโฟลว์เดียวสำหรับผู้ใช้ 50-100 คน

1) เพื่อเพิ่มหน่วยความจำที่กระบวนการทำงาน 1C ใช้การรีสตาร์ทกระบวนการทำงานโดยอัตโนมัติ ขอแนะนำให้รีสตาร์ทเวิร์กโฟลว์วันละครั้ง (ทุกๆ 86400 วินาที) ในกรณีนี้ กระบวนการของผู้ปฏิบัติงานจะถูกปิดก่อน (ไม่สามารถเชื่อมต่อใหม่ได้ กระบวนการเก่ายังคงทำงานต่อไป) และเปิดตัวกระบวนการใหม่ จากนั้น เมื่อการเชื่อมต่อทั้งหมดไปยังกระบวนการเก่าถูกปิด กระบวนการจะยุติลง ในเวลาเดียวกัน โปรดทราบว่าการนับถอยหลังของ 86400 เดียวกันนี้จะเริ่มนับจากช่วงเวลาที่บริการเริ่มต้น ตัวแทนเซิร์ฟเวอร์ 1C Enterprise- เหล่านั้น. ขอแนะนำให้เริ่มในเวลากลางคืน

2) อย่าใช้กระบวนการของผู้ปฏิบัติงานมากกว่าหนึ่งกระบวนการหากคุณมีผู้ใช้มากถึง 100 คน ด้วยกระบวนการของผู้ปฏิบัติงานที่มากขึ้น เวลาของ CPU จะสูญเปล่าไปกับการสลับบริบทระหว่างกระบวนการเหล่านั้น

3) ล้างหน่วยความจำที่ใช้แล้ว- การเติบโตอย่างรวดเร็วของหน่วยความจำที่ถูกครอบครองโดยกระบวนการ rphost มักเกิดจากการกำหนดค่าที่เขียนอย่างไม่ระมัดระวัง โปรแกรมเมอร์มักจะไม่สนใจที่จะล้างหน่วยความจำที่ถูกครอบครอง โดยเฉพาะภายใต้ ตารางค่าการแจงนับและอาร์เรย์ สิ่งนี้จะเด่นชัดเป็นพิเศษเมื่อมันเกิดขึ้นในงานเบื้องหลัง ดังนั้น เมื่อวิเคราะห์ปัญหาหน่วยความจำรั่ว คุณต้องเริ่มต้นด้วยปัญหาดังกล่าว เช่น ปิดการใช้งานในคุณสมบัติฐานข้อมูลสักระยะหนึ่ง

4) การใช้งาน เซิร์ฟเวอร์แยกต่างหากสำหรับ SQL และ 1C อย่างที่คุณทราบ ไม่มีหน่วยความจำสำหรับ SQL มากเกินไป

คุณควรให้ความสนใจกับกรณีที่ระบุไว้ซึ่งมีข้อผิดพลาด “โฮสต์ระยะไกลบังคับให้ปิดการเชื่อมต่อ” ปรากฏขึ้นเนื่องจาก การรีไซเคิลอุปกรณ์เครือข่ายสูง- เมื่อเวลาตอบสนองของเซิร์ฟเวอร์เพิ่มขึ้นเป็น 150-300 มิลลิวินาทีขึ้นไป การเชื่อมต่อจะถูกตัดการเชื่อมต่อเนื่องจากการหมดเวลา ตัวอย่างเช่นสิ่งนี้เกิดขึ้นเมื่อผู้ใช้หลายคนโหลดเราเตอร์ที่เซิร์ฟเวอร์ 1C เชื่อมต่อพร้อมกันโดยการคัดลอกไฟล์ขนาดใหญ่ ผู้ดูแลระบบควรคำนึงถึงความเป็นไปได้ของสถานการณ์ดังกล่าวและเมื่อซื้อเราเตอร์ให้คำนึงถึงความเร็วของเมทริกซ์การสลับ

โดยสรุป ฉันจะเสริมว่าการติดตั้งและกำหนดค่าเซิร์ฟเวอร์เป็นเรื่องที่มีความรับผิดชอบ ซึ่งต้องใช้ความรู้และประสบการณ์ เป็นการดีกว่าที่จะมอบความไว้วางใจให้กับผู้เชี่ยวชาญ ผู้เชี่ยวชาญของเราติดตั้งเซิร์ฟเวอร์แบบครบวงจร สำหรับรายละเอียดเพิ่มเติม โปรดดูในส่วน

รหัสข้อผิดพลาด 10054 ซึ่งมีลักษณะร้ายแรงนี้จะปรากฏต่อผู้ใช้ในขณะที่บันทึก มักพบใน 1C 8.2 รุ่นเก่า

ภาพหน้าจอของข้อผิดพลาด 10054:

โดยทั่วไป การปรากฏตัวของข้อผิดพลาดนี้บ่งชี้ว่ามีการกระทำที่ไม่คาดคิดสำหรับผู้พัฒนาเซิร์ฟเวอร์ 1C เกิดขึ้น:

• คำขอที่ไม่ถูกต้องมาถึง
• ข้อมูลไม่ถูกต้อง
• แบบสอบถามที่เรียกตัวอย่างขนาดใหญ่ที่ไม่สามารถตอบสนองได้
• กรณีพิเศษ เลขที่เอกสารยาวเกินความยาวที่กำหนดในตัวเศษ
• ตรวจสอบการทำงานด้วยโปรแกรมป้องกันไวรัสหรือไฟร์วอลล์ที่ถูกปิดใช้งาน

การแก้ไข:

ประกอบด้วยการแปลปัญหาให้มากที่สุด:

• การกำหนดประเภทของเอกสาร
• การลงทะเบียนที่เกิดข้อผิดพลาด
• ผู้ใช้,
• คอมพิวเตอร์.

จากนั้นจะทำสำเนาฐานข้อมูล (โดยใช้ 1C หรือ DBMS)

หากการรีสตาร์ทเซิร์ฟเวอร์ช่วยแก้ปัญหาได้ ให้ตรวจสอบต่อไป เพิ่มสคริปต์รีสตาร์ทบริการในเวลากลางคืน ชั่วโมงการทำงาน.

หากการรีสตาร์ทเป็นแบบวน ให้ตรวจสอบว่าคุณได้กำหนดค่าการรีสตาร์ทอัตโนมัติในคุณสมบัติคลัสเตอร์หรือไม่:

การทดสอบและแก้ไขจะดำเนินการด้วยการคำนวณผลลัพธ์ใหม่และการจัดทำดัชนีตารางใหม่

คัดลอกสำเนาก่อนหน้าของฐานข้อมูลที่มีการสังเกตปัญหา มีการตรวจสอบความแตกต่าง และบางทีนี่อาจนำไปสู่สาเหตุ

หากปัญหาไม่สามารถแก้ไขได้ ขั้นตอนต่อไปคือการกำหนดค่าและวิเคราะห์บันทึกกระบวนการ

สิ่งที่อาจชัดเจนในระหว่างกระบวนการ:

หากโหลดบนเซิร์ฟเวอร์ใกล้จะถึง 100% ให้พิจารณาตัวเลือกในการแยกเซิร์ฟเวอร์ฐานข้อมูลและเซิร์ฟเวอร์ 1C ซึ่งมักจะช้าลง แต่ทำให้งานมีเสถียรภาพ (ใน 8.3 มีกลไกหน่วยความจำที่ใช้ร่วมกันที่เพิ่มความเร็วการโต้ตอบระหว่าง เซิร์ฟเวอร์และ)

• เพิ่มหน่วยความจำให้กับเซิร์ฟเวอร์ถ้าเป็นไปได้
• วิธีแก้ปัญหาที่เป็นไปได้คือการแทนที่เซิร์ฟเวอร์ด้วยเซิร์ฟเวอร์ 64 บิต แต่ก่อนอื่นให้ตรวจสอบฟังก์ชันการทำงานของเพื่อนของคุณที่ตั้งอยู่
• การตรวจสอบแบบเดียวกันบน 32 บิตเพื่อทำความเข้าใจข้อผิดพลาดในข้อมูลหรือเซิร์ฟเวอร์เฉพาะจะไม่เสียหาย
• การขนถ่ายและการขนถ่ายอาจทำให้ไม่แสดงอาการ
• ทางเลือกสุดท้าย ให้พิจารณาถ่ายโอนข้อมูลผ่านการแปลงข้อมูลหรือเพิ่มข้อมูลลงในสำเนาที่ใช้งานได้ (ขั้นตอนที่ยาว)

ตรวจสอบบันทึก Windows เพื่อหาข้อผิดพลาดของระบบ:

• ในการดำเนินงานเครือข่าย
• อุปกรณ์
• การใช้งาน
• รีสตาร์ทเราเตอร์สวิตช์ (ไม่ค่อยพบ แต่มีปัญหา)

หากปัญหาไม่ได้รับการแก้ไขในเวลาอันสั้น คุณอาจต้องการความช่วยเหลือจากผู้ดูแลระบบที่ผ่านการรับรองหรือผู้เชี่ยวชาญ 1C