rumah » Tren musim ini » Mempercepat file 1s 8.3. Kursus ini menjadi lebih rinci

Mempercepat file 1s 8.3. Kursus ini menjadi lebih rinci

Kirimkan artikel ini ke email saya

Seiring waktu, banyak pengguna 1C memperhatikan bahwa sistem mulai bekerja lebih lambat dan semakin sering “gangguan” bahkan ketika menggunakan konfigurasi standar “di luar kotak”.

Keluhan utama yang dicatat oleh pengguna:

Dokumen mulai diproses dengan lambat

Laporan membutuhkan waktu terlalu lama untuk dibuat

Program ini lebih sering macet

Keluhan yang familiar, bukan?

Mari kita coba memahami faktor utama yang menurunkan kinerja dan mencari solusinya.

Peralatan usang

Pertama-tama, kami akan menghilangkan kemungkinan masalah perangkat keras.

Untuk melakukan ini, Anda perlu memeriksa persyaratan perangkat keras 1C 8.3

Ini dapat dilakukan di situs resmi http://1c.ru/rus/products/1c/predpr/compat/hard/demand.htm

Platform ketinggalan jaman

Beberapa pengguna tidak suka memperbarui konfigurasi lagi, percaya bahwa versi sebelumnya bekerja lebih stabil. Sayangnya, konservatisme seperti itu dapat merugikan: pengembang memperbarui platform secara rutin, memperbaiki kesalahan dalam kode, dan mengoptimalkan mekanisme, sehingga menggunakan versi yang sudah ketinggalan zaman (dengan jeda rilis yang signifikan) dapat berdampak negatif pada kinerja.

Kinerja server buruk

Dimungkinkan untuk meningkatkan kinerja dengan mengedit pengaturan server SQL dan 1C:Enterprise.

Untuk melakukan ini, di BIOS kami mematikan semua opsi untuk menghemat daya prosesor dan mengatur kinerja ke maksimal. Lebih mudah untuk melakukan ini, misalnya, melalui utilitas PowerSchemeEd.

Disarankan untuk menonaktifkan layanan yang jarang digunakan. Layanan tersebut mencakup Pencarian Teks Penuh dan Layanan Integrasi

Jangan lupa untuk mengatur jumlah memori yang dialokasikan pada server secara maksimal. Ini diperlukan agar server SQL memiliki waktu untuk mengosongkan memori terlebih dahulu dan mengontrol pengisiannya.

Sebagai alternatif, dimungkinkan untuk mengalihkan layanan 1C ke mode debug. Berkat ini, optimasi 1C semakin ditingkatkan.

Basis data besar

Saat Anda bekerja, volume basis apa pun meningkat seiring waktu. Oleh karena itu, jangan lupakan pemeliharaan preventif sistem secara berkala. Lebih mudah untuk melakukan ini menggunakan alat standar “Menguji dan mengoreksi basis informasi”.

Alat ini akan membantu mengoptimalkan database melalui restrukturisasi dan pengindeksan ulang. Untuk menggunakan pemrosesan, Anda harus berada dalam mode konfigurator. Pemrosesannya terlihat seperti ini:

Konfigurasi tugas latar belakang dan rutin yang salah

Dianjurkan untuk mendefrag indeks dan memperbarui statistik setiap hari, karena dengan mengurangi fragmentasi indeks, optimasi 1C berkurang secara signifikan.

Dianjurkan untuk mendefrag dan memperbarui statistik pada frekuensi yang sama. Pengoperasiannya dilakukan dengan cepat, untuk melakukannya tidak perlu memutuskan sambungan pengguna aktif, dan akselerasi efektif 1C dari penggunaan telah terbukti.

Pengindeksan ulang penuh dilakukan ketika database terkunci. Ini adalah proses yang lebih lama, namun harus dilakukan setidaknya sekali seminggu bersamaan dengan defragmentasi dan pembaruan statistik.

Interaksi yang salah dengan perangkat lunak lain

Selain itu, masalah kinerja 1C:Enterprise mungkin terkait dengan perangkat lunak pra-instal lainnya.

Paling sering ini adalah antivirus dengan pengaturan yang salah. Oleh karena itu, untuk memastikan pengoperasian 1C yang benar, Anda perlu memeriksa pengaturan antivirus yang digunakan. Misalnya, untuk Kaspersky, pengaturannya ditunjukkan di situs web resmi https://support.kaspersky.ru/general/compatibility/11683

Saluran komunikasi tidak stabil

Paling sering, masalah ini relevan ketika bekerja di 1C melalui antarmuka WEB atau desktop jarak jauh. Jika perusahaan menggunakan akses jarak jauh, maka sangat penting untuk memeriksa fungsionalitas saluran komunikasi.

Akselerasi 1C dalam mode pengguna

Untungnya, dalam pengiriman modern, optimasi dan akselerasi 1C juga dilakukan dalam mode pengguna.

Pada tab "Dukungan dan Pemeliharaan" (Bagian "Administrasi") tersedia berbagai fungsi yang meningkatkan akselerasi 1C:

Menonaktifkan peluncuran otomatis tugas terjadwal yang tidak digunakan;

Nonaktifkan pencarian teks lengkap;

Pengurangan database periode sebelumnya;

Menghapus objek yang ditandai;

optimasi 1C

Tentu saja, optimalisasi dan akselerasi 1C dicapai tidak hanya dengan metode ini, jadi daftar tipnya bukanlah obat mujarab, tetapi hanya dapat memberikan gambaran umum tentang kemungkinan peningkatan pekerjaan.

Seringkali, masalah database memerlukan keterlibatan spesialis yang berkualifikasi, sehingga Anda selalu dapat menghubungi kami untuk meminta nasihat.

Sistem 1C menempati posisi dominan di pasar otomasi untuk usaha kecil dan menengah. Jika suatu perusahaan telah memilih sistem akuntansi 1C, maka biasanya hampir semua karyawan bekerja di dalamnya, mulai dari spesialis biasa hingga manajemen. Oleh karena itu, kecepatan proses bisnis perusahaan bergantung pada kecepatan 1C. Jika 1C bekerja pada kecepatan yang tidak memuaskan, maka hal ini secara langsung mempengaruhi kerja seluruh perusahaan dan keuntungan.

Sebenarnya ada tiga metode akselerasi 1C:

Peningkatan kapasitas perangkat keras.
Optimalisasi sistem operasi dan pengaturan DBMS.
Optimalisasi kode dan algoritma dalam 1C.

Metode pertama memerlukan pembelian peralatan dan lisensi, metode ketiga memerlukan banyak pekerjaan bagi pemrogram dan, akibatnya, kedua metode tersebut menimbulkan biaya finansial yang signifikan. Pertama-tama, Anda perlu memperhatikan kode program, karena tidak ada peningkatan kapasitas server yang dapat mengkompensasi kode yang salah. Setiap programmer tahu bahwa hanya dengan beberapa baris kode, Anda dapat membuat proses yang akan memuat sepenuhnya sumber daya server mana pun.

Jika suatu perusahaan yakin bahwa kode programnya sudah optimal, tetapi masih berjalan lambat, manajemen biasanya memutuskan untuk meningkatkan kapasitas server. Pada titik ini muncul pertanyaan logis: apa yang hilang, berapa banyak dan apa yang pada akhirnya perlu ditambahkan.

Perusahaan 1C memberikan jawaban yang agak kabur terhadap pertanyaan tentang berapa banyak sumber daya yang dibutuhkan, kami telah menulisnya sebelumnya di postingan kami. Oleh karena itu, Anda harus melakukan eksperimen secara mandiri dan mencari tahu apa yang bergantung pada kinerja 1C. Eksperimen dengan kinerja program di EFSOL dijelaskan di bawah ini.

Saat bekerja dengan 1C 8.2, terutama dengan konfigurasi yang menggunakan formulir terkelola, fakta aneh diketahui: 1C bekerja lebih cepat di stasiun kerja daripada di server yang kuat. Selain itu, semua karakteristik stasiun kerja lebih buruk daripada karakteristik server.

Tabel 1 - Konfigurasi tempat pengujian awal dilakukan

Workstation menunjukkan kinerja 155% lebih tinggi dibandingkan server 1C dengan karakteristik superior. Kami mulai mencari tahu apa yang sedang terjadi dan mempersempit pencarian.

Gambar 1 – Pengukuran kinerja di stasiun kerja menggunakan uji Gilev

Kecurigaan pertama adalah tes Gilev tidak memadai. Pengukuran pembukaan formulir, pengeposan dokumen, pembuatan laporan, dan lain-lain menggunakan alat instrumentasi menunjukkan bahwa tes Gilev menghasilkan penilaian yang sebanding dengan kecepatan kerja sebenarnya di 1C.

Jumlah dan frekuensi RAM

Analisis informasi yang tersedia di Internet menunjukkan bahwa banyak yang menulis tentang ketergantungan kinerja 1C pada frekuensi memori. Itu tergantung pada frekuensinya, bukan volumenya. Kami memutuskan untuk menguji hipotesis ini, karena kami memiliki frekuensi RAM 1066 Mhz di server versus 1333 Mhz di workstation, dan jumlah RAM di server sudah jauh lebih tinggi. Kami memutuskan untuk segera menginstal bukan 1066 Mhz, tetapi 800 Mhz agar efek ketergantungan kinerja pada frekuensi memori lebih jelas. Dampaknya produktivitas turun 12% menjadi 39,37 unit. Kami memasang memori dengan frekuensi 1333 Mhz, bukan 1066 Mhz di server dan menerima sedikit peningkatan kinerja - sekitar 11%. Produktivitasnya adalah 19,53 unit. Oleh karena itu, ini bukan soal memori, meski frekuensinya memberikan sedikit peningkatan.

Gambar 2 – Pengukuran kinerja pada workstation setelah menurunkan frekuensi RAM

Gambar 3 – Pengukuran kinerja pada server setelah peningkatan frekuensi RAM

Subsistem disk

Hipotesis selanjutnya terkait dengan subsistem disk. Dua asumsi segera muncul:

SSD lebih baik daripada drive SAS, meskipun berada dalam serangan 10.
iSCSI lambat atau salah.

Oleh karena itu, disk SATA biasa dipasang di stasiun kerja alih-alih SSD, dan hal yang sama dilakukan dengan server - database ditempatkan pada disk SATA lokal. Hasilnya, pengukuran kinerja tidak berubah sama sekali. Kemungkinan besar, ini terjadi karena jumlah RAM yang cukup dan disk praktis tidak terlibat selama pengujian.

CPU

Prosesor di server tentu saja lebih bertenaga dan ada dua, tetapi frekuensinya sedikit lebih rendah dibandingkan di workstation. Kami memutuskan untuk memeriksa pengaruh frekuensi prosesor terhadap kinerja: tidak ada prosesor dengan frekuensi lebih tinggi untuk server, jadi kami menurunkan frekuensi prosesor di workstation. Langsung kita turunkan menjadi 1,6 agar korelasinya semakin jelas. Pengujian menunjukkan bahwa kinerja turun secara signifikan, tetapi bahkan dengan prosesor 1,6, stasiun kerja menghasilkan hampir 28 unit, yang hampir 1,5 kali lebih banyak daripada di server.

Gambar 4 – Pengukuran kinerja pada workstation dengan prosesor 1,6 Ghz

Kartu video

Ada informasi di Internet bahwa kinerja 1C dapat dipengaruhi oleh kartu video. Kami mencoba menggunakan video terintegrasi stasiun kerja, adaptor profesional Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, kartu video GeForce 16MbSDR lama. Selama uji Gilev, tidak ada perbedaan signifikan yang terlihat. Mungkin kartu video masih berpengaruh, tetapi dalam kondisi nyata, ketika Anda perlu membuka formulir terkelola, dll.

DI DALAM saat ini Ada dua kecurigaan mengapa workstation bekerja lebih cepat bahkan dengan karakteristik yang jauh lebih buruk:

CPU. Jenis prosesor pada workstation lebih cocok untuk 1C.
chipset. Selain daripada itu kondisi yang setara Workstation kami memiliki chipset yang lebih baru, jadi mungkin itulah masalahnya.

Kami berencana untuk membeli komponen yang diperlukan dan melanjutkan pengujian untuk akhirnya mengetahui apa yang sangat bergantung pada kinerja 1C. Selagi proses persetujuan dan pengadaan sedang berlangsung, kami memutuskan untuk melakukan optimalisasi, apalagi tidak memerlukan biaya apa pun. Tahapan berikut diidentifikasi:

Tahap 1. Pengaturan sistem

Pertama, mari kita lakukan pengaturan berikut pada BIOS dan sistem operasi:

Di BIOS server, kami menonaktifkan semua pengaturan untuk menghemat daya prosesor.
Pilih paket “Kinerja maksimum” di sistem operasi.
Prosesornya juga disetel untuk performa maksimal. Hal ini dapat dilakukan dengan menggunakan utilitas PowerSchemeEd.

Tahap 2. Menyiapkan SQL server dan 1C:Enterprise server

Kami membuat perubahan berikut pada pengaturan server DBMS dan 1C:Enterprise.

Menyiapkan protokol Memori Bersama:
- Memori Bersama hanya akan diaktifkan pada platform mulai dari 1C 8.2.17; pada rilis sebelumnya, Named Pipe akan diaktifkan - sedikit lebih rendah dalam kecepatan operasi. Teknologi ini hanya berfungsi jika layanan 1C dan MSSQL diinstal pada server fisik atau virtual yang sama.
Disarankan untuk mengalihkan layanan 1C ke mode debug, karena, secara paradoks, ini memberikan peningkatan kinerja. Secara default, debugging dinonaktifkan di server.
Menyiapkan server SQL:
- Kami hanya memerlukan server, layanan lain yang terkait dengannya dan, mungkin, seseorang menggunakannya, hanya memperlambat pekerjaan. Kami menghentikan dan menonaktifkan layanan seperti: Pencarian Teks Lengkap (1C memiliki mekanisme pencarian teks lengkapnya sendiri), Layanan Integrasi, dll.
- Kami menetapkan jumlah maksimum memori yang dialokasikan ke server. Ini diperlukan agar server SQL menghitung jumlah ini dan mengosongkan memori terlebih dahulu.
- Install jumlah maksimum utas (Utas pekerja maksimum) dan atur peningkatan prioritas server (Prioritas peningkatan).

Tahap 3: Menyiapkan database produksi

Setelah server DBMS dan 1C:Enterprise dioptimalkan, kita beralih ke pengaturan database. Jika database belum diperluas dari file .dt, dan Anda mengetahui perkiraan ukurannya, maka lebih baik segera menunjukkan ukuran inisialisasi ke file utama dengan “>=” dari ukuran database, tetapi ini adalah masalah rasanya, itu masih akan tumbuh selama ekspansi. Namun ukuran Peningkatan otomatis harus ditentukan: sekitar 200 MB per basis dan 50 MB per log, karena Nilai default – pertumbuhan sebesar 1 MB dan 10% sangat memperlambat kerja server ketika perlu menambah file setiap transaksi ke-3. Selain itu, sebaiknya tentukan penyimpanan file database dan file log pada disk fisik atau grup RAID yang berbeda jika array RAID digunakan, dan batasi pertumbuhan log. Disarankan untuk memindahkan file Tempdb ke array berkecepatan tinggi, karena DBMS cukup sering mengaksesnya.

Tahap 4. Menyiapkan tugas terjadwal

Tugas terjadwal dibuat cukup sederhana menggunakan Rencana Pemeliharaan di bagian Manajemen, menggunakan alat grafis, jadi kami tidak akan menjelaskan secara rinci bagaimana hal ini dilakukan. Mari kita lihat operasi apa yang perlu dilakukan untuk meningkatkan produktivitas.

Defragmentasi indeks dan pemutakhiran statistik harus dilakukan setiap hari, karena jika fragmentasi indeks > 25%, hal ini akan mengurangi kinerja server secara drastis.
Defragmentasi dan pembaruan statistik dilakukan dengan cepat dan tidak memerlukan pemutusan koneksi pengguna. Disarankan juga untuk melakukannya setiap hari.
Pengindeksan ulang penuh – dilakukan dengan database diblokir, disarankan untuk melakukannya setidaknya seminggu sekali. Biasanya, setelah pengindeksan ulang selesai, indeks segera didefragmentasi dan statistik diperbarui.

Hasilnya, dengan bantuan penyempurnaan sistem, server SQL, dan database yang berfungsi, kami berhasil meningkatkan produktivitas sebesar 46%. Pengukuran dilakukan dengan menggunakan alat 1C KIP dan menggunakan uji Gilev. Yang terakhir menunjukkan 25,6 unit versus 17,53 yang aslinya.

Kesimpulan singkat

Performa 1C tidak terlalu bergantung pada frekuensi RAM. Setelah jumlah memori yang cukup tercapai, perluasan memori lebih lanjut tidak masuk akal, karena tidak menghasilkan peningkatan kinerja.
Performa 1C tidak bergantung pada kartu video.
Kinerja 1C tidak bergantung pada subsistem disk, asalkan antrian baca atau tulis disk tidak terlampaui. Jika drive SATA dipasang dan antriannya tidak terlampaui, memasang SSD tidak akan meningkatkan kinerja.
Performanya sangat bergantung pada frekuensi prosesor.
Dengan konfigurasi sistem operasi dan server MSSQL yang tepat, peningkatan kinerja 1C dapat dicapai sebesar 40-50% tanpa biaya material apa pun.

PERHATIAN! Sangat poin penting! Semua pengukuran dilakukan berdasarkan tes menggunakan tes Gilev dan alat instrumentasi 1C. Perilaku database nyata dengan pengguna sebenarnya mungkin berbeda dari hasil yang diperoleh. Misalnya, dalam database pengujian kami tidak menemukan ketergantungan kinerja pada kartu video dan jumlah RAM. Kesimpulan tersebut cukup dipertanyakan dan dalam kondisi nyata faktor-faktor tersebut dapat memberikan dampak yang signifikan terhadap kinerja. Saat bekerja dengan konfigurasi yang menggunakan formulir terkelola, kartu video penting dan prosesor grafis yang kuat mempercepat pekerjaan dalam hal menggambar antarmuka program, secara visual hal ini diwujudkan dalam lebih banyak kerja cepat 1C.

Apakah 1C Anda berjalan lambat? Pesan pemeliharaan TI untuk komputer dan server oleh spesialis EFSOL dengan pengalaman bertahun-tahun atau transfer 1C Anda ke server virtual 1C yang kuat dan toleran terhadap kesalahan.

Integrasi sistem. Konsultasi

Kami sering menerima pertanyaan tentang apa yang memperlambat 1c, terutama saat beralih ke versi 1c 8.3, terima kasih kepada rekan-rekan kami dari Interface LLC, kami memberi tahu Anda secara detail:

Dalam publikasi kami sebelumnya, kami telah menyentuh dampak kinerja subsistem disk terhadap kecepatan 1C, namun penelitian ini berkaitan dengan penggunaan lokal aplikasi pada PC atau server terminal terpisah. Pada saat yang sama, sebagian besar implementasi kecil melibatkan bekerja dengan database file melalui jaringan, di mana salah satu PC pengguna digunakan sebagai server, atau server file khusus berdasarkan komputer biasa, seringkali juga murah.

Sebuah studi kecil tentang sumber daya berbahasa Rusia di 1C menunjukkan bahwa masalah ini dihindari dengan rajin, jika masalah muncul, biasanya disarankan untuk beralih ke mode client-server atau terminal. Hampir secara umum diterima bahwa konfigurasi pada aplikasi terkelola bekerja jauh lebih lambat dari biasanya. Biasanya, argumen yang diberikan adalah “besi”: “Akuntansi 2.0 baru saja terbang, tetapi “troika” hampir tidak bergerak,” tentu saja, ada benarnya kata-kata ini, jadi mari kita coba mencari tahu.

Konsumsi sumber daya, sekilas

Sebelum memulai studi ini, kami menetapkan dua tujuan: untuk mengetahui apakah konfigurasi berbasis aplikasi terkelola sebenarnya lebih lambat dibandingkan konfigurasi konvensional, dan sumber daya spesifik mana yang memiliki dampak utama terhadap kinerja.

Untuk pengujian, kami mengambil dua mesin virtual yang masing-masing menjalankan Windows Server 2012 R2 dan Windows 8.1, mengalokasikannya dengan 2 inti host Core i5-4670 dan 2 GB memori akses acak, yang kira-kira setara dengan rata-rata mesin kantor. Server ditempatkan pada array RAID 0 dari dua WD Se, dan klien ditempatkan pada array serupa dari disk serba guna.

Sebagai basis eksperimental, kami memilih beberapa konfigurasi Accounting 2.0, rilis 2.0.64.12 , yang kemudian diperbarui menjadi 3.0.38.52 , semua konfigurasi diluncurkan pada platform 8.3.5.1443 .

Hal pertama yang menarik perhatian adalah peningkatan ukuran basis informasi Troika, yang telah tumbuh secara signifikan, serta kebutuhan RAM yang jauh lebih besar:

Kami siap mendengar pertanyaan biasa: “mengapa mereka menambahkan itu ke tiga ini,” tapi jangan terburu-buru. Berbeda dengan pengguna versi client-server, yang memerlukan administrator yang kurang lebih berkualifikasi, pengguna versi file jarang berpikir untuk memelihara database. Selain itu, karyawan perusahaan khusus yang melayani (baca memperbarui) database ini jarang memikirkan hal ini.

Sementara itu, basis informasi 1C adalah DBMS lengkap dengan formatnya sendiri, yang juga memerlukan pemeliharaan, dan untuk ini bahkan ada alat yang disebut Menguji dan memperbaiki basis informasi. Mungkin namanya memainkan lelucon yang kejam, yang entah bagaimana menyiratkan bahwa ini adalah alat untuk memecahkan masalah, tetapi kinerja yang rendah juga merupakan masalah, dan restrukturisasi dan pengindeksan ulang, bersama dengan kompresi tabel, adalah alat yang terkenal untuk mengoptimalkan database untuk administrator DBMS mana pun. . Bisakah kita memeriksanya?

Setelah menerapkan tindakan yang dipilih, database “menurunkan bobot” secara tajam, menjadi lebih kecil dari “dua”, yang belum pernah dioptimalkan oleh siapa pun, dan konsumsi RAM juga sedikit menurun.

Selanjutnya, setelah memuat pengklasifikasi dan direktori baru, membuat indeks, dll. ukuran alas akan bertambah; secara umum, “tiga” alas lebih besar dari pada “dua” alas. Namun hal ini tidak lebih penting, jika versi kedua puas dengan RAM 150-200 MB, maka edisi baru Anda sudah membutuhkan setengah gigabyte, dan Anda harus melanjutkan dari nilai ini ketika merencanakan sumber daya yang diperlukan untuk bekerja dengan program ini.

Bersih

Bandwidth jaringan adalah salah satu parameter terpenting untuk aplikasi jaringan, terutama seperti 1C dalam mode file, yang memindahkan sejumlah besar data melalui jaringan. Sebagian besar jaringan perusahaan kecil dibangun berdasarkan peralatan murah dengan kecepatan 100 Mbit/s, jadi kami memulai pengujian dengan membandingkan indikator kinerja 1C dalam jaringan 100 Mbit/s dan 1 Gbit/s.

Apa yang terjadi ketika Anda meluncurkan database file 1C melalui jaringan? Klien mengunduh sejumlah besar informasi ke dalam folder sementara, terutama jika ini adalah permulaan "dingin" yang pertama. Pada kecepatan 100 Mbit/s, kita diperkirakan akan mengalami lebar saluran dan pengunduhan dapat memakan banyak waktu, dalam kasus kita sekitar 40 detik (biaya membagi grafik adalah 4 detik).

Peluncuran kedua lebih cepat karena sebagian data disimpan dalam cache dan tetap di sana hingga reboot. Beralih ke jaringan gigabit dapat mempercepat pemuatan program secara signifikan, baik "dingin" maupun "panas", dan rasio nilainya tetap terjaga. Oleh karena itu, kami memutuskan untuk menyatakan hasilnya dalam nilai relatif, mengambil yang terbanyak sangat penting setiap pengukuran:

Seperti yang dapat Anda lihat dari grafik, Accounting 2.0 memuat dua kali lebih cepat pada kecepatan jaringan apa pun, transisi dari 100 Mbit/s ke 1 Gbit/s memungkinkan Anda mempercepat waktu pengunduhan sebanyak empat kali lipat. Tidak ada perbedaan antara database "troika" yang dioptimalkan dan tidak dioptimalkan dalam mode ini.

Kami juga memeriksa pengaruh kecepatan jaringan terhadap pengoperasian dalam mode berat, misalnya, selama transfer grup. Hasilnya juga dinyatakan dalam nilai relatif:

Ini yang lebih menarik, basis "tiga" yang dioptimalkan dalam jaringan 100 Mbit/s bekerja pada kecepatan yang sama dengan "dua", dan basis yang tidak dioptimalkan menunjukkan hasil dua kali lebih buruk. Pada gigabit, rasionya tetap sama, "tiga" yang tidak dioptimalkan juga setengah lebih lambat dari "dua", dan yang dioptimalkan tertinggal sepertiga. Selain itu, transisi ke 1 Gbit/s memungkinkan Anda mengurangi waktu eksekusi sebanyak tiga kali lipat untuk edisi 2.0 dan setengahnya untuk edisi 3.0.

Untuk mengevaluasi dampak kecepatan jaringan pada pekerjaan sehari-hari, kami menggunakan Pengukuran kinerja, melakukan serangkaian tindakan yang telah ditentukan di setiap database.

Sebenarnya, untuk tugas sehari-hari, throughput jaringan bukanlah hambatan, "tiga" yang tidak dioptimalkan hanya 20% lebih lambat dari "dua", dan setelah pengoptimalan ternyata lebih cepat - keuntungan bekerja dalam mode klien tipis jelas. Transisi ke 1 Gbit/s tidak memberikan keuntungan apa pun pada basis yang dioptimalkan, dan basis yang tidak dioptimalkan dan keduanya mulai bekerja lebih cepat, menunjukkan perbedaan kecil di antara keduanya.

Dari pengujian yang dilakukan, terlihat jelas bahwa jaringan bukanlah hambatan untuk konfigurasi baru, dan aplikasi yang dikelola berjalan lebih cepat dari biasanya. Anda juga dapat merekomendasikan untuk beralih ke 1 Gbit/dtk jika tugas berat dan kecepatan pemuatan basis data sangat penting bagi Anda; dalam kasus lain, konfigurasi baru memungkinkan Anda bekerja secara efektif bahkan di jaringan lambat 100 Mbit/dtk.

Jadi mengapa 1C lambat? Kami akan memeriksanya lebih jauh.

Subsistem disk server dan SSD

Pada artikel sebelumnya, kami mencapai peningkatan kinerja 1C dengan menempatkan database pada SSD. Mungkin kinerja subsistem disk server tidak mencukupi? Kami mengukur kinerja server disk selama menjalankan grup di dua database sekaligus dan mendapatkan hasil yang cukup optimis.

Meskipun jumlah operasi input/output per detik (IOPS) relatif besar - 913, panjang antrian tidak melebihi 1,84, yang merupakan jumlah yang sangat besar. hasil yang bagus. Berdasarkan hal ini, kita dapat berasumsi bahwa cermin yang terbuat dari disk biasa akan cukup untuk operasi normal 8-10 klien jaringan dalam mode berat.

Jadi apakah SSD diperlukan di server? Cara terbaik untuk menjawab pertanyaan ini adalah melalui pengujian, yang kami lakukan menggunakan metode serupa, koneksi jaringan di mana-mana adalah 1 Gbit/s, hasilnya juga dinyatakan dalam nilai relatif.

Mari kita mulai dengan kecepatan memuat database.

Ini mungkin tampak mengejutkan bagi sebagian orang, tetapi SSD di server tidak mempengaruhi kecepatan memuat database. Faktor pembatas utama di sini, seperti yang ditunjukkan pengujian sebelumnya, adalah throughput jaringan dan kinerja klien.

Mari lanjutkan ke pengerjaan ulang:

Kami telah mencatat di atas bahwa kinerja disk cukup memadai bahkan untuk bekerja dalam mode berat, sehingga kecepatan SSD juga tidak terpengaruh, kecuali untuk basis yang tidak dioptimalkan, yang pada SSD telah menyusul basis yang dioptimalkan. Sebenarnya, ini sekali lagi menegaskan bahwa operasi optimasi mengatur informasi dalam database, mengurangi jumlah operasi I/O acak dan meningkatkan kecepatan akses ke database.

Dalam tugas sehari-hari gambarannya serupa:

Hanya database yang tidak dioptimalkan yang mendapat manfaat dari SSD. Anda, tentu saja, dapat membeli SSD, tetapi akan lebih baik jika memikirkan pemeliharaan database yang tepat waktu. Juga, jangan lupa tentang mendefrag bagian dengan basis info di server.

Subsistem disk klien dan SSD

Kami membahas pengaruh SSD pada kecepatan pengoperasian 1C yang dipasang secara lokal di materi sebelumnya, sebagian besar hal di atas juga berlaku untuk bekerja dalam mode jaringan. Memang, 1C cukup aktif menggunakan sumber daya disk, termasuk untuk tugas latar belakang dan rutin. Pada gambar di bawah ini Anda dapat melihat bagaimana Accounting 3.0 cukup aktif mengakses disk selama sekitar 40 detik setelah booting.

Namun pada saat yang sama, Anda harus menyadari bahwa untuk stasiun kerja di mana pekerjaan aktif dilakukan dengan satu atau dua database informasi, sumber daya kinerja HDD produksi massal biasa sudah cukup. Membeli SSD dapat mempercepat beberapa proses, namun mempercepatnya secara radikal pekerjaan sehari-hari Anda tidak akan menyadarinya karena, misalnya, unduhan akan dibatasi keluaran jaringan.

Hard drive yang lambat dapat memperlambat beberapa operasi, namun hard drive itu sendiri tidak dapat menyebabkan program melambat.

RAM

Terlepas dari kenyataan bahwa RAM sekarang sangat murah, banyak workstation terus bekerja dengan jumlah memori yang terpasang saat dibeli. Di sinilah masalah pertama menunggu. Berdasarkan fakta bahwa rata-rata “troika” membutuhkan sekitar 500 MB memori, kita dapat berasumsi bahwa jumlah total RAM sebesar 1 GB tidak akan cukup untuk menjalankan program tersebut.

Kami mengurangi memori sistem menjadi 1 GB dan meluncurkan dua database informasi.

Pada pandangan pertama, semuanya tidak terlalu buruk, program ini telah mengekang seleranya dan cocok dengan memori yang tersedia, namun jangan lupa bahwa kebutuhan akan data operasional tidak berubah, lalu kemana perginya? Dibuang ke disk, cache, swap, dll. Inti dari operasi ini adalah data yang tidak diperlukan saat ini dikirim dari RAM cepat, yang jumlahnya tidak cukup, untuk memperlambat memori disk.

Kemana arahnya? Mari kita lihat bagaimana sumber daya sistem digunakan dalam operasi berat, misalnya, mari kita luncurkan transfer ulang grup di dua database sekaligus. Pertama pada sistem dengan RAM 2 GB:

Seperti yang bisa kita lihat, sistem secara aktif menggunakan jaringan untuk menerima data dan prosesor untuk memprosesnya; aktivitas disk tidak signifikan; selama pemrosesan kadang-kadang meningkat, namun bukan merupakan faktor pembatas.

Sekarang mari kita kurangi memori menjadi 1 GB:

Situasi berubah secara radikal, beban utama sekarang jatuh pada hard drive, prosesor dan jaringan menganggur, menunggu sistem membaca data yang diperlukan dari disk ke dalam memori dan mengirim data yang tidak perlu ke sana.

Pada saat yang sama, bahkan pekerjaan subjektif dengan dua database terbuka pada sistem dengan memori 1 GB ternyata sangat tidak nyaman; direktori dan majalah dibuka dengan penundaan yang signifikan dan akses aktif ke disk. Misalnya, pembukaan jurnal Penjualan Barang dan Jasa memakan waktu sekitar 20 detik dan selama ini disertai dengan aktivitas disk yang tinggi (disorot dengan garis merah).

Untuk mengevaluasi secara obyektif dampak RAM terhadap kinerja konfigurasi berdasarkan aplikasi yang dikelola, kami melakukan tiga pengukuran: kecepatan memuat database pertama, kecepatan memuat database kedua, dan menjalankan ulang grup di salah satu database . Kedua database tersebut benar-benar identik dan dibuat dengan menyalin database yang dioptimalkan. Hasilnya dinyatakan dalam satuan relatif.

Hasilnya berbicara sendiri: jika waktu pemuatan meningkat sekitar sepertiga, yang masih cukup dapat ditoleransi, maka waktu untuk melakukan operasi dalam database meningkat tiga kali lipat, tidak perlu membicarakan tentang pekerjaan yang nyaman dalam kondisi seperti itu. Omong-omong, membeli SSD dapat memperbaiki situasi, tetapi jauh lebih mudah (dan lebih murah) untuk mengatasi penyebabnya, bukan konsekuensinya, dan cukup membeli jumlah RAM yang tepat.

Kurangnya RAM adalah alasan utama mengapa bekerja dengan konfigurasi 1C baru menjadi tidak nyaman. Konfigurasi dengan memori internal 2 GB harus dianggap sesuai minimal. Pada saat yang sama, perlu diingat bahwa dalam kasus kami, kondisi "rumah kaca" diciptakan: sistem yang bersih, hanya 1C dan pengelola tugas yang berjalan. Dalam kehidupan nyata, di komputer kerja, biasanya browser, office suite terbuka, antivirus berjalan, dll., dll., jadi lanjutkan dari kebutuhan 500 MB per database, ditambah beberapa cadangan, sehingga selama pengoperasian berat, Anda tidak mengalami kekurangan memori dan penurunan produktivitas yang tajam.

CPU

Tanpa berlebihan, prosesor pusat dapat disebut sebagai jantungnya komputer, karena pada akhirnya memproses semua perhitungan. Untuk mengevaluasi perannya, kami melakukan serangkaian pengujian lain, sama seperti pada RAM, mengurangi jumlah inti yang tersedia untuk mesin virtual dari dua menjadi satu, dan pengujian dilakukan dua kali dengan jumlah memori 1 GB dan 2 GB.

Hasilnya ternyata cukup menarik dan tidak terduga: prosesor yang lebih bertenaga cukup efektif mengatasi beban ketika ada kekurangan sumber daya, di waktu lain tanpa memberikan keuntungan nyata. 1C Enterprise hampir tidak bisa disebut sebagai aplikasi yang secara aktif menggunakan sumber daya prosesor; ini tidak terlalu menuntut. Dan dalam kondisi sulit, prosesor tidak terlalu terbebani dengan menghitung data aplikasi itu sendiri, tetapi dengan membayar biaya overhead: operasi input/output tambahan, dll.

kesimpulan

Jadi mengapa 1C lambat? Pertama-tama, ini adalah kurangnya RAM, beban utama dalam hal ini jatuh pada hard drive dan prosesor. Dan jika kinerjanya tidak bersinar, seperti yang biasanya terjadi pada konfigurasi kantor, maka kita mendapatkan situasi yang dijelaskan di awal artikel - "dua" berfungsi dengan baik, tetapi "tiga" sangat lambat.

Yang kedua adalah kinerja jaringan; saluran lambat 100 Mbit/s dapat menjadi hambatan nyata, namun pada saat yang sama, mode klien tipis mampu mempertahankan tingkat pengoperasian yang cukup nyaman bahkan pada saluran lambat.

Maka Anda harus memperhatikan disk drive; membeli SSD sepertinya bukan investasi yang baik, tetapi mengganti drive dengan yang lebih modern adalah ide yang bagus. Perbedaan generasi harddisk dapat dinilai dari materi berikut ini: Review dua drive murah seri Western Digital Blue 500 GB dan 1 TB.

Dan yang terakhir adalah prosesor. Model yang lebih cepat tentu tidak akan berlebihan, tapi sangat masuk akal Tidak ada cara untuk meningkatkan kinerjanya, kecuali PC ini digunakan operasi berat: pemrosesan grup, laporan berat, penutupan bulan, dll.

Kami berharap materi ini akan membantu Anda dengan cepat memahami pertanyaan “mengapa 1C lambat” dan menyelesaikannya dengan paling efektif dan tanpa biaya tambahan.

Dengan dirilisnya platform 8.2, banyak pengguna mencatat penurunan kecepatan program, waktu respons saat mengklik tautan meningkat, dan laporan mulai dibuat lebih lambat. Faktanya, 1c tidak menjadi lebih lambat, hanya saja seiring berkembangnya teknologi, banyak muncul fungsi tambahan yang tidak dibutuhkan semua orang. Namun kami punya kabar baik - semua fungsi ini dapat dinonaktifkan sesuai kebijaksanaan dan keinginan pengguna. Mari kita lihat semua alasan mengapa 1C mungkin bekerja pada kecepatan yang tidak memuaskan.

Akselerasi program menggunakan contoh 1C: Accounting

Hal pertama yang akan kita lakukan adalah nonaktifkan mekanisme pencarian teks lengkap.

Kami masuk ke program Akuntansi 1C kami;
Di sudut kiri atas, klik panah bawah dan pilih -> “Layanan” -> “Opsi”. Seperti yang ditunjukkan pada tangkapan layar;
Beri tanda centang pada kotak perintah “Tampilkan Semua Fungsi”. Seperti yang ditunjukkan pada tangkapan layar;
Sekali lagi, di sudut kiri atas, klik panah bawah dan pilih “Semua fungsi”, seperti yang ditunjukkan pada tangkapan layar;
Gulir daftar ke paling bawah, klik dua kali di pohon objek dan pilih “Standar” -> “Manajemen pencarian teks lengkap”;
Klik tombol “Mati”, sehingga menonaktifkan mekanisme pencarian teks lengkap;

Pencarian teks lengkap dinonaktifkan, sekarang Anda perlu melakukannya nonaktifkan tugas rutin yang tidak perlu:

Di panel navigasi, seperti yang ditunjukkan pada tangkapan layar, buka tab "Administrasi", di sana pilih "Tugas rutin dan latar belakang" Jika item "Tugas rutin dan latar belakang" tidak ada, lihat sudut kanan atas, klik tautan "Pengaturan navigasi"
Di panel pengaturan navigasi, di kolom kiri kita temukan dan pilih "Tugas rutin dan latar belakang", klik tombol "Tambah", lalu "OK", seperti yang ditunjukkan pada gambar.
Jadi, mari kita pergi ke “Tugas rutin dan latar belakang”, seperti yang ditunjukkan pada poin 1;
Untuk menonaktifkan tugas terjadwal, klik kanan pada Namanya dan pilih Nonaktifkan;
Jika mau, Anda dapat menonaktifkan semua tugas rutin dan sistem akan tetap bekerja dengan sempurna. Kami tidak menyarankan mematikan monitor akuntan.

Tindakan ini dijamin akan meningkatkan kecepatan 1C dan kinerja sistem. Pembekuan akan dihilangkan, dan waktu pemuatan program akan berkurang secara signifikan.

Alasan penurunan kecepatan kerja di 1C

Menggunakan program yang dimodifikasi oleh programmer yang tidak bermoral. Salah satu alasannya mungkin karena kualitas perbaikan perangkat lunak;
Kesalahan dalam pengaturan program;
Kesalahan dalam pengaturan peralatan;
Kesalahan dalam pengaturan perangkat lunak eksternal, server;

Artikel ini mengidentifikasi kesalahan utama yang dilakukan administrator 1C pemula dan menunjukkan cara mengatasinya menggunakan tes Gilev sebagai contoh.

Tujuan utama penulisan artikel ini adalah untuk menghindari terulangnya nuansa yang jelas bagi para administrator (dan pemrogram) yang belum memperoleh pengalaman dengan 1C.

Tujuan kedua adalah jika saya memiliki kekurangan, Infostart akan menjadi yang tercepat untuk menunjukkan hal ini kepada saya.

Tes V. Gilev telah menjadi semacam standar “de facto”. Penulis di websitenya memberikan rekomendasi yang cukup jelas, namun saya hanya akan menyajikan beberapa hasil dan mengomentari kesalahan yang paling mungkin terjadi. Tentu saja, hasil pengujian pada peralatan Anda mungkin berbeda; ini hanyalah panduan tentang apa yang seharusnya dan apa yang dapat Anda perjuangkan. Saya ingin segera mencatat bahwa perubahan harus dilakukan selangkah demi selangkah, dan setelah setiap langkah, periksa hasil apa yang dihasilkannya.

Ada artikel serupa di Infostart, saya akan meletakkan tautannya di bagian yang relevan (jika saya melewatkan sesuatu, silakan sarankan saya di komentar, saya akan menambahkannya). Jadi, anggap saja 1C Anda lambat. Bagaimana cara mendiagnosis masalah, dan bagaimana memahami siapa yang harus disalahkan, administrator atau pemrogram?

Data awal:

Komputer yang diuji, kelinci percobaan utama: HP DL180G6, dilengkapi dengan 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Sebagai perbandingan, Core i3-2100 menunjukkan hasil yang sebanding dalam pengujian single-threaded. Peralatan yang sengaja saya pilih bukanlah yang terbaru, dengan peralatan yang modern hasilnya terasa lebih baik.

Untuk menguji server 1C dan SQL terpisah, server SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Untuk menguji jaringan 10 Gbit, adaptor Intel 520-DA2 digunakan.

Versi berkas. (database ada di server dalam folder bersama, klien terhubung melalui jaringan, protokol CIFS/SMB). Algoritma langkah demi langkah:

0. Tambahkan database pengujian Gilev ke server file di folder yang sama dengan database utama. Kami terhubung dari komputer klien dan menjalankan pengujian. Kami ingat hasilnya.

Dapat dipahami bahwa bahkan untuk komputer lama dari 10 tahun yang lalu (Pentium pada soket 775), waktu mulai dari mengklik pintasan 1C:Enterprise hingga tampilan jendela database akan memakan waktu kurang dari satu menit. (Celeron = lambat).

Jika komputer Anda lebih buruk daripada Pentium pada soket 775 dengan RAM 1 GB, maka saya bersimpati dengan Anda, dan akan sulit bagi Anda untuk mencapai pekerjaan yang nyaman pada 1C 8.2 dalam versi file. Pikirkan untuk mengupgrade (ini saatnya) atau beralih ke server terminal (atau web, dalam kasus klien tipis dan formulir terkelola).

Jika kondisi komputer tidak lebih buruk, maka Anda dapat menendang administrator. Minimal, periksa pengoperasian jaringan, antivirus, dan driver perlindungan pengait.

Jika pengujian Gilev pada tahap ini menunjukkan 30 "burung beo" atau lebih tinggi, tetapi database 1C yang berfungsi masih berjalan lambat, hubungi programmer.

1. Sebagai panduan seberapa banyak komputer klien dapat “memeras”, kami memeriksa pengoperasian hanya komputer ini, tanpa jaringan. Kami menginstal database pengujian di komputer lokal (pada disk yang sangat cepat). Jika komputer klien tidak memiliki SSD normal, maka ramdisk akan dibuat. Untuk saat ini yang paling sederhana dan gratis adalah Ramdisk enterprise.

Untuk menguji versi 8.2, ramdisk 256 MB sudah cukup, dan! Yang paling penting. Setelah me-reboot komputer, dengan ramdisk berjalan, seharusnya ada 100-200 MB kosong di dalamnya. Oleh karena itu, tanpa ramdisk, untuk pengoperasian normal, harus ada 300-400 MB memori bebas.

Untuk menguji versi 8.3, ramdisk 256 MB sudah cukup, namun Anda memerlukan lebih banyak RAM kosong.

Saat menguji, Anda perlu melihat beban prosesor. Dalam kasus yang mendekati ideal (ramdisk), file lokal 1c memuat 1 inti prosesor saat dijalankan. Oleh karena itu, jika selama pengujian inti prosesor Anda tidak terisi penuh, carilah titik lemahnya. Sedikit emosional, tetapi secara umum benar, pengaruh prosesor terhadap pengoperasian 1C dijelaskan di sini. Sekadar referensi, bahkan pada Core i3 modern dengan frekuensi tinggi, angka 70-80 cukup realistis.

Kesalahan paling umum pada tahap ini.

Antivirus yang tidak dikonfigurasi dengan benar. Ada banyak antivirus, pengaturan masing-masing berbeda, saya hanya akan mengatakan bahwa dengan konfigurasi yang tepat, baik web maupun Kaspersky 1C tidak akan mengganggu. Dengan pengaturan default, sekitar 3-5 burung beo (10-15%) dapat diambil.
Mode performa. Untuk beberapa alasan, hanya sedikit orang yang memperhatikan hal ini, tetapi efeknya paling signifikan. Jika Anda membutuhkan kecepatan, maka Anda harus melakukan ini, baik di komputer klien maupun server. (Gilev memiliki deskripsi yang bagus. Satu-satunya peringatan adalah pada beberapa motherboard, jika Anda mematikan Intel SpeedStep, Anda tidak dapat mengaktifkan TurboBoost).

Singkatnya, saat 1C berjalan, ada banyak waktu tunggu dari perangkat lain (disk, jaringan, dll.). Sambil menunggu respons, jika mode kinerja diaktifkan, prosesor akan menurunkan frekuensinya. Respons datang dari perangkat, 1C (prosesor) perlu bekerja, tetapi siklus clock pertama berada pada frekuensi yang dikurangi, kemudian frekuensinya meningkat - dan 1C kembali menunggu respons dari perangkat. Dan - ratusan kali per detik.

Anda dapat (dan sebaiknya) mengaktifkan mode kinerja di dua tempat:

melalui BIOS. Nonaktifkan mode C1, C1E, Intel C-state (C2, C3, C4). Di bios beda namanya berbeda, tapi artinya sama. Butuh waktu lama untuk mencari, perlu reboot, tetapi jika Anda melakukannya sekali, maka Anda bisa melupakannya. Jika Anda melakukan semuanya dengan benar di BIOS, kecepatannya akan meningkat. Pada beberapa motherboard, Anda dapat mengonfigurasi pengaturan BIOS sehingga mode kinerja Windows tidak berperan. (Contoh Pengaturan BIOS di Gilev). Pengaturan ini terutama menyangkut prosesor server atau BIOS "lanjutan", jika Anda belum menemukannya dan TIDAK memiliki Xeon, tidak apa-apa.

Panel kontrol - Catu daya - Performa tinggi. Minusnya - jika komputer tidak diservis dalam waktu lama, maka akan menimbulkan suara kipas yang lebih keras, lebih panas, dan menghabiskan lebih banyak energi. Ini adalah biaya kinerja.

Cara memeriksa apakah mode tersebut diaktifkan. Luncurkan pengelola tugas - kinerja - monitor sumber daya - CPU. Kami menunggu sampai prosesor tidak sibuk dengan apa pun.

Ini adalah pengaturan default.

Status C BIOS diaktifkan,

mode konsumsi daya seimbang

BIOS C-state diaktifkan, mode kinerja tinggi

Untuk Pentium dan Core Anda bisa berhenti di situ,

Anda masih bisa memeras sedikit "burung beo" dari Xeon

Di BIOS C-state dinonaktifkan, mode kinerja tinggi.

Jika Anda tidak menggunakan Turbo boost, tampilannya akan seperti ini

server disetel untuk kinerja

Dan sekarang angkanya. Izinkan saya mengingatkan Anda: Intel Xeon 5650, ramdisk. Dalam kasus pertama, tes menunjukkan 23,26, yang terakhir - 49,5. Perbedaannya hampir dua kali lipat. Jumlahnya mungkin berbeda, tetapi rasionya pada dasarnya tetap sama untuk Intel Core.

Administrator yang terhormat, Anda dapat mengkritik 1C sebanyak yang Anda suka, tetapi jika pengguna akhir membutuhkan kecepatan, Anda harus mengaktifkan mode kinerja tinggi.

c) Peningkatan Turbo. Pertama, Anda perlu memahami apakah prosesor Anda mendukung fungsi ini, misalnya di sini. Jika mendukung, maka Anda masih bisa mendapatkan sedikit performa. (Saya tidak ingin menyentuh masalah overclocking frekuensi, terutama server, risikonya ditanggung sendiri. Namun saya setuju bahwa meningkatkan kecepatan Bus dari 133 menjadi 166 memberikan peningkatan yang sangat nyata baik dalam kecepatan maupun pembuangan panas)

Cara mengaktifkan turbo boost ditulis misalnya di sini. Tetapi! Ada beberapa nuansa untuk 1C (bukan yang paling jelas). Kesulitannya adalah itu efek maksimal dari turbo boost muncul saat C-state dihidupkan. Dan kami mendapatkan sesuatu seperti ini:

Harap diperhatikan bahwa penggandanya maksimal, kecepatan Core-nya bagus, dan performanya tinggi. Tapi apa yang akan terjadi dengan angka 1?

Namun pada akhirnya ternyata menurut tes performa CPU versi dengan pengali 23 lebih unggul, menurut pengujian Gilev pada versi file performa dengan pengali 22 dan 23 sama, namun di client-server versi - versi dengan pengali 23 sangat buruk, sangat buruk (meskipun kondisi C disetel ke level 7, versi tersebut masih lebih lambat dibandingkan dengan kondisi C yang dimatikan). Oleh karena itu, rekomendasinya adalah memeriksa sendiri kedua opsi tersebut dan memilih yang terbaik. Bagaimanapun, perbedaan antara 49,5 dan 53 burung beo cukup signifikan, terutama tanpa banyak usaha.

Kesimpulan - turbo boost harus dihidupkan. Izinkan saya mengingatkan Anda bahwa mengaktifkan item Turbo boost di BIOS saja tidak cukup, Anda juga perlu melihat pengaturan lainnya (BIOS: QPI L0s, L1 - nonaktifkan, demand scrubbing - nonaktifkan, Intel SpeedStep - aktifkan, Turbo boost - aktifkan Panel Kontrol - Opsi Daya - Kinerja Tinggi) . Dan saya akan tetap (bahkan untuk versi file) memilih opsi di mana c-state dimatikan, meskipun penggandanya lebih kecil. Ini akan menjadi seperti ini...

Hal yang agak kontroversial adalah frekuensi memori. Misalnya, di sini frekuensi memori terbukti mempunyai pengaruh yang sangat kuat. Tes saya tidak menunjukkan ketergantungan seperti itu. Saya tidak akan membandingkan DDR 2/3/4, saya akan menunjukkan hasil perubahan frekuensi dalam satu baris. Memorinya sama, tapi di BIOS kita dipaksa untuk mengatur frekuensi yang lebih rendah.

Dan hasil tes. 1C 8.2.19.83, untuk versi file ramdisk lokal, untuk client-server 1C dan SQL dalam satu komputer, Memori bersama. Turbo boost dinonaktifkan di kedua versi. 8.3 menunjukkan hasil yang sebanding.

Perbedaannya terletak pada kesalahan pengukurannya. Saya secara khusus mengeluarkan tangkapan layar CPU-Z untuk menunjukkan bahwa ketika frekuensi berubah, parameter lain juga berubah, Latensi CAS yang sama dan RAS ke CAS Delay, yang menetralkan perubahan frekuensi. Perbedaannya adalah ketika modul memori diubah secara fisik, dari lebih lambat ke lebih cepat, namun jumlahnya pun tidak terlalu signifikan.

2. Ketika kita telah memilah prosesor dan memori komputer klien, kita beralih ke tempat yang sangat penting berikutnya - jaringan. Banyak buku telah ditulis tentang penyetelan jaringan, ada artikel tentang Infostart (1, 2 dan lain-lain), tetapi di sini saya tidak akan fokus pada topik ini. Sebelum memulai pengujian 1C, pastikan iperf antara dua komputer menunjukkan seluruh bandwidth (untuk kartu 1 Gbit - setidaknya 850 Mbit, atau lebih baik lagi 950-980), dan saran Gilev telah diikuti. Kemudian - tes operasi yang paling sederhana adalah, anehnya, menyalin satu file besar (5-10 gigabyte) melalui jaringan. Tanda tidak langsung dari pengoperasian normal pada jaringan 1 Gbit adalah kecepatan penyalinan rata-rata 100 MB/detik, pengoperasian yang baik - 120 MB/detik. Saya ingin menarik perhatian Anda pada fakta bahwa titik lemah (termasuk) mungkin adalah beban prosesor. Protokol SMB di Linux memiliki paralelisasi yang buruk, dan selama pengoperasian, protokol tersebut dapat dengan mudah “memakan” satu inti prosesor dan tidak mengkonsumsinya lagi.

Dan selanjutnya. Dengan pengaturan default klien jendela bekerja paling baik dengan server windows (atau bahkan workstation windows) dan protokol SMB/CIFS, klien linux (debian, ubuntu belum melihat yang lain) bekerja lebih baik dengan linux dan NFS (juga bekerja dengan SMB, tetapi NFS lebih unggul). Fakta bahwa selama penyalinan linier, server Windows Linux ke NFS disalin ke dalam satu aliran lebih cepat tidak berarti apa-apa. Penyetelan Debian untuk 1C adalah topik untuk artikel terpisah, saya belum siap untuk itu, meskipun saya dapat mengatakan bahwa dalam versi file saya mendapatkan kinerja yang sedikit lebih baik daripada versi Win pada peralatan yang sama, tetapi dengan postgres dengan lebih 50 pengguna Saya masih memiliki semuanya sangat buruk.

Hal terpenting yang diketahui oleh administrator "terbakar", tetapi pemula tidak memperhitungkannya. Ada banyak cara untuk menyetel jalur ke database 1c. Anda dapat melakukan servershare, Anda dapat melakukan 192.168.0.1share, Anda dapat menggunakan net z: 192.168.0.1share (dan dalam beberapa kasus metode ini juga akan berhasil, tetapi tidak selalu) dan kemudian tentukan drive Z. Tampaknya semua jalur ini arahkan ke hal yang sama di tempat yang sama, tetapi untuk 1C hanya ada satu metode yang memberikan kinerja normal dengan cukup andal. Jadi, inilah yang perlu Anda lakukan dengan benar:

DI DALAM garis komando(baik dalam atau sesuai keinginan) - lakukan penggunaan bersih DriveLetter: servershare. Contoh: penggunaan bersih m: serverbases. Saya secara khusus menekankan BUKAN alamat IP, tetapi nama server. Jika nama server tidak terlihat, tambahkan ke dns di server, atau secara lokal di file host. Tapi alamatnya harus berdasarkan nama. Oleh karena itu, dalam perjalanan ke database, akses disk ini (lihat gambar).

Dan sekarang saya akan menunjukkan dengan angka mengapa ini adalah nasihatnya. Data awal: kartu Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. OS Win 2008 R2, Win 7, Debian 8. Driver terbaru, pembaruan diterapkan. Sebelum pengujian, saya memastikan bahwa Iperf memberikan bandwidth penuh (kecuali untuk kartu 10 Gbit, hanya berhasil memeras 7,2 Gbit, nanti saya lihat alasannya, server pengujian belum dikonfigurasi dengan benar). Disknya berbeda, tetapi di mana-mana ada SSD (saya khusus memasukkan satu disk untuk pengujian, tidak dimuat dengan apa pun) atau serangan dari SSD. Kecepatan 100 Mbit diperoleh dengan membatasi pengaturan adaptor Intel 362. Tidak ada perbedaan antara 1 Gbit tembaga Intel 350 dan 1 Gbit optik Intel X520-DA2 (diperoleh dengan membatasi kecepatan adaptor). Performa maksimal, turbo boost dimatikan (hanya untuk perbandingan hasil, turbo boost untuk hasil bagus ditambah sedikit kurang dari 10%, untuk hasil buruk mungkin tidak berpengaruh sama sekali). Versi 1C 8.2.19.86, 8.3.6.2076. Saya tidak memberikan semua angkanya, tetapi hanya yang paling menarik, sehingga Anda memiliki sesuatu untuk dibandingkan.

	Menangkan 2008 - Menangkan 2008 hubungi berdasarkan alamat ip	Menangkan 2008 - Menangkan 2008 Memanggil dengan nama	Menangkan 2008 - Menangkan 2008 Kontak berdasarkan alamat IP	Menangkan 2008 - Menangkan 2008 Memanggil dengan nama	Menangkan 2008 - Menangkan 7 Memanggil dengan nama	Menangkan 2008 - Debian Memanggil dengan nama	Menangkan 2008 - Menangkan 2008 Kontak berdasarkan alamat IP	Menangkan 2008 - Menangkan 2008 Memanggil dengan nama
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1C 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Kesimpulan (dari tabel dan dari pengalaman pribadi. Hanya berlaku untuk versi file):

Melalui jaringan, Anda bisa mendapatkan nomor pekerjaan yang cukup normal jika jaringan ini dikonfigurasi dengan benar dan jalur dimasukkan dengan benar di 1C. Bahkan Core i3 pertama dapat dengan mudah menghasilkan 40+ burung beo, yang cukup bagus, dan ini bukan hanya burung beo, dalam pekerjaan nyata perbedaannya juga terlihat. Tetapi! Batasannya saat bekerja dengan beberapa (lebih dari 10) pengguna bukan lagi jaringan, disini 1 Gbit masih cukup, tapi pemblokiran saat bekerja multi-user (Gilev).
platform 1C 8.3 berkali-kali lebih menuntut dalam hal konfigurasi jaringan yang tepat. Pengaturan dasar - lihat Gilev, namun perlu diingat bahwa segala sesuatu dapat mempengaruhi. Saya melihat percepatan dari mencopot pemasangan (dan tidak hanya mematikan) antivirus, dari menghapus protokol seperti FCoE, dari mengganti driver ke versi yang lebih lama, namun bersertifikasi Microsoft (terutama untuk kartu murah seperti ASUS dan DLC), dari melepas kartu jaringan kedua. dari server. Ada banyak pilihan, atur jaringan Anda dengan hati-hati. Mungkin ada situasi ketika platform 8.2 memberikan angka yang dapat diterima, dan 8.3 - dua kali atau lebih. Coba mainkan dengan platform versi 8.3, terkadang Anda mendapatkan efek yang sangat besar.
1C 8.3.6.2076 (mungkin nanti, saya belum mencari versi pastinya) masih lebih mudah dikonfigurasi melalui jaringan dibandingkan 8.3.7.2008. Saya dapat mencapai operasi normal melalui jaringan mulai 8.3.7.2008 (pada burung beo yang sebanding) hanya beberapa kali; Saya tidak dapat mengulanginya untuk kasus yang lebih umum. Saya tidak mengerti banyak, tetapi dilihat dari penjelasan Process Explorer, rekaman di sana tidak sebagus di 8.3.6.
Terlepas dari kenyataan bahwa ketika bekerja pada jaringan 100 Mbit, jadwal pemuatannya kecil (kita dapat mengatakan bahwa jaringan ini gratis), kecepatan operasinya masih jauh lebih rendah dibandingkan pada 1 Gbit. Alasannya adalah latensi jaringan.
Semua hal lain dianggap sama (jaringan yang berfungsi dengan baik) untuk 1C 8.2 koneksi Intel-Realtek 10% lebih lambat dari Intel-Intel. Namun realtek-realtek umumnya dapat memberikan penurunan permukaan tanah yang tajam secara tiba-tiba. Oleh karena itu, jika Anda punya uang, lebih baik simpan kartu jaringan Intel di mana-mana, jika Anda tidak punya uang, maka instal Intel hanya di server (CO Anda). Dan masih banyak lagi instruksi untuk menyetel kartu jaringan Intel.
Pengaturan antivirus default (menggunakan drweb versi 10 sebagai contoh) memakan waktu sekitar 8-10% dari burung beo. Jika Anda mengkonfigurasinya sebagaimana mestinya (mengizinkan proses 1cv8 melakukan semuanya, meskipun tidak aman), kecepatannya sama seperti tanpa antivirus.
JANGAN membaca guru Linux. Server dengan samba sangat bagus dan gratis, tetapi jika Anda menginstal Win XP atau Win7 (atau bahkan lebih baik - server OS) di server, maka versi file 1c akan bekerja lebih cepat. Ya, samba dan tumpukan protokol serta pengaturan jaringan dan masih banyak lagi dapat disesuaikan dengan baik di debian/ubuntu, tetapi ini direkomendasikan untuk spesialis. Tidak ada gunanya menginstal Linux dengan pengaturan default dan kemudian mengatakan bahwa itu lambat.
Merupakan ide bagus untuk memeriksa pengoperasian disk yang terhubung melalui penggunaan bersih menggunakan fio. Setidaknya akan jelas apakah ini masalah pada platform 1C, atau pada jaringan/disk.
Untuk versi pengguna tunggal, saya tidak dapat memikirkan pengujian (atau situasi) di mana perbedaan antara 1 Gbit dan 10 Gbit akan terlihat. Satu-satunya hal di mana 10Gbit untuk versi file memberikan hasil yang lebih baik adalah menghubungkan disk melalui iSCSI, tetapi ini adalah topik untuk artikel terpisah. Namun, menurut saya untuk versi file, 1 kartu Gbit sudah cukup.
Saya tidak mengerti mengapa, dengan jaringan 100 Mbit, 8.3 bekerja jauh lebih cepat daripada 8.2, tapi itu faktanya. Semua peralatan lainnya, semua pengaturan lainnya persis sama, hanya saja dalam satu kasus 8.2 diuji, dan di kasus lain - 8.3.
NFS win-win atau win-lin yang tidak disetel memberikan 6 burung beo, saya tidak memasukkannya ke dalam tabel. Setelah tuning saya mendapat 25, tetapi tidak stabil (perbedaan pengukuran lebih dari 2 unit). Saya belum bisa memberikan rekomendasi penggunaan Windows dan protokol NFS.

Setelah semua pengaturan dan pemeriksaan, kami menjalankan pengujian lagi dari komputer klien dan bersukacita atas hasil yang ditingkatkan (jika berhasil). Jika hasilnya membaik, ada lebih dari 30 burung beo (dan terutama lebih dari 40), kurang dari 10 pengguna yang bekerja pada saat yang sama, dan database yang berfungsi masih lambat - hampir pasti ada masalah dengan pemrogram (atau Anda punya sudah mencapai kemampuan puncak versi file).

Server terminal. (database ada di server, klien terhubung melalui jaringan, protokol RDP). Algoritma langkah demi langkah:

Kami menambahkan database pengujian Gilev ke server di folder yang sama dengan database utama. Kami terhubung dari server yang sama dan menjalankan pengujian. Kami ingat hasilnya.
Dengan cara yang persis sama seperti pada versi file, kami mengkonfigurasi prosesor. Dalam kasus server terminal, prosesor umumnya memainkan peran utama (diasumsikan tidak ada peran eksplisit titik lemah, seperti kekurangan memori atau banyaknya perangkat lunak yang tidak diperlukan).
Mengonfigurasi kartu jaringan dalam kasus server terminal hampir tidak berpengaruh pada pengoperasian 1c. Untuk memastikan kenyamanan “khusus”, jika server Anda menghasilkan lebih dari 50 burung beo, Anda dapat bermain dengan protokol RDP versi baru, hanya untuk kenyamanan pengguna, respons dan pengguliran yang lebih cepat.
Ketika sejumlah besar pengguna aktif bekerja (dan di sini Anda sudah dapat mencoba menghubungkan 30 orang ke satu database, jika Anda mencobanya), sangat disarankan untuk memasang drive SSD. Untuk beberapa alasan, diyakini bahwa disk tidak terlalu mempengaruhi pengoperasian 1C, tetapi semua pengujian dilakukan dengan cache pengontrol diaktifkan untuk menulis, dan ini tidak benar. Basis pengujiannya kecil, cukup cocok dengan cache, sehingga jumlahnya tinggi. Pada database nyata (besar), semuanya akan sangat berbeda, sehingga cache dinonaktifkan untuk pengujian.

Misalnya, saya memeriksa pengoperasian tes Gilev dengan opsi disk yang berbeda. Saya memasang disk dari apa yang ada, hanya untuk menunjukkan kecenderungannya. Perbedaan antara 8.3.6.2076 dan 8.3.7.2008 kecil (pada Ramdisk Turbo boost versi 8.3.6 menghasilkan 56.18 dan 8.3.7.2008 menghasilkan 55.56, pada pengujian lain perbedaannya bahkan lebih kecil). Konsumsi daya - performa maksimal, turbo boost dinonaktifkan (kecuali dinyatakan lain).

	Serangan 10 4x SATA 7200 ATA ST31500341AS	Serangan 10 4x SAS 10k	Serangan 10 4x SAS 15k	SSD tunggal	Ramdisk		Tembolok diaktifkan Pengontrol RAID
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1C 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Cache pengontrol RAID yang diaktifkan menghilangkan semua perbedaan antara disk; jumlahnya sama untuk sat dan cas. Mengujinya pada sejumlah kecil data tidak ada gunanya dan tidak menunjukkan apa pun.
Untuk platform 8.2, perbedaan performa antara opsi SATA dan SSD lebih dari dua kali lipat. Ini bukan salah ketik. Jika Anda melihat monitor kinerja selama pengujian pada drive SATA. maka Anda dapat dengan jelas melihat “Waktu pengoperasian disk aktif (dalam%)” 80-95. Ya, jika Anda mengaktifkan cache dari disk itu sendiri untuk merekam, kecepatannya akan meningkat menjadi 35, jika Anda mengaktifkan cache dari pengontrol serangan - hingga 49 (terlepas dari disk mana yang sedang diuji saat ini). Tapi ini adalah cache sintetis; dalam pekerjaan nyata, dengan database besar, tidak akan pernah ada rasio hit cache tulis 100%.
Kecepatan SSD murah sekalipun (saya uji pada Agility 3) cukup untuk menjalankan versi file. Sumber daya perekaman adalah masalah lain, Anda perlu melihatnya dalam setiap kasus tertentu, jelas bahwa Intel 3700 akan memiliki urutan yang lebih tinggi, tetapi harganya sesuai. Dan ya, saya memahami bahwa ketika menguji disk SSD, saya juga menguji cache disk ini lebih jauh, hasil sebenarnya akan lebih sedikit.
Solusi yang paling benar (dari sudut pandang saya) adalah dengan mengalokasikan 2 disk SSD dalam serangan cermin untuk database file (atau beberapa database file), dan tidak menempatkan apa pun di sana. Ya, dengan cermin, SSD juga mengalami keausan yang sama, dan ini merupakan kerugian, tetapi setidaknya elektronik pengontrol terlindungi dari kesalahan.
Keunggulan utama drive SSD untuk versi file akan muncul ketika terdapat banyak database yang masing-masing memiliki beberapa pengguna. Jika ada 1-2 database, dan ada sekitar 10 pengguna, maka disk SAS sudah cukup. (tetapi bagaimanapun juga, lihat memuat disk ini, setidaknya melalui perfmon).
Keuntungan utama dari server terminal adalah ia dapat memiliki klien yang sangat lemah, dan pengaturan jaringan tidak terlalu mempengaruhi server terminal (sekali lagi, K.O. Anda).

Kesimpulan: jika Anda menjalankan tes Gilev di server terminal (dari disk yang sama tempat database yang berfungsi berada) dan pada saat database yang berfungsi melambat, dan tes Gilev menunjukkan hasil yang baik (di atas 30), maka lambatnya pengoperasian database kerja utama kemungkinan besar disebabkan oleh programmer.

Jika tes Gilev menunjukkan angka kecil, dan Anda memiliki prosesor dengan jam tinggi dan disk cepat, maka administrator perlu mengambil setidaknya perfmon, mencatat semua hasilnya di suatu tempat, dan mengamati, mengamati, dan menarik kesimpulan. Tidak akan ada saran yang pasti.

Opsi klien-server.

Pengujian hanya dilakukan pada 8.2, karena pada 8.3 semuanya sangat bergantung pada versinya.

Untuk pengujian, saya memilih opsi server dan jaringan yang berbeda di antara keduanya untuk menunjukkan tren utama.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Saluran serat - SSD	SQL: Xeon E5-2630 Saluran serat - SAS	SQL: Xeon E5-2630 SSD lokal	SQL: Xeon E5-2630 Saluran serat - SSD	SQL: Xeon E5-2630 SSD lokal	1C: Xeon 5650 =	1C: Xeon 5650 = Berbagi memori	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1C 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Sepertinya itu saja pilihan menarik Saya sudah memeriksanya, jika ada hal lain yang Anda minati, tulis di komentar, saya akan mencoba melakukannya.

SAS pada sistem penyimpanan bekerja lebih lambat dibandingkan SSD lokal, meskipun sistem penyimpanannya memilikinya ukuran besar cache. SSD, baik lokal maupun pada sistem penyimpanan, bekerja pada kecepatan yang sebanding untuk pengujian Gilev. Saya tidak tahu tes multi-thread standar apa pun (tidak hanya rekaman, tetapi semua peralatan) kecuali tes beban 1C dari MCC.
Mengubah server 1C dari 5520 menjadi 5650 meningkatkan kinerja hampir dua kali lipat. Ya, konfigurasi server tidak sepenuhnya cocok, tetapi menunjukkan tren (tidak mengherankan).
Peningkatan frekuensi pada SQL server tentu memberikan efek, namun tidak sama dengan pada server 1C; MS SQL server sangat baik (jika diminta) untuk menggunakan multi-core dan mengosongkan memori.
Mengubah jaringan antara 1C dan SQL dari 1 Gbit menjadi 10 Gbit menghasilkan sekitar 10% burung beo. Saya mengharapkan lebih banyak.
Mengaktifkan Shared memory tetap memberikan efek meski tidak 15% seperti yang dijelaskan pada artikel. Pastikan untuk melakukannya, untungnya cepat dan mudah. Jika seseorang memberi server SQL sebuah contoh bernama, maka agar 1C berfungsi, nama server harus ditentukan bukan oleh FQDN (tcp/ip akan berfungsi), bukan melalui localhost atau hanya ServerName, tetapi melalui ServerNameInstanceName, misalnya zz-testzztest. (Jika tidak, akan ada kesalahan DBMS: Microsoft SQL Server Native Client 10.0: Penyedia Memori Bersama: Pustaka memori bersama yang digunakan untuk membuat sambungan dengan SQL Server 2000 tidak ditemukan. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE=08001, status=1, Tingkat Keparahan=10, asli=126, baris=0).
Untuk pengguna kurang dari 100, satu-satunya poin untuk membaginya menjadi dua server terpisah adalah lisensi Win 2008 Std (dan lebih lama), yang hanya mendukung RAM 32GB. Dalam semua kasus lainnya, 1C dan SQL pasti perlu diinstal pada server yang sama dan diberikan lebih banyak memori (setidaknya 64 GB). Memberi MS SQL RAM kurang dari 24-28 GB adalah keserakahan yang tidak dapat dibenarkan (jika Anda berpikir Anda memiliki cukup memori untuk itu dan semuanya berfungsi dengan baik, mungkin versi file 1C akan cukup untuk Anda?)
Seberapa buruk kombinasi 1C dan SQL bekerja di mesin virtual adalah topik artikel terpisah (petunjuk - terasa lebih buruk). Bahkan di Hyper-V semuanya tidak begitu jelas...
Mode kinerja seimbang buruk. Hasilnya cukup sesuai dengan versi file.
Banyak sumber yang mengatakan bahwa mode debugging (ragent.exe -debug) menyebabkan penurunan kinerja yang signifikan. Ya, memang berkurang, tapi saya tidak akan menyebut 2-3% sebagai efek yang signifikan.

Saran yang ada di sini paling sedikit untuk kasus tertentu, karena... Rem dalam versi kerja klien-server adalah kasus yang paling sulit, dan semuanya dikonfigurasi secara individual. Cara termudah adalah dengan mengatakan bahwa untuk operasi normal Anda perlu mengambil server terpisah HANYA untuk 1C dan MS SQL, letakkan prosesor di sana dengan frekuensi maksimum (di atas 3 GHz), drive SSD untuk pangkalan, dan lebih banyak memori(128+), jangan gunakan virtualisasi. Ini membantu - bagus, Anda beruntung (dan akan ada banyak orang yang beruntung, lebih dari separuh masalah dapat diselesaikan dengan peningkatan yang memadai). Jika tidak, maka opsi lain memerlukan pertimbangan dan pengaturan terpisah.

Tampilan