Kesalahan yang cukup umum saat menggunakan 1C 8.2 dalam mode klien-server - host jarak jauh terputus secara paksa koneksi yang ada. Sebagai aturan, administrator klien dari sektor korporasi berlaku, mis. di mana 20 atau lebih tempat kerja dioperasikan.

Dalam 98% kasus, kesalahan ini dikaitkan dengan memulai ulang alur kerja. Mungkin ada beberapa alasan mengapa ini dimulai ulang, tetapi yang paling umum adalah memulai kembali secara dangkal sesuai jadwal. Karena pertumbuhan file alur kerja rphost dan perlambatan tajam dalam pekerjaan setelah pertumbuhan ini, administrator mencoba memecahkan masalah dengan memulai kembali proses kerja, dan segera dihadapkan pada masalah lain - memutuskan sambungan pengguna yang bekerja. Membuat alur kerja tambahan tidak memberikan apa pun karena... bertentangan dengan dokumentasi resmi tentang mengalihkan klien tebal ke alur kerja lain tidak terjadi. Apalagi ada peningkatan beban pada prosesor - perlu untuk menangani peralihan konteks. Omong-omong, 1C sendiri merekomendasikan satu alur kerja untuk 50-100 pengguna.

1) untuk mengosongkan memori yang ditempati oleh proses kerja 1C, gunakan restart otomatis proses kerja. Disarankan untuk memulai ulang alur kerja sekali sehari (setiap 86400 detik). Dalam hal ini, proses pekerja dimatikan terlebih dahulu (koneksi baru tidak dapat dilakukan, yang lama terus berfungsi) dan yang baru diluncurkan. Kemudian, ketika semua koneksi ke proses lama ditutup, proses tersebut berhenti. Pada saat yang sama, harap dicatat bahwa hitungan mundur 86400 yang sama dimulai dari saat layanan dimulai Agen server 1C Enterprise. Itu. Dianjurkan untuk memulainya pada malam hari.

2) jangan menggunakan lebih dari satu proses pekerja, jika Anda memiliki hingga 100 pengguna. Pada lagi proses pekerja menghabiskan waktu CPU untuk mengalihkan konteks di antara mereka.

3) menghapus memori yang digunakan. Pesatnya pertumbuhan memori yang ditempati oleh proses rphost paling sering disebabkan oleh konfigurasi yang ditulis secara sembarangan; pemrogram sering kali tidak repot-repot membersihkan memori yang ditempati, terutama di bawah tabel nilai, enumerasi dan array. Hal ini terutama terlihat ketika terjadi di tugas latar belakang. Oleh karena itu, ketika menganalisis masalah kebocoran memori, Anda harus memulainya, misalnya, dengan menonaktifkannya di properti basis informasi sebentar.

4) penggunaan server terpisah untuk SQL dan 1C. Seperti yang Anda ketahui, memori untuk SQL tidak pernah terlalu banyak.

Anda harus memperhatikan kasus-kasus yang dicatat di mana kesalahan "Host jarak jauh menutup koneksi secara paksa" muncul karena pemanfaatan yang tinggi peralatan jaringan . Ketika waktu respons server meningkat menjadi 150-300 ms atau lebih, koneksi terputus karena batas waktu habis. Misalnya, ini terjadi ketika beberapa pengguna secara bersamaan memuat router yang terhubung dengan server 1C dengan menyalin file ukuran besar. Administrator harus memperhitungkan kemungkinan situasi ini, dan ketika membeli router, perhatikan kecepatan peralihan jaringan.

Sebagai kesimpulan, saya akan menambahkan bahwa menginstal dan mengkonfigurasi server adalah masalah bertanggung jawab yang membutuhkan pengetahuan dan pengalaman; lebih baik mempercayakannya kepada para profesional. Spesialis kami melakukan instalasi server turnkey; untuk lebih jelasnya, lihat bagian.

kesalahan ini dengan kode 10054, bersifat kritis, muncul di hadapan pengguna pada saat perekaman. Paling sering ditemukan di rilis lama 1C 8.2.

Tangkapan layar kesalahan 10054:

Secara umum, munculnya kesalahan ini menunjukkan bahwa sesuatu yang tidak terduga sedang terjadi pada pengembang server 1C:

• permintaan yang salah datang;
• data yang salah;
• kueri yang memanggil sampel besar yang tidak dapat dipenuhi;
• kasus khusus: nomor dokumen lebih besar dari panjang yang ditentukan dalam pembilang;
• periksa operasi dengan antivirus atau firewall yang dinonaktifkan

Koreksi:

Ini terdiri dari melokalisasi masalah sejauh mungkin:

• menentukan jenis dokumen,
• register tempat kesalahan terjadi,
• pengguna,
• komputer.

Kemudian salinan database dibuat (menggunakan 1C atau DBMS).

Jika memulai ulang server menyelesaikan masalah, lanjutkan pemantauan. Tambahkan skrip restart layanan di malam hari jam kerja.

Jika restart bersifat siklis, periksa apakah Anda telah mengkonfigurasi restart otomatis di properti cluster:

Pengujian dan koreksi dilakukan dengan penghitungan ulang hasil dan pengindeksan ulang tabel.

Salinan database sebelumnya dimana masalah diamati diambil, perbedaannya diperiksa, dan mungkin ini akan mengarah pada penyebabnya.

Jika permasalahan tidak dapat diselesaikan, langkah selanjutnya Akan ada pengaturan dan analisis log teknologi.

Apa yang mungkin menjadi jelas selama proses tersebut:

Jika beban di server di ambang 100%, pertimbangkan untuk memisahkan server database dan server 1C, ini biasanya memperlambat tetapi menstabilkan pekerjaan (di 8.3 ada mekanismenya memori bersama, yang mempercepat interaksi server dan).

• Tambahkan memori ke server jika memungkinkan.
• Solusi yang mungkin adalah mengganti server dengan yang 64-bit, tetapi periksa dulu fungsionalitas teman Anda di mana lokasinya.
• Tidak ada salahnya melakukan pemeriksaan yang sama pada 32-bit untuk memahami kesalahan pada data atau server tertentu.
• Bongkar dan muat dapat menghilangkan manifestasi.
• Sebagai upaya terakhir, pertimbangkan untuk mentransfer data melalui konversi data atau pemuatan data tambahan ke dalamnya copy pekerjaan(prosedur panjang)

Periksa log Windows untuk kesalahan sistem:

• dalam operasi jaringan
• peralatan
• aplikasi
• restart router, switch (jarang, tetapi ada masalah dengannya)

Jika masalah tidak terselesaikan di waktu singkat, Anda mungkin memerlukan bantuan administrator bersertifikat atau pakar 1C.

Deskripsi kesalahan

server_addr=tcp://<имясервера>:1562 descr=Kesalahan akses jaringan ke server (Soket Windows - 10054(0x00002746). Host jarak jauh secara paksa menutup koneksi yang ada.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp

Bagaimana cara mengatasi masalah ini

Siapkan Log Teknologi dan parsing lognya.
Paling alasan umum Ada kerusakan pada bagian server 1C:Enterprise.
Anda juga dapat memastikannya dengan melihat apakah dump sedang dibuat (lihat path logcfg.xml, jika pengaturan dump tidak ada, maka di direktori %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps , misalnya C:\Dokumen dan Pengaturan\<Имя пользователя>\Pengaturan Lokal\Data Aplikasi\1C\1Cv81\dumps. Kegagalan platform paling sering terjadi karena permintaan dengan parameter non-standar. Kirim dump ke email dukungan teknis 1C: [dilindungi email].
1. Paling sering saya menemui masalah dalam pilihan log in dokumen, pertanyaannya mirip dengan ini:

PILIH DIIZINKAN TOP 35 R.Tanggal_Waktu A1,
R.Nomor 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.Dokumen A14,
R.Bertanda A15,
R.Diposting A16,CAST(R.Fld9608 SEBAGAI REF(Referensi9)).Deskripsi
A17,CAST(R.Fld9606 SEBAGAI REF(Referensi52)).Deskripsi A18,CAST(R.Fld9611
SEBAGAI REF(Referensi93)).Deskripsi A19, KASUS KETIKA R.Fld9609 REFS
Referensi53 LALU CAST(R.Fld9609 SEBAGAI REF(Referensi53)).Deskripsi KAPAN
R.Fld9609 REFS Referensi150 LALU CAST(R.Fld9609 AS
REF(Referensi150)).Deskripsi KETIKA R.Fld9609 Referensi REFS63 LALU
CAST(R.Fld9609 AS REF(Reference63)).Deskripsi KETIKA R.Fld9609 REFS
Referensi114 LALU CAST(R.Fld9609 SEBAGAI REF(Referensi114)).Deskripsi AKHIR
A20,CAST(R.Fld9605 SEBAGAI REF(Referensi79)).Deskripsi A21
DARI DocumentJournal9604 R DIMANA
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) DAN
(R.Tanggal_Waktu > DATETIME(2006,12,31,12,0,0) ATAU (R.Tanggal_Waktu =
DATETIME(2006,12,31,12,0,0) DAN (R.Dokumen >=
343:b654000bcd6ad80811dba49c7aabe269)))
DIPESAN OLEH A1 ASC, A14 ASC'

2. Contoh log TJ yang menunjukkan alasan server mogok saat memperbarui pencarian teks lengkap
11:40.9690-0,EXCP,1,proses=rphost,p:namaproses=<база данных>,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.Module Tugas Reguler: 46: Full-TextSearch.UpdateIndex (Salah, Benar);'

Solusi terakhir dalam contoh ini adalah menonaktifkan proses latar belakang di database yang bermasalah. Tunggu rilis dan pembaruan platform baru.
Untuk informasi lebih lanjut tentang kerusakan platform, lihat blog saya.
3. Contoh TC untuk proses restart siklik. Untuk menganalisis peristiwa ini di komputer server 1C:Enterprise, Anda harus mengaktifkan entri di log peristiwa teknologi PROC (contoh file logcfg.xml).
Ketika suatu proses dimatikan, event PROC akan dimunculkan dengan properti Txt=Proses menjadi nonaktif.
Ketika suatu proses dihentikan, acara PROC akan dikeluarkan dengan properti Txt=Proses dihentikan. Setiap klien selesai dengan kesalahan. Jika crash pengguna bertepatan dengan output dari peristiwa ini, maka penyebabnya adalah berhenti secara paksa alur kerja baik oleh administrator (melalui konsol cluster) atau karena restart otomatis.
4. Pastikan penyebabnya adalah/bukan tindakan administrator di konsol

—————————-

Di bawah ini adalah versi solusi rekan kerja.

Setiap orang tertarik dalam memecahkan masalah dengan platform crash dengan kesalahan:

10051, 10053, 10054, 10064

Seperti yang ditunjukkan oleh pembekalan tentang kerusakan platform, dari atas kesalahan yang ditunjukkan:

- Kebanyakan jatuh disebabkan oleh pekerjaan pekerjaan latar belakang, seperti yang diharapkan dalam topik.

- Tidak dengan pegangan ruang disk

— Ketersediaan jumlah besar transaksi yang belum selesai di log 1C

— Sebelum mengurai log teknologi, analisis pekerjaan latar belakang yang digunakan dalam konfigurasi dan nonaktifkan pekerjaan yang tidak Anda perlukan untuk pekerjaan atau konfigurasi (sepele, menganalisis sampah 14 GB dapat dianggap sebagai hobi jika tidak ada hal lain yang lebih baik untuk dilakukan.. .

— Analisis dan koreksi pekerjaan latar belakang yang Anda tambahkan, pastikan pekerjaan tersebut diselesaikan dengan kode penyelesaian normal (tidak ada kesalahan atau transaksi tertutup)

— Tambahkan fragmen kode ke algoritma tugas latar belakang yang bermasalah secara paksa, memori yang digunakan selama pengoperasiannya (Anda tidak boleh berharap bahwa 1C akan memisahkan memori yang digunakan setelah selesai)

— Menganalisis dan MEMPERBAIKI MASALAH KINERJA dari pekerjaan konfigurasi latar belakang yang umum

— Lakukan prosedur regulasi dengan database, melalui item menu Administrasi-Pengujian dan Koreksi, jangan lupa Perlu, lakukan kompresi basis data

— Analisis jumlah ruang yang digunakan oleh server SQL, kemungkinan besar server tidak memiliki cukup memori

— Periksa pengaturan kebijakan Anda Direktori Aktif

— Dan juga kompres/hapus log transaksi SQL dengan kode seperti ini (untuk SQL 2000):

Opsi 1:DBCC SHRINKFILE(pubs_log, 2)
(Jika ukuran yang tepat tidak tercapai coba opsi 2) Opsi 2:CADANGAN LOG pub ​​DENGAN TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

Dimana pub_log adalah nama database Anda

Opsi 3:
sp_detach_db - kami akan memutuskan sambungan database dengan prosedur ini, dan sp_attach_db - kami akan menghubungkannya kembali. Ini akan menghapus log transaksi.
(Untuk informasi selengkapnya, lihat topik MSDN Q256650 (untuk SQL 7.0) dan Q272318 (untuk SQL 2000).)

Opsi 4: (Untuk 7.0)
DBCC SHRINKFILE(nama_file, ukuran_target)
DBCC SHRINKDATABASE (nama_database, target_persen)
LOG CADANGAN nama_database DENGAN TRUNCATE_ONLY

Jika jatuh terus berlanjut setelah operasi ini, ikuti terus rekomendasinya:

- Coba lakukan perubahan pada file HOST sistem operasi(kemungkinan besar cukup mendaftarkan asosiasi hanya dalam file di satu atau dua mesin, di mana crash paling sering terjadi)

— Coba pisahkan server perusahaan 1C dan SQL jika Anda memilikinya di mesin yang sama.

— Atau, sebaliknya, menginstalnya di satu mesin (jika Anda memiliki sumber daya yang cukup) Ada kalanya mentransfer server ke satu server membantu (Menurut pendapat saya, ini sangat meragukan dan berkaitan lebih spesifik dengan alasan memulai pekerjaan, ini adalah kompresi log transaksi)

— Periksa waktu respons server (kemungkinan besar, semuanya akan berada dalam batas normal, dan kegagalan waktu layanan yang jarang terjadi tidak dapat berdampak kuat pada pengoperasian server perusahaan)

— Periksa pengoperasian router di jaringan (Jarang, tetapi konfigurasi ulangnyalah yang memengaruhi jumlah kerusakan)

— Periksa konflik peralatan di jaringan (ini terkait dengan pertanyaan mengapa diinginkan untuk memiliki peralatan dari satu pemasok di jaringan. Siapa pun yang ingin dapat memeriksa, misalnya, dalam dokumentasi teknis 3COM tertulis: jika kartu jaringan mendeteksi bahwa ia berinteraksi dengan kartu serupa kartu jaringan, kemudian dapat dialihkan ke mode yang lebih produktif dengan beralih ke algoritma pemrosesan yang dioptimalkan paket jaringan, diuji untuk pengalaman pribadi kinerja melonjak hingga 50%)

— Periksa level sinyal konsumen/komputer akhir (mungkin sepele, tingkat rendah sinyal, konstan permintaan berulang blok, menunda antrian layanan di jaringan, dan akhirnya menerima pesan bahwa server akhir telah menutup koneksi ketika jumlah upaya melebihi waktu tunggu sinyal tiba. Jika Anda ingin mengerti masalah ini lihat protokol operasi Ethernet/CSMA CD/CSMA. Jumlah upaya untuk mengirimkan paket protokol ini bukan tidak terbatas...))) Dan buffer di kartu juga tidak terbatas.)

— Tambahkan memori ke server

— Mentransfer beberapa/semua pengguna ke mode terminal (yaitu menyediakan apa yang BANYAK pengguna definisikan sebagai THIN CLIENT 1C). Untuk server seperti itu, saya akan merekomendasikan Citrix Metaframe atau Terminal Server MS

Kemungkinan besar, ketika Anda mengikuti rekomendasi ini, dengan pengecualian menganalisis masalah dengan perangkat keras, stabilitas kerja akan meningkat sedemikian rupa sehingga kerusakan platform akan menjadi sangat jarang terjadi, yang akan menutup kesenjangan teknologi untuk pemeliharaan basis data, yang masih DIPERLUKAN untuk mengikuti dan jangan berpikir bahwa rekomendasi yang tercantum di atas adalah obat mujarab untuk semua masalah.

Mereka akan menyelesaikan banyak masalah, namun tidak semua masalah.

Dan Anda senang jika Anda tidak mempunyai masalah seperti itu; siapa pun yang memilikinya akan memahami saya.

———————————

Periksa peran "Pengguna" jika ada konfigurasi khas tentu saja, dan khususnya, setelah Anda menghitung masalah dokumen menggunakan , Anda perlu menemukan peran yang bermasalah (siapa yang mengeluh).
Selanjutnya, untuk peran Pengguna, lihat radar dokumen, jika pengaturan tambahan tidak (murni), kalau begitu klik kanan di atasnya - mencari tautan ke suatu objek, dan secara berurutan melihat radar untuk peran "Pengguna" untuk setiap objek.

Mengira intensitas pengguna yang tinggi sebagai serangan protokol dalam beberapa kasus Windows.
>Jalankan regedit.exe dan tambahkan nilai baru Tipe DWORD dengan nama SynAttackProtect ke registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ dan beri nilai 00000000
Masuk akal untuk melakukannya untuk Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx

Server 1C dan database pada satu mesin yang menjalankan Debian Squeeze.

Solusi: Setel parameter kernel tcp_syncookies ke 0.

root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(penulis Vadim Ivakhin)