Eğe tabanındaki frenler - nasıl önlenir (en son deneyimlerden). 1c'yi otomatikleştirmek için ipuçları ağ üzerinden yavaş çalışır

1C'niz yine yavaşlıyor mu?Rapor yazarken zaman mı harcıyorsunuz?Veri alışverişini beklerken çay içmekten bıktınız mı?

1C'nin yavaş çalışmasıyla ilgili durum nadir değildir. Buna katlanabilir veya işinizin hızını önemli ölçüde artıracak 1C ve ekipman ayarlarını optimize edebilirsiniz.

Hizmetlerimiz iş gününüzde daha fazlasını yapmanıza yardımcı olacak! "1C donuyor" kelimesini asla tekrarlamamanız için 1C'yi nasıl hızlandıracağımızı biliyoruz.

"1C" neden donabilir veya yavaşlayabilir?

Sorun donanımda olabilir. 1C'li sunucuda bellek eksikliği, yerel ağda dengesiz çalışma, sabit sürücü veya güvenlik anahtarlarıyla ilgili sorunlar - tüm bunlar 1C'yi yavaşlatabilir ve sizi gerginleştirebilir. Ek olarak, 1C aşağıdakilerden dolayı takılabilir:

zayıf platform ve yapılandırma uyumluluğu,
acemi 1C programcılarının hataları,
büyük taban,
çok sayıda kullanıcı.

1C ile normal işlemler sırasında yapılan hatalar bile yavaş çalışmasına neden olabilir.

1C nasıl hızlandırılır?

Şu şekilde çalışıyoruz:

Ekipmanı teknolojik gereksinimler 1C'ye uygunluk açısından kontrol ediyoruz. Belki de RAM'i artırmanız, 1C sunucusunu yapılandırmanız, diski değiştirmeniz veya yerel ağın hızını kontrol etmeniz gerekiyor. Başka bir deyişle, sürece dahil olan tüm ekipmanları kapsamlı bir şekilde kontrol ediyoruz.
1C'nin çalışmasına dahil olan diğer hizmetlerin ayarlarını kontrol ediyoruz. Örneğin, yanlış yapılandırılmış SQL veritabanı veya güvenilir olmayan terminal erişimi, 1C'yi büyük ölçüde yavaşlatabilir.
Çalışırken sorun olan 1C yapılandırma kodunun doğruluğunu kontrol ediyoruz. Aynı yazılım sorununun farklı şekillerde çözülebileceği bir sır değil. Uygun olmayan kod genellikle 1C'nin donmasına neden olur.
1C ile çalışırken kullanıcıların çalışma düzenini kontrol ediyoruz. Bazen kullanıcıların kendileri 1C'yi yavaşlatır ve bunun farkında olmazlar ..

“1C yavaşlar” ifadesi, 1C:Enterprise platformunda ürünlerle çalışan herkes tarafından duyulmuş olmalıdır. Birisi bundan şikayet etti, biri şikayetleri kabul etti. Bu yazıda, bu sorunun en yaygın nedenlerini ve çözme seçeneklerini ele almaya çalışacağız.

Metafora dönelim: Bir kişinin neden bir yere gitmediğini bulmadan önce, yürüyecek bacakları olduğundan emin olmaya değer. Öyleyse, donanım ve ağ gereksinimleriyle başlayalım.

Windows 7 yüklüyse:

Windows 8 veya 10 yüklüyse:

Ayrıca, en az 2 GB boş disk alanı olması gerektiğini ve bir ağ bağlantısının en az 100 Mb / s hıza sahip olması gerektiğini unutmayın.

İstemci-sunucu sürümündeki sunucuların özelliklerini dikkate almak pek mantıklı değil, çünkü bu durumda her şey kullanıcı sayısına ve 1C'de çözdükleri görevlerin özelliklerine bağlıdır.

Bir sunucu için yapılandırma seçerken aşağıdakileri aklınızda bulundurun:

1C sunucusunun bir çalışan işlemi ortalama 4 GB tüketir (kullanıcı bağlantısıyla karıştırılmamalıdır, çünkü bir çalışan işlemin sunucu ayarlarında belirttiğiniz kadar çok bağlantısı olabilir);
1C ve DBMS'nin (özellikle MS SQL) aynı fiziksel sunucu üzerinde kullanılması, büyük veri dizilerini işlerken (örneğin, bir ayı kapatma, bir modele göre bütçe hesaplama vb.) kazanç sağlar, ancak sırasında performansı önemli ölçüde azaltır. boşaltılan işlemler (örneğin, uygulama belgesinin oluşturulması ve yürütülmesi vb.);
1C sunucularının ve DBMS'nin 1 GB'tan "kalın" bir kanal üzerinden bağlanması gerektiğini unutmayın;
Yüksek performanslı diskler kullanın ve 1C sunucusu ve DBMS rollerini diğer rollerle (örneğin, dosya, AD, etki alanı denetleyicisi vb.) birleştirmeyin.

Ekipmanı kontrol ettikten sonra 1C hala "yavaşlıyorsa"

Küçük bir şirketimiz var, 7 kişi ve 1C "yavaşlıyor". Uzmanlara döndük ve bizi yalnızca istemci-sunucu seçeneğinin kurtaracağını söylediler. Ama bizim için böyle bir çözüm kabul edilemez, çok pahalı!

Veritabanında rutin bakım gerçekleştirin*:

1. Veritabanını yapılandırıcı modunda başlatın.

2. Ana menüde "Yönetim" öğesini ve içinde - "Test etme ve düzeltme" öğesini seçin.

3. Resimdeki gibi tüm onay kutularını ayarlayın. Çalıştıra tıkla.

*Bu prosedür, tabanın boyutuna ve PC'nizin özelliklerine bağlı olarak 15 dakika ile bir saat arasında sürebilir.

Bu yardımcı olmazsa, bir istemci-sunucu bağlantısı kurarız, ancak donanım ve yazılıma ek yatırımlar yapmadan:

1. Ofisteki en az yüklü bilgisayarı sabit (dizüstü bilgisayar değil) arasından seçin: en az 4 GB RAM'e ve en az 100 Mb / s ağ bağlantısına sahip olmalıdır.

2. Üzerinde IIS'yi (İnternet Bilgi Sunucusu) etkinleştirin. Bunun için:

3. Veritabanınızı bu bilgisayarda yayınlayın. ITS'de bu konuyla ilgili mevcut materyal var veya bir destek uzmanıyla iletişime geçin.

4. Kullanıcı bilgisayarlarında, hafif istemci aracılığıyla veritabanına erişimi yapılandırın. Bunun için:

Başlatma penceresini açın 1C.

Çalışma tabanınızı seçin. Burası senin üssün. Düzenle'yi tıklayın. Anahtarı "Web sunucusunda" konumuna getirin, altındaki satırda IIS'nin etkinleştirildiği sunucunun adını veya IP adresini ve veritabanının yayınlandığı adı belirtin. Sonrakine tıkla".

"Ana Başlangıç Modu" anahtarını "İnce İstemci" moduna ayarlayın. "Bitir"i tıklayın.

Oldukça büyük bir şirketimiz var ama çok büyük değil, 50-60 kişi İstemci-sunucu seçeneğini kullanıyoruz ama 1C çok yavaş.

Bu durumda, 1C sunucusunu ve DBMS sunucusunu iki farklı sunucuya ayırmanız önerilir. Ayırırken, şunu hatırladığınızdan emin olun: basitçe sanallaştırılmış olan aynı fiziksel sunucuda kaldılarsa, bu sunucuların diskleri farklı olmalıdır - fiziksel olarak farklı! Ayrıca, MS SQL söz konusu olduğunda DBMS sunucusunda zamanlanmış görevler kurduğunuzdan emin olun (bununla ilgili daha fazla bilgi ITS web sitesinde açıklanmıştır)

100'den fazla kullanıcısı olan oldukça büyük bir şirketimiz var. Bu seçenek için her şey 1C'nin önerilerine göre ayarlanmıştır, ancak bazı belgeleri yürütürken 1C çok "yavaşlar" ve bazen bir engelleme hatası oluşur. Belki üssün bir kıvrımını yapmak?

Benzer bir durum, çok özel bir birikim kaydının veya muhasebenin boyutundan (ancak daha sıklıkla - birikim), kaydın ya hiç "kapalı" olmamasından, yani. gelir hareketleri var ama harcama hareketleri yok veya defter bakiyelerinin hesaplandığı ölçü sayısı çok fazla. Hatta önceki iki nedenin bir karışımı bile olabilir. Hangi kaydın her şeyi bozduğu nasıl belirlenir?

Dokümanların yavaş işlendiği zamanı veya engelleme hatası olan zamanı ve kullanıcıyı düzeltiriz.

Kayıt günlüğünü açın.

“Data.Conduct” olay türü ile doğru kullanıcı için, doğru zamanda, ihtiyacımız olan belgeyi buluyoruz.

İşlemin iptal edildiği ana kadar tüm işlem bloğuna bakarız, bir engelleme hatası varsa veya en uzun değişikliği ararız (önceki kayıttan itibaren geçen süre bir dakikadan fazladır).

Bundan sonra, her durumda bu özel kaydı daraltmanın tüm veritabanından daha ucuz olduğunu akılda tutarak bir karar veriyoruz.

Biz çok büyük bir şirketiz, 1000'den fazla kullanıcı, günde binlerce belge, kendi BT departmanımız, devasa bir sunucu filomuz, istekleri birkaç kez optimize ettik, ancak 1C yavaşlıyor. Görünüşe göre 1C'yi aştık ve daha güçlü bir şeye ihtiyacımız var.

Bu tür vakaların büyük çoğunluğunda "yavaşlayan" 1C değil, kullanılan çözümün mimarisidir. Yeni bir iş programı lehine bir seçim yaparken, iş süreçlerinizi bir programa yazmanın, bazıları için, özellikle de çok pahalı bir program için yeniden yapmaktan daha ucuz ve daha kolay olduğunu unutmayın. Sadece 1C böyle bir fırsat sağlar. Bu nedenle, kendinize şunu sormak daha iyidir: “Durum nasıl düzeltilir? 1C'nin bu tür hacimlerde "uçması" nasıl sağlanır? Birkaç tedavi seçeneğine bir göz atalım:

1C'nin desteklediği paralel ve eşzamansız programlama teknolojilerini kullanın (bir döngüdeki arka plan görevleri ve istekleri).
Çözümün mimarisini tasarlarken, birikim kayıtlarını ve muhasebe kayıtlarını en "dar" yerlerde kullanmayı reddedin.
Bir veri yapısı (birikim ve / veya bilgi kayıtları) geliştirirken şu kuralı izleyin: "Yazılması ve okunması en hızlı tablo, tek sütunlu tablodur." Tipik bir RAUS mekanizmasına bakarsak neyin tehlikede olduğu daha net hale gelecektir.
Büyük miktarda veriyi işlemek için, aynı veritabanının bağlı olduğu yardımcı kümeler kullanın (ancak bu, etkileşimli çalışırken hiçbir durumda yapılmamalıdır !!!). Bu, standart 1C kilitlerini atlayacak ve bu da veritabanıyla doğrudan SQL araçlarıyla çalışırken olduğu gibi neredeyse aynı hızda çalışmayı mümkün kılacaktır.

Holdingler ve büyük şirketler için 1C optimizasyonunun ayrı, büyük bir makalenin konusu olduğunu belirtmekte fayda var, bu nedenle web sitemizdeki materyallerin güncellemeleri için bizi izlemeye devam edin.

Son zamanlarda, kullanıcılar ve yöneticiler, yönetilen bir uygulama temelinde geliştirilen yeni 1C yapılandırmalarının yavaş, bazı durumlarda kabul edilemez derecede yavaş olduğundan giderek daha fazla şikayet etmeye başladılar. Yeni yapılandırmaların yeni işlevler ve yetenekler içerdiği ve bu nedenle kaynaklar üzerinde daha fazla talepte bulunduğu açıktır, ancak çoğu kullanıcı, 1C'nin dosya modunda çalışmasını neyin etkilediğine dair bir anlayışa sahip değildir. Bu açığı gidermeye çalışalım.

Bizimkinde, disk alt sisteminin performansının 1C hızı üzerindeki etkisine zaten değindik, ancak bu çalışma, uygulamanın ayrı bir PC veya terminal sunucusunda yerel kullanımıyla ilgiliydi. Aynı zamanda, çoğu küçük uygulama, kullanıcının kişisel bilgisayarlarından birinin sunucu olarak kullanıldığı bir ağ üzerinden bir dosya tabanıyla veya normal, çoğu kez de ucuz bir bilgisayara dayalı özel bir dosya sunucusuyla çalışmayı içerir.

1C'deki Rusça kaynaklarla ilgili küçük bir çalışma, bu sorunun özenle atlandığını gösterdi, sorun olması durumunda, genellikle istemci-sunucu veya terminal moduna geçmeniz önerilir. Ayrıca, yönetilen bir uygulamadaki yapılandırmaların normal yapılandırmalardan çok daha yavaş çalıştığı da neredeyse genel kabul görmüştür. Kural olarak, argümanlar "demir" olarak verilir: "burada Muhasebe 2.0 yeni uçtu ve" troyka "zar zor hareket ediyor, elbette, bu sözlerde bazı gerçekler var, o yüzden anlamaya çalışalım.

Bir bakışta kaynak tüketimi

Bu çalışmaya başlamadan önce kendimize iki hedef belirledik: yönetilen uygulama tabanlı yapılandırmaların aslında geleneksel yapılandırmalardan daha yavaş olup olmadığını ve hangi kaynakların performans üzerinde en yüksek etkiye sahip olduğunu bulmak.

Test için, sırasıyla Windows Server 2012 R2 ve Windows 8.1 çalıştıran, 2 çekirdekli ana bilgisayar Core i5-4670 ve ortalama bir ofis makinesine karşılık gelen 2 GB RAM'e sahip iki sanal makine aldık. Sunucu, iki kişilik bir RAID 0 dizisine yerleştirildi ve istemci benzer bir genel amaçlı disk dizisine yerleştirildi.

Deneysel temeller olarak, Accounting 2.0'ın birkaç yapılandırmasını seçtik, sürüm 2.0.64.12 , daha sonra şu şekilde güncellendi: 3.0.38.52 , tüm yapılandırmalar platformda çalıştırıldı 8.3.5.1443 .

Dikkat çeken ilk şey, Troyka'nın bilgi tabanının boyutunun artması ve önemli ölçüde artması ve RAM'e olan iştahın çok daha fazla artması:

Her zamanki gibi duymaya hazırız: "Bu üçlüye ne kattılar", ama acele etmeyelim. Az ya da çok kalifiye bir yönetici gerektiren istemci-sunucu sürümleri kullanıcılarının aksine, dosya sürümleri kullanıcıları nadiren veritabanı bakımını düşünürler. Ayrıca, bu üslere hizmet veren (okuma - güncelleme) uzman firmaların çalışanları bunu nadiren düşünür.

Bu arada, 1C bilgi tabanı, aynı zamanda bakım gerektiren, kendi formatında tam teşekküllü bir DBMS'dir ve bunun için adı verilen bir araç bile vardır. Bilgi bankasını test etme ve düzeltme. Belki de isim, bunun bir sorun giderme aracı olduğunu ima ediyor gibi görünen acımasız bir şaka yaptı, ancak düşük performans da bir sorundur ve tablo sıkıştırmanın yanı sıra yeniden yapılandırma ve yeniden dizin oluşturma, herhangi bir RDBMS yöneticisi için iyi bilinen veritabanı optimizasyon araçlarıdır. Hadi kontrol edelim?

Seçilen eylemleri uyguladıktan sonra, veritabanı önemli ölçüde "ağırlık kaybetti", kimsenin optimize etmediği "iki" den bile daha küçük hale geldi ve RAM tüketimi de biraz azaldı.

Akabinde, yeni sınıflandırıcılar ve dizinler yüklendikten, indeksler oluşturulduktan sonra vb. tabanın boyutu büyüyecek, genel olarak "üç" ün tabanları "iki" nin tabanlarından daha büyüktür. Ancak bu daha önemli değil, ikinci sürüm 150-200 MB RAM ile içerikliyse, yeni sürüm zaten yarım gigabayta ihtiyaç duyuyor ve programla çalışmak için gerekli kaynakları planlarken bu değer dikkate alınmalıdır. .

Açık

Ağ bant genişliği, özellikle dosya modunda 1C olarak ağ uygulamaları için en önemli parametrelerden biridir ve ağ üzerinde önemli miktarda veri taşır. Çoğu küçük işletme ağı, ucuz 100 Mbps ekipman temelinde kurulur, bu nedenle 1C'nin 100 Mbps ve 1 Gbps ağlardaki performans göstergelerini karşılaştırarak test etmeye başladık.

1C dosya tabanını ağ üzerinden başlattığınızda ne olur? İstemci, özellikle bu ilk "soğuk" başlatma ise, oldukça büyük miktarda bilgiyi geçici klasörlere indirir. 100 Mbps'de, bant genişliğini aşmamız bekleniyor ve indirme işlemi önemli miktarda zaman alabilir, bizim durumumuzda yaklaşık 40 saniye (grafik bölümünün fiyatı 4 saniyedir).

İkinci başlatma daha hızlıdır, çünkü verilerin bir kısmı önbellekte depolanır ve yeniden başlatılana kadar orada kalır. Bir gigabit ağa geçiş, programın hem "soğuk" hem de "sıcak" olarak yüklenmesini önemli ölçüde hızlandırabilir ve değerlerin oranı gözlenir. Bu nedenle, her ölçümün en büyük değerini %100 olarak alarak sonucu göreli terimlerle ifade etmeye karar verdik:

Grafiklerden de görebileceğiniz gibi Accounting 2.0 herhangi bir ağ hızında iki kat daha hızlı yükleniyor, 100 Mbps'den 1 Gbps'ye geçiş, indirme süresini dört kat hızlandırmanızı sağlıyor. Bu modda optimize edilmiş ve optimize edilmemiş Troika veritabanları arasında fark yoktur.

Ağ hızının, örneğin yeniden grup barındırma sırasında olduğu gibi ağır hizmet operasyonları üzerindeki etkisini de kontrol ettik. Sonuç ayrıca göreli terimlerle ifade edilir:

Burada zaten daha ilginç, 100 Mbit / s ağdaki optimize edilmiş "troyka" tabanı "iki" ile aynı hızda çalışıyor ve optimize edilmemiş olan, iki kat daha kötü sonuç gösteriyor. Bir gigabitte oranlar korunur, optimize edilmemiş "üç" de "iki" den iki kat daha yavaştır ve optimize edilmiş olan üçte bir oranında geride kalır. Ayrıca, 1 Gb / sn'ye geçiş, yürütme süresini sürüm 2.0 için üç kat ve sürüm 3.0 için iki kat azaltmanıza olanak tanır.

Ağ hızının günlük iş üzerindeki etkisini değerlendirmek için kullandık. performans ölçümü her veritabanında bir dizi önceden tanımlanmış eylem gerçekleştirerek.

Aslında, günlük görevler için ağ bant genişliği bir darboğaz değildir, optimize edilmemiş bir "üç", ikiden yalnızca% 20 daha yavaştır ve optimizasyondan sonra yaklaşık olarak aynı derecede daha hızlı olduğu ortaya çıkar - ince istemci modunda çalışmanın avantajları etkilenir. 1 Gb / s'ye geçiş, optimize edilmiş tabana herhangi bir avantaj sağlamaz ve optimize edilmemiş taban ve ikili, aralarında küçük bir fark göstererek daha hızlı çalışmaya başlar.

Yapılan testlerden, ağın yeni yapılandırmalar için bir darboğaz olmadığı ve yönetilen uygulamanın normalden daha hızlı çalıştığı ortaya çıkıyor. Ağır görevler ve veritabanı yükleme hızı sizin için kritikse 1 Gb/sn'ye geçmeyi de önerebilirsiniz, diğer durumlarda yeni yapılandırmalar yavaş 100 Mb/sn ağlarda bile verimli çalışmanıza olanak tanır.

Peki 1C neden yavaşlıyor? Daha fazla araştıracağız.

Sunucu disk alt sistemi ve SSD

Bir önceki yazımızda veritabanlarını SSD üzerine yerleştirerek 1C performansında artış elde etmiştik. Sunucu disk alt sisteminin performansı yeterli olmayabilir mi? Aynı anda iki veritabanında çalışan bir grup sırasında bir disk sunucusunun performansını ölçtük ve oldukça iyimser bir sonuç aldık.

Saniyede nispeten yüksek giriş / çıkış işlemi sayısı (IOPS) - 913'e rağmen, sıra uzunluğu 1,84'ü geçmedi, bu iki diskli bir dizi için çok iyi bir sonuç. Buna dayanarak, ağır modlarda 8-10 ağ istemcisinin normal çalışması için sıradan disklerden bir aynanın yeterli olacağı varsayımını yapabiliriz.

Peki bir sunucuda bir SSD gerekli mi? Bu sorunun en iyi cevabı, benzer bir metodoloji kullanarak yaptığımız teste yardımcı olacaktır, ağ bağlantısı her yerde 1 Gb / s'dir, sonuç da göreceli değerlerle ifade edilir.

Veritabanı yükleme hızı ile başlayalım.

Birisine şaşırtıcı gelebilir, ancak sunucudaki SSD tabanı, veritabanının indirme hızını etkilemez. Önceki testte gösterildiği gibi, buradaki ana sınırlayıcı faktör, ağ verimi ve istemci performansıdır.

Yeniden kablolamaya geçelim:

Yukarıda, disk performansının ağır işler için bile oldukça yeterli olduğunu zaten belirtmiştik, bu nedenle SSD'de optimize edilmiş olanı yakalayan optimize edilmemiş taban dışında SSD'nin hızı da etkilenmez. Aslında bu, optimizasyon işlemlerinin veritabanındaki bilgileri düzenlediğini, rastgele G/Ç işlemlerinin sayısını azalttığını ve bunlara erişim hızını artırdığını bir kez daha doğruluyor.

Günlük görevlerde resim benzer:

SSD'den yalnızca optimize edilmemiş taban yararlanır. Elbette bir SSD satın alabilirsiniz, ancak üslerin zamanında bakımını düşünmek çok daha iyi olacaktır. Ayrıca, sunucudaki bilgi tabanı bölümünü birleştirmeyi de unutmayın.

İstemci disk alt sistemi ve SSD

Yerel olarak kurulan 1C'nin hızı üzerinde SSD'nin etkisini analiz ettik , söylenenlerin çoğu ağ modunda çalışmak için de geçerlidir. Gerçekten de, 1C, arka plan ve zamanlanmış görevler dahil olmak üzere disk kaynaklarını oldukça aktif bir şekilde kullanır. Aşağıdaki şekilde, Accounting 3.0'ın yüklemeden sonra yaklaşık 40 saniye boyunca diske nasıl oldukça aktif bir şekilde eriştiğini görebilirsiniz.

Ancak aynı zamanda, bir veya iki bilgi tabanıyla aktif çalışmanın gerçekleştirildiği bir iş istasyonu için, geleneksel bir toplu seri HDD'nin performans kaynaklarının oldukça yeterli olduğu bilinmelidir. Bir SSD satın almak bazı işlemleri hızlandırabilir, ancak örneğin indirme işlemi ağ bant genişliği ile sınırlı olacağından günlük işlerde radikal bir hızlanma fark etmeyeceksiniz.

Yavaş bir sabit sürücü bazı işlemleri yavaşlatabilir, ancak tek başına bir programın yavaşlamasına neden olamaz.

Veri deposu

RAM'in artık aşırı derecede ucuz olmasına rağmen, birçok iş istasyonu satın alındıklarında takılı olan bellek miktarıyla çalışmaya devam ediyor. İlk sorunların pusuda yattığı yer burasıdır. Ortalama bir "troyka" nın yaklaşık 500 MB bellek gerektirdiği gerçeğine dayanarak, programla çalışmak için toplam 1 GB RAM miktarının yeterli olmayacağını varsayabiliriz.

Sistem belleğini 1 GB'a indirdik ve iki bilgi bankası başlattık.

İlk bakışta her şey o kadar da kötü değil, program iştahını azalttı ve tamamen mevcut hafıza içinde tuttu ama unutmayalım ki operasyonel verilere olan ihtiyaç değişmedi, peki nereye gittiler? Diske, önbelleğe, takasa vb. aktarılan bu işlemin özü, o anda ihtiyaç duyulmayan verilerin miktarı yeterli olmayan hızlı RAM'den yavaş diske gönderilmesidir.

Nereye götürüyor? Ağır operasyonlarda sistem kaynaklarının nasıl kullanıldığına bir bakalım, örneğin aynı anda iki veritabanında grup rerun'u başlatalım. İlk olarak 2 GB RAM'e sahip bir sistemde:

Gördüğünüz gibi, sistem verileri almak için ağı ve bunları işlemek için işlemciyi aktif olarak kullanır, disk etkinliği önemsizdir, işleme sürecinde ara sıra büyür, ancak sınırlayıcı bir faktör değildir.

Şimdi belleği 1 GB'a düşürelim:

Durum kökten değişiyor, ana yük artık sabit diske düşüyor, işlemci ve ağ boşta, sistemin gerekli verileri diskten belleğe okumasını ve gereksiz verileri oraya göndermesini bekliyor.

Aynı zamanda, 1 GB belleğe sahip bir sistemde iki açık veritabanıyla yapılan öznel çalışmanın bile son derece rahatsız olduğu ortaya çıktı, dizinler ve dergiler önemli bir gecikme ve aktif disk erişimi ile açıldı. Örneğin, Sales of mal ve hizmet dergisinin açılması yaklaşık 20 saniye sürdü ve tüm bu süre boyunca yüksek disk etkinliği eşlik etti (kırmızı çizgiyle vurgulanmıştır).

RAM'in yönetilen bir uygulamaya dayalı yapılandırmaların performansı üzerindeki etkisini objektif olarak değerlendirmek için üç ölçüm gerçekleştirdik: birinci tabanın yükleme hızı, ikinci tabanın yükleme hızı ve tabanlardan birinde grup yeniden gönderme. Her iki taban da tamamen aynıdır ve optimize edilmiş tabanın kopyalanmasıyla oluşturulur. Sonuç göreli birimlerle ifade edilir.

Sonuç kendi adına konuşur, eğer yükleme süresi yaklaşık üçte bir oranında artarsa ki bu hala oldukça tolere edilebilir, o zaman veritabanında işlem yapma süresi üç kat artar, bu tür koşullarda herhangi bir rahat işten bahsetmeye gerek yoktur. Bu arada, bir SSD satın almanın durumu iyileştirebileceği durum budur, ancak sonuçlarla değil, nedenle başa çıkmak ve sadece doğru miktarda RAM satın almak çok daha kolaydır (ve daha ucuzdur).

RAM eksikliği, yeni 1C yapılandırmalarıyla çalışmanın rahatsız olmasının ana nedenidir. Kart üzerinde 2 GB bellek ile minimum uygun yapılandırmalar düşünülmelidir. Aynı zamanda, bizim durumumuzda "sera" koşullarının yaratıldığını unutmayın: temiz bir sistem, yalnızca 1C ve görev yöneticisi başlatıldı. Gerçek hayatta, çalışan bir bilgisayarda genellikle bir tarayıcı, bir ofis paketi, bir antivirüs vb. bellek ve ciddi performans düşüşü.

İşlemci

Merkezi işlem birimi, abartmadan, bilgisayarın kalbi olarak adlandırılabilir, çünkü sonuçta tüm hesaplamaları işleyen odur. Rolünü değerlendirmek için, sanal makine için kullanılabilir çekirdek sayısını ikiden bire düşürerek RAM ile aynı olan başka bir dizi test gerçekleştirdik ve test 1 GB ve 2 GB bellek boyutlarıyla iki kez çalıştırıldı.

Sonuç oldukça ilginç ve beklenmedik çıktı, daha güçlü bir işlemci, aksi takdirde herhangi bir somut fayda sağlamadan, kaynak eksikliği karşısında yükü oldukça etkili bir şekilde üstlendi. 1C Enterprise (dosya modunda), iddiasız olmaktan ziyade işlemci kaynaklarını aktif olarak kullanan bir uygulama olarak adlandırılamaz. Ve zor koşullarda, işlemciye, uygulamanın verilerini hesaplamaktan çok, genel giderlere hizmet verme yükü yüklenir: ek G/Ç işlemleri, vb.

sonuçlar

Peki 1C neden yavaşlıyor? Her şeyden önce, bu bir RAM eksikliğidir, bu durumda ana yük sabit sürücüye ve işlemciye düşer. Ve genellikle ofis konfigürasyonlarında olduğu gibi performansla parlamazlarsa, makalenin başında açıklanan durumu elde ederiz - "iki" iyi çalıştı ve "üç" utanmadan yavaşlar.

İkincisi ağ performansına verilmelidir, 100 Mbps'lik yavaş bir kanal gerçek bir darboğaza dönüşebilir, ancak aynı zamanda ince istemci modu, yavaş kanallarda bile oldukça rahat bir çalışma seviyesini koruyabilir.

O zaman diske dikkat etmelisiniz, bir SSD satın almak pek iyi bir yatırım olmayacaktır, ancak diski daha modern bir diskle değiştirmek gereksiz olmayacaktır. Sabit sürücü nesilleri arasındaki fark, aşağıdaki malzemeden tahmin edilebilir: .

Ve son olarak işlemci. Daha hızlı bir model elbette gereksiz olmayacak, ancak bu bilgisayar ağır işlemler için kullanılmadığı sürece performansını artırmanın pek bir anlamı yok: toplu işleme, ağır raporlar, ay kapanışı vb.

Bu materyalin "1C neden yavaşlıyor" sorusunu hızlı bir şekilde anlamanıza ve sorunu en etkili şekilde ve hiçbir ek ücret ödemeden çözmenize yardımcı olacağını umuyoruz.

Etiketler:

görüntülemek için lütfen JavaScript'i etkinleştirin.

Fotoğraf: Alena Tulyakova, IA Clerk.Ru

Makale, acemi 1C yöneticilerinin yaptığı ana hataları gösterir ve Gilev testi örneğini kullanarak bunların nasıl çözüleceğini gösterir.

Makaleyi yazmanın temel amacı, bariz nüansları henüz 1C ile deneyim kazanmamış yöneticilere (ve programcılara) tekrarlamak değildir.

İkinci bir hedef, herhangi bir eksikliğim varsa, Infostart bunu bana en hızlı şekilde gösterecek.

V. Gilev'in testi şimdiden bir tür "fiili" standart haline geldi. Web sitesindeki yazar oldukça anlaşılır önerilerde bulundu, ancak ben sadece bazı sonuçlar vereceğim ve en olası hatalar hakkında yorum yapacağım. Doğal olarak, ekipmanınızdaki test sonuçları farklı olabilir, bu sadece bir kılavuzdur, ne olması gerektiği ve ne için çaba gösterebileceğiniz. Değişikliklerin adım adım yapılması gerektiğini hemen not etmek istiyorum ve her adımdan sonra hangi sonucu verdiğini kontrol edin.

Infostart'ta benzer makaleler var, ilgili bölümlerde onlara bağlantılar koyacağım (bir şeyi kaçırırsam, lütfen yorumlarda bana bildirin, ekleyeceğim). Öyleyse, 1C'yi yavaşlattığınızı varsayalım. Sorun nasıl teşhis edilir ve yöneticinin mi yoksa programcının mı suçlanacağı nasıl anlaşılır?

İlk veri:

Test edilen bilgisayar, ana kobay: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Karşılaştırma için, tek iş parçacıklı testteki karşılaştırılabilir sonuçlar Core i3-2100 tarafından gösterilir. Ekipman en yeni değil özel olarak alındı, modern ekipmanlarda sonuçlar gözle görülür şekilde daha iyi.

Uzak 1C ve SQL sunucularını test etmek için, SQL sunucusu: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

10 Gbit ağı test etmek için Intel 520-DA2 adaptörleri kullanıldı.

Dosya sürümü. (temel, paylaşılan klasördeki sunucuda yer alır, istemciler bir ağa, CIFS/SMB protokolüne bağlıdır). Adım adım algoritma:

0. Gilev test veritabanını ana veritabanlarıyla aynı klasördeki dosya sunucusuna ekleyin. İstemci bilgisayardan bağlanıyoruz, testi çalıştırıyoruz. Sonucu hatırlıyoruz.

10 yıl önceki eski bilgisayarlar için bile (Pentium 775 soketinde), 1C:Enterprise kısayolunun tıklanmasından veritabanı penceresinin görünümüne kadar geçen sürenin bir dakikadan az olması gerektiği varsayılmaktadır. (Celeron = yavaş çalışma).

Bilgisayarınız 1 GB RAM'e sahip 775 soket pentiumdan daha kötüyse, o zaman size sempati duyuyorum ve dosya sürümünde 1C 8.2'de rahat çalışmanız zor olacak. Yükseltme (geçmiş) veya bir terminal (veya ince istemciler ve yönetilen formlar söz konusu olduğunda web) sunucusuna geçmeyi düşünün.

Bilgisayar daha kötü değilse, yöneticiyi atabilirsiniz. En azından ağ, antivirüs ve HASP koruma sürücüsünün çalışmasını kontrol edin.

Gilev'in bu aşamadaki testi 30 "papağan" ve daha fazlasını gösterdiyse, ancak 1C çalışma tabanı hala yavaş çalışıyorsa - sorular zaten programcı içindir.

1. Bir istemci bilgisayarın ne kadar "sıkıştırabileceğine" ilişkin bir kılavuz olarak, ağ olmadan yalnızca bu bilgisayarın çalışmasını kontrol ediyoruz. Test tabanını yerel bilgisayara (çok hızlı bir diske) koyduk. İstemci bilgisayarda normal bir SSD yoksa, bir ramdisk oluşturulur. Şimdiye kadar en basit ve ücretsiz olan Ramdisk Enterprise'dır.

Sürüm 8.2'yi test etmek için 256 MB ramdisk yeterlidir ve! En önemli. Çalışan bir ramdisk ile bilgisayarı yeniden başlattıktan sonra, 100-200 MB boş alana sahip olmalıdır. Buna göre, bir ramdisk olmadan, boş belleğin normal çalışması için 300-400 MB olmalıdır.

Sürüm 8.3'ü test etmek için 256 MB'lık bir ramdisk yeterlidir, ancak daha fazla boş RAM gereklidir.

Test ederken, işlemci yüküne bakmanız gerekir. İdeale yakın bir durumda (ramdisk), yerel dosya 1c çalışma sırasında 1 işlemci çekirdeği yükler. Buna göre, test sırasında işlemci çekirdeğiniz tam olarak yüklenmemişse, zayıf noktalara bakın. Biraz duygusal ama genel olarak doğru, işlemcinin 1C'nin çalışması üzerindeki etkisi açıklanıyor. Sadece referans olarak, yüksek frekanslı modern Core i3'te bile 70-80 sayıları oldukça gerçektir.

Bu aşamada en sık yapılan hatalar.

Yanlış yapılandırılmış antivirüs. Pek çok antivirüs var, her biri için ayarlar farklı, yalnızca doğru yapılandırma ile ne web ne de Kaspersky 1C'nin müdahale etmediğini söyleyebilirim. "Varsayılan" ayarlarla - yaklaşık 3-5 papağan (%10-15) alınabilir.
performans modu. Nedense çok az insan buna dikkat ediyor ve etkisi en önemli olanıdır. Hıza ihtiyacınız varsa, bunu hem istemci hem de sunucu bilgisayarlarda yapmalısınız. (Gilev'in iyi bir açıklaması var. Tek uyarı, bazı anakartlarda Intel SpeedStep kapalıysa TurboBoost'un açılamamasıdır).

Kısacası, 1C işlemi sırasında, diğer cihazlardan (disk, ağ vb.) Yanıt bekleyen çok şey vardır. Yanıt beklerken performans modu dengeli ise işlemci frekansını düşürür. Cihazdan bir yanıt gelir, 1C'nin (işlemci) çalışması gerekir, ancak ilk döngüler azaltılmış bir frekansta gider, ardından frekans yükselir - ve 1C tekrar cihazdan bir yanıt bekler. Ve böylece - saniyede yüzlerce kez.

Performans modunu (ve tercihen) iki yerde etkinleştirebilirsiniz:

BIOS aracılığıyla. C1, C1E, Intel C durumu (C2, C3, C4) modlarını devre dışı bırakın. Farklı biyografilerde farklı şekilde adlandırılırlar, ancak anlam aynıdır. Uzun süre arayın, yeniden başlatma gerekir, ancak bunu bir kez yaptıysanız unutabilirsiniz. BIOS'ta her şey doğru yapılırsa, hız eklenecektir. Bazı anakartlarda BIOS ayarları, Windows performans modunun bir rol oynamaması için ayarlanabilir. (Gilev tarafından BIOS kurulum örnekleri). Bu ayarlar, sisteminizde bulamadıysanız ve Xeon'unuz yoksa, esas olarak sunucu işlemcileri veya "gelişmiş" BIOS ile ilgilidir - sorun değil.

Kontrol Paneli - Güç - Yüksek performans. Eksi - bilgisayar uzun süre servis görmediyse, bir fanla daha güçlü bir şekilde vızıldar, daha fazla ısınır ve daha fazla enerji tüketir. Bu, performansın bedelidir.

Modun etkin olup olmadığı nasıl kontrol edilir. Görev Yöneticisi - Performans - Kaynak İzleyici - CPU'yu çalıştırın. İşlemci hiçbir şeyle meşgul olana kadar bekleyeceğiz.

Bunlar varsayılan ayarlardır.

BIOS C durumu etkin,

dengeli güç modu

BIOS C durumu etkin, yüksek performans modu

Pentium ve Core için burada durabilirsiniz,

hala Xeon'dan bazı "papağanlar" çıkarabilirsiniz

BIOS'ta, C durumları kapalı, yüksek performans modu.

Turbo boost kullanmıyorsanız - bu şekilde görünmesi gerekir

performans için ayarlanmış sunucu

Ve şimdi sayılar. Hatırlatayım: Intel Xeon 5650, ramdisk. İlk durumda, test ikincisinde 23.26'yı gösteriyor - 49.5. Fark neredeyse iki katıdır. Sayılar değişebilir, ancak oran Intel Core için hemen hemen aynı kalır.

Sayın yöneticiler, 1C'yi istediğiniz gibi azarlayabilirsiniz, ancak son kullanıcıların hıza ihtiyacı varsa, yüksek performans modunu etkinleştirmelisiniz.

c) Turbo Güçlendirme. Öncelikle, örneğin işlemcinizin bu işlevi destekleyip desteklemediğini anlamanız gerekir. Eğer öyleyse, o zaman hala oldukça yasal olarak bir miktar performans elde edebilirsiniz. (Hız aşırtma konularına, özellikle sunuculara değinmek istemiyorum, bunu kendi sorumluluğunuzda ve risk altında yapın. Ancak Otobüs hızını 133'ten 166'ya çıkarmanın hem hız hem de ısı dağılımında çok belirgin bir artış sağladığına katılıyorum)

Turbo boost nasıl açılır yazıyor mesela. Ancak! 1C için bazı nüanslar vardır (en bariz olanı değil). Zorluk, turbo güçlendirmenin maksimum etkisinin C durumu açıldığında ortaya çıkmasıdır. Ve bu resim gibi bir şey çıkıyor:

Lütfen çarpanın maksimum olduğunu, Çekirdek hızının en güzel olduğunu, performansın yüksek olduğunu unutmayın. Ama 1'lerin sonucunda ne olacak?

Ama sonunda, CPU performans testlerine göre çarpanı 23 olan varyantın önde olduğu, Gilev'in dosya sürümündeki testlerine göre çarpanı 22 ve 23 olan performansın aynı olduğu ancak istemci-sunucu versiyonu, çarpanı 23 korku korku korku olan değişken (C durumu 7. seviyeye ayarlanmış olsa bile, yine de C durumu kapalıyken olduğundan daha yavaştır). Bu nedenle tavsiye, her iki seçeneği de kendiniz kontrol edin ve aralarından en iyisini seçin. Her halükarda, 49,5 ile 53 papağan arasındaki fark, özellikle fazla çaba gerektirmediği için oldukça önemlidir.

Sonuç - turbo boost dahil edilmelidir. BIOS'ta Turbo boost öğesini etkinleştirmenin yeterli olmadığını hatırlatmama izin verin, diğer ayarlara da bakmanız gerekir (BIOS: QPI L0s, L1 - devre dışı bırak, talep temizleme - devre dışı bırak, Intel SpeedStep - etkinleştir, Turbo hızlandırma - Denetim Masası - Güç - Yüksek performans) . Ve yine de (dosya sürümü için bile), çarpan orada daha az olsa bile, c-durumunun kapatıldığı seçenekte dururdum. Böyle bir şey al...

Oldukça tartışmalı bir nokta, hafıza frekansıdır. Örneğin hafıza frekansı çok etkili olarak gösteriliyor. Testlerim böyle bir bağımlılığı ortaya çıkarmadı. DDR 2/3/4'ü karşılaştırmayacağım, frekansı değiştirmenin sonuçlarını aynı satırda göstereceğim. Bellek aynıdır, ancak BIOS'ta daha düşük frekansları zorlarız.

Ve test sonuçları. 1C 8.2.19.83, yerel ramdisk dosya sürümü için, bir bilgisayarda istemci-sunucu 1C ve SQL için, Paylaşılan bellek. Turbo boost her iki seçenekte de devre dışıdır. 8.3 karşılaştırılabilir sonuçları gösterir.

Fark, ölçüm hatası dahilindedir. Diğer parametrelerin frekans değişikliği ile değiştiğini göstermek için özellikle CPU-Z ekran görüntülerini çıkardım, aynı CAS Gecikmesi ve RAS'tan CAS'a Gecikmesi, bu da frekans değişikliğini dengeliyor. Fark, bellek modülleri daha yavaştan daha hızlıya fiziksel olarak değiştiğinde olacaktır, ancak orada bile sayılar çok önemli değildir.

2. İstemci bilgisayarın işlemcisini ve belleğini anladığımızda, bir sonraki çok önemli yere - ağa geçiyoruz. Ağ ayarlama hakkında birçok cilt kitap yazıldı, Infostart ( ve diğerleri) hakkında makaleler var, burada bu konuya odaklanmayacağım. 1C'yi test etmeye başlamadan önce, lütfen iki bilgisayar arasındaki iperf'in tüm bandı gösterdiğinden (1 Gbit kartlar için - en az 850 Mbit, ancak daha iyisi 950-980) ve Gilev'in tavsiyesine uyulduğundan emin olun. O zaman - işin en basit testi, garip bir şekilde, ağ üzerinden büyük bir dosyayı (5-10 gigabayt) kopyalamak olacaktır. 1 Gbps'lik bir ağda normal çalışmanın dolaylı bir işareti, ortalama 100 Mb / s kopyalama hızı olacaktır, iyi iş - 120 Mb / s. İşlemci yükünün de zayıf bir nokta (dahil) olabileceği gerçeğine dikkatinizi çekmek istiyorum. Linux'taki SMB protokolü oldukça zayıf bir şekilde paralelleştirilmiştir ve çalışma sırasında bir işlemci çekirdeğini kolayca "yiyebilir" ve artık onu tüketmeyebilir.

Ve ilerisi. Varsayılan ayarlarla, Windows istemcisi en iyi Windows sunucusu (hatta Windows iş istasyonu) ve SMB / CIFS protokolü ile çalışır, linux istemcisi (debian, ubuntu geri kalanına bakmadı) en iyi linux ve NFS ile çalışır (SMB ile de çalışır, ancak yukarıdaki NFS papağanlarında). Doğrusal kopyalama sırasında, NFS'deki Win-Linux sunucusunun bir akışa daha hızlı kopyalanması hiçbir şey ifade etmez. Debian'ı 1C için ayarlamak ayrı bir makalenin konusu, henüz buna hazır değilim, ancak dosya sürümünde aynı ekipmanda Win sürümünden biraz daha iyi performans aldığımı söyleyebilirim, ancak postgres ile 50 yaş üstü kullanıcılarda hala her şey çok kötü.

En önemli şey, "yanmış" yöneticilerin bildikleri, ancak yeni başlayanların dikkate almadığı şeydir. 1c veritabanına giden yolu belirlemenin birçok yolu vardır. Servershare yapabilirsiniz, 192.168.0.1share yapabilirsiniz, net use z: 192.168.0.1share yapabilirsiniz (ve bazı durumlarda bu yöntem de işe yarar, ancak her zaman değil) ve ardından Z sürücüsünü belirtin. Görünüşe göre tüm bu yollar işaret ediyor aynı yere aynı yere, ancak 1C için oldukça istikrarlı bir performans sağlayan tek bir yol var. İşte doğru yapmanız gerekenler:

Komut satırında (veya ilkelerde veya size uygun olan her şeyde) - net use DriveLetter: servershare yapın. Örnek: net kullanım m:serverbases. IP adresini DEĞİL, sunucu adını özellikle vurguluyorum. Sunucu ada göre görünmüyorsa sunucudaki dns'ye veya yerel olarak hosts dosyasına ekleyin. Ancak temyiz isme göre yapılmalıdır. Buna göre, veritabanına giderken bu diske erişin (resme bakın).

Ve şimdi neden böyle bir tavsiyeyi sayılarla göstereceğim. Başlangıç verileri: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kartları OS Win 2008 R2, Win 7, Debian 8. En son sürücüler, güncellemeler uygulandı. Test etmeden önce, Iperf'in tam bant genişliğini sağladığından emin oldum (10 Gbit kartlar hariç, yalnızca 7,2 Gbit'i sıktığı ortaya çıktı, nedenini daha sonra göreceğim, test sunucusu henüz düzgün yapılandırılmadı). Diskler farklıdır, ancak her yerde bir SSD (test için özel olarak tek bir disk takılmıştır, başka hiçbir şey yüklenmez) veya bir SSD'den bir baskın vardır. 100 Mbit hız Intel 362 adaptörünün ayarları sınırlandırılarak elde edildi.1 Gbit bakır Intel 350 ile 1 Gbit optik Intel X520-DA2 (adaptörün hızı sınırlandırılarak elde edildi) arasında fark yoktu. Maksimum performans, turbo boost devre dışıdır (sadece sonuçların karşılaştırılabilir olması için, turbo boost iyi sonuçlar için %10'dan biraz daha az ekler, kötü sonuçlar için hiç etkilemeyebilir). Sürümler 1C 8.2.19.86, 8.3.6.2076. Tüm sayıları vermiyorum, karşılaştırılacak bir şey olması için yalnızca en ilginç olanları veriyorum.

	100Mbit CIFS 2008 Kazan - 2008 Kazan ip adresi ile arama	100Mbit CIFS 2008 Kazan - 2008 Kazan isme göre adres	1 Gbit CIFS 2008 Kazan - 2008 Kazan ip adresi ile arama	1 Gbit CIFS 2008 Kazan - 2008 Kazan isme göre adres	1 Gbit CIFS Win 2008 - Win 7 isme göre adres	1 Gbit CIFS Windows 2008 - Debian isme göre adres	10Gbit CIFS 2008 Kazan - 2008 Kazan ip adresi ile arama	10Gbit CIFS 2008 Kazan - 2008 Kazan isme göre adres
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 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

Sonuçlar (tablodan ve kişisel deneyimden. Yalnızca dosya sürümü için geçerlidir):

Bu ağ normal olarak yapılandırılmışsa ve yol 1C'de doğru yazılmışsa, ağ üzerinden oldukça normal iş sayıları alabilirsiniz. İlk Core i3'ler bile 40'tan fazla papağan verebilir ki bu oldukça iyidir ve bunlar sadece papağanlar değil, gerçek işte de fark göze çarpıyor. Ancak! birkaç (10'dan fazla) kullanıcıyla çalışırken sınırlama artık ağ olmayacak, burada 1 Gbit hala yeterli, ancak çok kullanıcılı çalışma (Gilev) sırasında engelleme.
platform 1C 8.3, yetkili ağ kurulumu için birçok kez daha talepkardır. Temel ayarlar - Gilev'e bakın, ancak her şeyin etkileyebileceğini unutmayın. Virüsten koruma yazılımını kaldırmalarından (ve sadece kapatmamalarından), FCoE gibi protokolleri kaldırmalarından, sürücüleri daha eski ama Microsoft sertifikalı bir sürüme (özellikle asus ve uzun kartlar gibi ucuz kartlar için) değiştirmekten, kaldırmadan hızlanma gördüm. sunucudan ikinci ağ kartı. Birçok seçenek, ağı düşünceli bir şekilde yapılandırın. Platform 8.2'nin kabul edilebilir sayılar verdiği ve 8.3'ün iki veya daha fazla kat daha az olduğu bir durum olabilir. 8.3 platform sürümleriyle oynamaya çalışın, bazen çok büyük bir etki elde edersiniz.
1C 8.3.6.2076 (belki daha sonra, henüz tam sürümü aramadım) ağ üzerinden kurulumu 8.3.7.2008'den daha kolaydır. 8.3.7.2008'den itibaren normal ağ işlemi elde etmek için (karşılaştırılabilir papağanlarda) yalnızca birkaç kez ortaya çıktı, daha genel bir durum için tekrarlayamadım. Pek bir şey anlamadım, ancak Process Explorer'ın ayak örtülerine bakılırsa, kayıt oraya 8.3.6'daki gibi gitmiyor.
100 Mbps'lik bir ağda çalışırken yük programının küçük olmasına rağmen (ağın ücretsiz olduğunu söyleyebiliriz), çalışma hızı hala 1 Gbps'den çok daha düşük. Nedeni ağ gecikmesidir.
1C 8.2 için Ceteris paribus (iyi işleyen ağ), Intel-Realtek bağlantısı Intel-Intel'den %10 daha yavaştır. Ancak realtek-realtek genellikle birdenbire keskin bir düşüş sağlayabilir. Bu nedenle, para varsa, Intel ağ kartlarını her yerde tutmak daha iyidir, para yoksa Intel'i yalnızca sunucuya (KO'nuza) koyun. Evet ve Intel ağ kartlarını ayarlamak için birçok kez daha fazla talimat var.
Varsayılan antivirüs ayarları (örneğin, drweb 10 sürümü) papağanların yaklaşık %8-10'unu ortadan kaldırır. Düzgün yapılandırırsanız (güvenli olmasa da 1cv8 işleminin her şeyi yapmasına izin verin) - hız, antivirüs olmadan aynıdır.
Linux gurularını OKUMAYIN. Samba içeren bir sunucu harika ve ücretsizdir, ancak sunucuya (veya daha iyisi - sunucu işletim sistemi) Win XP veya Win7 koyarsanız, dosya sürümü 1c daha hızlı çalışacaktır. Evet, hem samba hem de protokol yığını ve ağ ayarları ve debian / ubuntu'daki çok daha fazlası iyi ayarlanmış, ancak bu uzmanlar için önerilir. Linux'u varsayılan ayarlarla kurup sonra yavaş olduğunu söylemenin bir anlamı yok.
Net use ile bağlanan diskleri fio ile test etmek iyi bir fikirdir. En azından bunların 1C platformunda mı yoksa ağ / diskte mi sorun olduğu netleşecek.
Tek kullanıcılı bir varyant için, 1 Gb ile 10 Gb arasındaki farkın görünür olacağı testler (veya bir durum) düşünemiyorum. Dosya sürümü için 10Gbps'nin daha iyi sonuç verdiği tek yer, diskleri iSCSI aracılığıyla bağlamaktı, ancak bu ayrı bir makalenin konusu. Yine de dosya versiyonu için 1 Gbit kartların yeterli olduğunu düşünüyorum.
Neden 100 Mbit'lik bir ağda 8.3, 8.2'den belirgin şekilde daha hızlı çalışıyor - anlamıyorum ama gerçek oldu. Diğer tüm ekipmanlar, diğer tüm ayarlar tamamen aynıdır, yalnızca bir durumda 8.2 test edilir ve diğerinde - 8.3.
Ayarlanmamış NFS kazan - kazan veya kazan-lin 6 papağan verir, tabloya dahil etmemiştir. Ayarladıktan sonra 25 aldım, ancak kararsız (ölçümlerdeki artış 2 birimden fazla). Şimdiye kadar pencerelerin kullanımı ve NFS protokolü hakkında önerilerde bulunamıyorum.

Tüm ayarlar ve kontrollerden sonra, testi istemci bilgisayardan tekrar çalıştırıyoruz, iyileştirilmiş sonuca seviniyoruz (eğer işe yaradıysa). Sonuç düzeldiyse, 30'dan fazla papağan var (ve özellikle 40'tan fazla), aynı anda çalışan 10'dan az kullanıcı var ve çalışan veritabanı hala yavaşlıyor - neredeyse kesinlikle bir programcının sorunu (veya zaten dosya sürümünün kapasitesinin zirvesine ulaştı).

Terminal sunucusu. (temel sunucuda bulunur, istemciler bir ağa, RDP protokolüne bağlıdır). Adım adım algoritma:

Gilev test veritabanını ana veritabanları ile aynı klasörde sunucuya ekliyoruz. Aynı sunucudan bağlanıp testi çalıştırıyoruz. Sonucu hatırlıyoruz.
Dosya versiyonundaki ile aynı şekilde işlemciyi kuruyoruz. Bir terminal sunucusu söz konusu olduğunda, işlemci genellikle ana rolü oynar (hafıza eksikliği veya çok miktarda gereksiz yazılım gibi bariz zayıflıklar olmadığı anlaşılmaktadır).
Bir terminal sunucusu durumunda ağ kartlarının ayarlanması, 1'lerin çalışması üzerinde pratik olarak hiçbir etkiye sahip değildir. "Özel" rahatlık sağlamak için, sunucunuz 50'den fazla papağan veriyorsa, yalnızca kullanıcıların rahatlığı, daha hızlı yanıt ve kaydırma için RDP protokolünün yeni sürümleriyle oynayabilirsiniz.
Çok sayıda kullanıcının aktif çalışmasıyla (ve burada denerseniz zaten 30 kişiyi bir üsse bağlamayı deneyebilirsiniz), bir SSD sürücüsü takmak çok arzu edilir. Nedense diskin özellikle 1C'nin çalışmasını etkilemediğine inanılıyor, ancak tüm testler denetleyici önbelleği yazma için etkinleştirilerek yapılıyor ki bu yanlış. Test tabanı küçüktür, önbelleğe sığar, dolayısıyla yüksek sayılar. Gerçek (büyük) veritabanlarında her şey tamamen farklı olacaktır, bu nedenle testler için önbellek devre dışı bırakılır.

Örneğin Gilev testinin çalışmasını farklı disk seçenekleriyle kontrol ettim. Sadece bir eğilim göstermek için elimde olanlardan diskler koydum. 8.3.6.2076 ve 8.3.7.2008 arasındaki fark küçüktür (Ramdisk Turbo boost sürüm 8.3.6'da 56.18 verir ve 8.3.7.2008 55.56 verir, diğer testlerde fark daha da küçüktür). Güç tüketimi - maksimum performans, turbo boost devre dışı (aksi belirtilmedikçe).

	Baskın 10 4x SATA 7200 ATA ST31500341AS	Baskın 10 4x SAS 10k	Baskın 10 4x SAS 15k	Tek SSD	ramdisk	ramdisk	önbellek etkin RAID denetleyicisi
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 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

RAID denetleyicisinin dahil edilen önbelleği, diskler arasındaki tüm farkı ortadan kaldırır, sayılar hem sat hem de sas için aynıdır. Bununla az miktarda veri için test yapmak işe yaramaz ve bir gösterge değildir.
8.2 platformu için, SATA ve SSD seçenekleri arasındaki performans farkı iki kattan fazladır. Bu bir yazım hatası değil. SATA sürücülerinde test sırasında performans monitörüne bakarsanız. o zaman açıkça görülebilen "Aktif disk süresi (% olarak)" 80-95 vardır. Evet, disklerin yazma önbelleğini etkinleştirirseniz, baskın denetleyici önbelleğini etkinleştirirseniz hız 35'e yükselir - 49'a kadar (şu anda hangi disklerin test edildiğinden bağımsız olarak). Ancak bunlar önbelleğin sentetik papağanlarıdır, büyük veritabanlarıyla yapılan gerçek çalışmalarda hiçbir zaman %100 yazma önbelleği isabet oranı olmayacaktır.
Ucuz SSD'lerin bile hızı (Agility 3'te test ettim) dosya sürümünün çalışması için yeterlidir. Yazma kaynağı başka bir konudur, burada her bir özel duruma bakmanız gerekir, Intel 3700'ün daha yüksek bir mertebeye sahip olacağı açıktır, ancak orada fiyat karşılık gelir. Ve evet, bir SSD sürücüsünü test ederken, bu sürücünün önbelleğini de daha büyük ölçüde test ettiğimi, gerçek sonuçların daha az olacağını anlıyorum.
En doğru (benim açımdan) çözüm, dosya tabanı (veya birkaç dosya tabanı) için bir ayna baskınına 2 SSD disk tahsis etmek ve oraya başka bir şey koymamak olacaktır. Evet, bir ayna ile SSD'ler aynı şekilde aşınır ve bu bir eksidir, ancak en azından denetleyici elektroniğindeki hatalara karşı bir şekilde sigortalıdırlar.
Dosya sürümü için SSD disklerin ana avantajları, birçok veritabanı olduğunda ve her birinin birkaç kullanıcısı olduğunda ortaya çıkacaktır. 1-2 baz ve 10 bölgesinde kullanıcı varsa, o zaman SAS diskleri yeterli olacaktır. (ancak her durumda - en azından perfmon aracılığıyla bu disklerin yüklenmesine bakın).
Bir terminal sunucusunun ana avantajları, çok zayıf istemcilere sahip olabilmesi ve ağ ayarlarının terminal sunucusunu çok daha az etkilemesidir (yine KO'nuz).

Sonuçlar: Gilev testini terminal sunucusunda (çalışan veritabanlarının bulunduğu aynı diskten) ve çalışan veritabanının yavaşladığı anlarda çalıştırırsanız ve Gilev testi iyi bir sonuç gösteriyorsa (30'un üzerinde), o zaman yavaş ana çalışma veritabanının çalışması, büyük olasılıkla bir programcıyı suçlamaktır.

Gilev testi küçük sayılar gösteriyorsa ve hem yüksek frekanslı bir işlemciniz hem de hızlı diskleriniz varsa, burada yöneticinin en azından perfmon alması ve tüm sonuçları bir yere kaydetmesi ve izlemesi, gözlemlemesi, sonuçlar çıkarması gerekir. Kesin bir tavsiye olmayacak.

İstemci-sunucu seçeneği.

Testler sadece 8.2'de yapıldı, tk. 8.3'te, her şey oldukça ciddi bir şekilde sürüme bağlıdır.

Test için, ana eğilimleri göstermek için farklı sunucu seçeneklerini ve aralarındaki ağları seçtim.

	1C: Xeon 5520 SQL: Xeon E5-2630	1C: Xeon 5520 SQL: Xeon E5-2630 Fiber kanal-SSD	1C: Xeon 5520 SQL: Xeon E5-2630 Fiber kanal - SAS	1C: Xeon 5650 SQL: Xeon E5-2630	1C: Xeon 5650 SQL: Xeon E5-2630 Fiber kanal-SSD	1C: Xeon 5650 SQL: Xeon E5-2630	1C: Xeon 5650 =	1C: Xeon 5650 =	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
1С 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

Görünüşe göre tüm ilginç seçenekleri değerlendirdim, başka bir şeyle ilgileniyorsanız - yorumları yazın, yapmaya çalışacağım.

Depolama büyük önbellek boyutlarına sahip olsa da depolamadaki SAS, yerel SSD'lerden daha yavaştır. Gilev testi için SSD'ler ve yerel ve depolama sistemleri karşılaştırılabilir hızlarda çalışır. MCC'den gelen 1C yükü dışında herhangi bir standart çok iş parçacıklı test (yalnızca kayıtlar değil, tüm ekipman) bilmiyorum.
1C sunucusunu 5520'den 5650'ye değiştirmek, performansı neredeyse iki katına çıkardı. Evet, sunucu yapılandırmaları tam olarak uyuşmuyor, ancak bir eğilim gösteriyor (şaşırtıcı bir şey yok).
Elbette, SQL sunucusundaki frekansı artırmak bir etki sağlar, ancak 1C sunucusundakiyle aynı değildir, MS SQL sunucusu (bu sorulursa) mükemmel bir şekilde çok çekirdekli ve boş hafıza kullanabilir.
1C ve SQL arasındaki ağı 1 Gbps'den 10 Gbps'ye değiştirmek papağanların yaklaşık %10'unu verir. Daha fazlası bekleniyor.
Paylaşılan belleğin etkinleştirilmesi, makalede açıklandığı gibi %15 olmasa da yine de etkiyi verir. Bunu yaptığınızdan emin olun, hızlı ve kolaydır. Birisi yükleme sırasında SQL sunucusuna adlandırılmış bir örnek verdiyse, 1C'nin çalışması için sunucu adının FQDN (tcp / ip çalışacaktır), localhost veya yalnızca SunucuAdı aracılığıyla değil, SunucuAdıÖrnekAdı aracılığıyla, örneğin zz- belirtilmesi gerekir. testzztest. (Aksi takdirde aşağıdaki DBMS hatası oluşur: Microsoft SQL Server Native Client 10.0: Paylaşılan Bellek Sağlayıcı: SQL Server 2000'e bağlanmak için kullanılan paylaşılan bellek kitaplığı bulunamadı. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, durum=1, Önem Derecesi=10, yerel=126, satır=0).
100'den küçük kullanıcılar için, iki ayrı sunucuya bölünmenin tek noktası, yalnızca 32 GB RAM'i destekleyen Win 2008 Std (ve daha eski sürümler) için bir lisanstır. Diğer tüm durumlarda, 1C ve SQL kesinlikle aynı sunucuya kurulmalı ve daha fazla (en az 64 GB) bellek verilmelidir. MS SQL'e 24-28 GB'tan daha az RAM vermek haksız bir açgözlülüktür (bunun için yeterli belleğiniz olduğunu ve her şeyin yolunda gittiğini düşünüyorsanız, belki 1C dosya sürümü sizin için yeterli olur?)
Bir sanal makinede bir grup 1C ve SQL'in ne kadar kötü çalıştığı ayrı bir makalenin konusudur (ipucu - gözle görülür şekilde daha kötü). Hyper-V'de bile işler o kadar net değil...
Dengeli performans modu kötü. Sonuçlar, dosya sürümüyle iyi bir uyum içindedir.
Birçok kaynak, hata ayıklama modunun (ragent.exe -debug) performansta güçlü bir düşüş sağladığını söylüyor. Evet, düşürür, ancak %2-3'ü önemli bir etki olarak adlandırmam.

Belirli bir durum için en az tavsiye olacaktır, çünkü. istemci-sunucu çalışma modundaki frenler en zor durumdur ve her şey çok bireysel olarak yapılandırılmıştır. En kolay yol, normal çalışma için YALNIZCA 1C ve MS SQL için ayrı bir sunucu almanız, işlemcileri maksimum frekansa (3 GHz'in üzerinde), taban için SSD sürücülerine ve daha fazla belleğe (128+) koymanız gerektiğini söylemenin en kolay yoludur. , sanallaştırma kullanmayın. Yardımcı oldu - harika, şanslısın (ve bu kadar çok şanslı olacak, sorunların yarısından fazlası yeterli bir yükseltme ile çözüldü). Değilse, diğer tüm seçenekler zaten ayrı değerlendirme ve ayarlar gerektirir.

Sık sık şu tür sorularla karşılaşıyorum:

1C sunucusunun yavaşlaması nedeniyle mi?
1C'li bilgisayar çok yavaş çalışıyor
istemci 1C çok yavaş

Ne yapmalı ve nasıl kazanılmalı, vb. Sırasıyla:

İstemciler, 1C'nin sunucu sürümüyle çok yavaş çalışır

1C'nin yavaş çalışmasına ek olarak, ağ dosyalarıyla da yavaş çalıştığı gözlemlenir. Sorun normal çalışma sırasında ve RDP ile ortaya çıkıyor

Bunu çözmek için, Seven veya 2008 sunucusunun her kurulumundan sonra, her zaman

netsh int tcp global otomatik ayarlamayı ayarla = devre dışı

netsh int tcp global otomatik ayar seviyesini ayarla=devre dışı

netsh int tcp set global rss=devre dışı baca=devre dışı

ve ağ sorunsuz çalışıyor

bazen en iyisi:
netsh interface tcp global autotuning'i ayarla= HighlyRestricted

kurulum böyle görünüyor

Antivirüs veya Windows Güvenlik Duvarını Yapılandırma

1C sunucusunun çalışması için Anti-Virüs veya Windows güvenlik duvarı nasıl yapılandırılır (örneğin, 1C Sunucusundan bir paket: Enterprise ve MS SQL 2008).

Kural ekle:

SQL sunucusu, standart TCP bağlantı noktası 1433'teki bağlantıları kabul ederse, buna izin veririz.
SQL bağlantı noktası dinamikse, %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe uygulamasına bağlantılara izin vermelisiniz.
Sunucu 1C, 1541 numaralı bağlantı noktalarında, küme 1540'ta ve 1560-1591 aralığında çalışır. Tamamen mistik nedenlerle, bazen böyle bir açık port listesi hala sunucuya bağlantıya izin vermiyor. Kesin olarak çalışması için 1540-1591 aralığına izin verin.

Sunucu / Bilgisayar Performans Ayarı

Bilgisayarın maksimum performansla çalışabilmesi için şu şekilde yapılandırmanız gerekir:

1. BIOS ayarları

Sunucu BIOS'unda, işlemci gücünden tasarruf etmek için tüm ayarları devre dışı bırakın.
"C1E" varsa & BAĞLANTIYI AYIRDIĞINIZDAN emin olun!!
Çok paralel olmayan bazı görevler için, bios'ta hyperthreading'in kapatılması da önerilir.
Bazı durumlarda (özellikle HP için!), sunucunun BIOS'una gitmeniz ve orada adına EIST, Intel SpeedStep ve C1E olan öğeleri kapatmanız gerekir.
Bunun yerine, adına Turbo Boost olan işlemciyle ilgili öğeleri aynı yerde bulmanız ve bunları ETKİNLEŞTİRMENİZ gerekir.
BIOS'ta güç tasarrufu modunun genel bir göstergesi varsa ve bunu maksimum performans modunda etkinleştirin ("agresif" olarak da adlandırılabilir)