Performans 1s 8.3 dosya sürümü. Dosya veritabanı darboğazları - nasıl önlenir (son deneyimlerden). Dosya veritabanından SQL'e geçiş talimatları
1C: Muhasebe 2.0'dan sürüm 3.0'a geçtikten sonra yeni sürümün hızı yavaşlar. Bu makalede bu soruna bakacağız ve 1C: Muhasebe 3.0 programındaki işlemlerin daha hızlı yapılmasına yardımcı olacak eylemler için adım adım talimatlar sunacağız.
Kural olarak programın yavaş çalışmasının nedeni sistemde rutin ve arka plan işlerinin çalışıyor olmasıdır. Sürüm 3.0 yapılandırmasının sunucu sürümünde, çalışma saatleri dışında programı sürdürmek için birçok işlemi otomatikleştirmenize olanak tanır. Ancak dosya çalışma modunda kullanıcı çalışırken arka plan işleri başlatılır ve bu nedenle sistem yavaşlar.
1C: Muhasebe 3.0 dosya modunda çalışmayı hızlandırmak için arka plan işlerinin devre dışı bırakılması önerilir. Bunu yapmak için bölüme başvurmamız gerekir. Yönetim. Gezinme panelindeki bu bölümde bulduğumuz Destek ve servis.
Bölümü aç Düzenleyici işlemler ve ardından bağlantıya tıklayın Rutin ve arka plan görevleri.
Önünüzde aktif (etkin) görevlerin işaretlendiği bir liste görünecektir. 
Bir görevi devre dışı bırakmak için onu açmanız ve seçeneğin işaretini kaldırmanız gerekir. "Etkinleştirilmiş", ardından düğmeye basın Kaydet ve kapat.
Programın dosya sürümünde çalışırken listede bulunan tüm rutin görevleri devre dışı bırakmanızı öneririz. Sistemin hızının düşük olmasının bir diğer olası nedeni de etkin mekanizmadır. Tam metin araması. 1C: Muhasebe 3.0 programında bu mekanizma isteğe bağlı olduğundan, devre dışı bırakmak. Bunu yapmak için bölüme gitmeniz gerekir. Düzenleyici işlemler işareti kaldır Tam metin veri araması.
Arayüz LLC'deki meslektaşlarımız sayesinde, özellikle 1c 8.3 sürümüne geçerken, 1c'yi neyin yavaşlattığına dair sıklıkla sorular alıyoruz, size ayrıntılı olarak anlatıyoruz:
Önceki yayınlarımızda disk alt sistemi performansının 1C hızı üzerindeki etkisine zaten değinmiştik 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 bilgisayarlarından birinin sunucu olarak kullanıldığı bir ağ üzerinden bir dosya veritabanıyla veya normal, çoğunlukla aynı zamanda ucuz bir bilgisayara dayalı özel bir dosya sunucusuyla çalışmayı içerir.
1C'deki Rusça kaynaklar üzerine yapılan küçük bir çalışma, bu sorunun özenle önlendiğini gösterdi; sorunlar ortaya çıkarsa, genellikle istemci-sunucu veya terminal moduna geçmeniz önerilir. Yönetilen bir uygulamadaki yapılandırmaların normalden çok daha yavaş çalıştığı da neredeyse genel olarak kabul görmüştür. Kural olarak, verilen argümanlar "demir"dir: "Muhasebe 2.0 uçtu, ancak "troyka" zar zor hareket etti" elbette, bu sözlerde bazı gerçekler var, o yüzden anlamaya çalışalım.
Kaynak tüketimi, ilk bakışta
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 belirli kaynakların performans üzerinde birincil etkiye sahip olduğunu bulmak.
Test için, sırasıyla Windows Server 2012 R2 ve Windows 8.1 çalıştıran iki sanal makine aldık ve onlara Core i5-4670 ana bilgisayarından 2 çekirdek ve yaklaşık olarak ortalama bir ofis makinesine karşılık gelen 2 GB RAM verdik. Sunucu, iki WD Se'den oluşan bir RAID 0 dizisine yerleştirildi ve istemci, benzer bir genel amaçlı disk dizisine yerleştirildi.
Deneysel temeller olarak Muhasebe 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 konfigürasyonlar platformda başlatıldı 8.3.5.1443 .
Dikkat çeken ilk şey, Troyka'nın bilgi tabanının önemli ölçüde büyüyen boyutunun yanı sıra RAM'e olan iştahın da artması:
Her zamanki gibi duymaya hazırız: “Neden bu üçüne bunu da eklediler” ama acele etmeyelim. Az ya da çok nitelikli bir yönetici gerektiren istemci-sunucu sürümlerinin kullanıcılarının aksine, dosya sürümlerinin kullanıcıları veritabanlarının bakımını nadiren düşünürler. Ayrıca, bu veritabanlarına hizmet veren (güncellemeyi oku) uzman şirketlerin çalışanları bunu nadiren düşünür.
Bu arada, 1C bilgi tabanı, kendi formatında tam teşekküllü bir DBMS'dir ve bu da bakım gerektirir ve bunun için adı verilen bir araç bile vardır. Bilgi tabanının test edilmesi ve düzeltilmesi. Belki de isim, bir şekilde bunun sorunları gidermeye yönelik bir araç olduğunu ima eden 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 indeksleme, herhangi bir DBMS yöneticisi için veritabanlarını optimize etmek için iyi bilinen araçlardır. . Kontrol edelim mi?
Seçilen eylemleri uyguladıktan sonra, veritabanı keskin bir şekilde "ağırlık kaybetti", şimdiye kadar hiç kimsenin optimize etmediği "iki"den bile daha küçük hale geldi ve RAM tüketimi de biraz azaldı.
Daha sonra yeni sınıflandırıcılar ve dizinler yüklendikten, dizinler oluşturulduktan vb. sonra. tabanın boyutu artacaktır, genel olarak “üç” baz “iki” bazdan daha büyüktür. Ancak bu daha önemli değil, eğer ikinci sürüm 150-200 MB RAM ile yetiniyorsa, yeni sürümün yarım gigabayta ihtiyacı vardır ve programla çalışmak için gerekli kaynaklar planlanırken bu değer dikkate alınmalıdır.
Açık
Ağ bant genişliği, ağ uygulamaları için en önemli parametrelerden biridir; özellikle ağ üzerinde önemli miktarda veri taşıyan dosya modundaki 1C gibi. Küçük işletmelerin ağlarının çoğu, ucuz 100 Mbit/s ekipmanı temel alınarak inşa edilmiştir; bu nedenle, 100 Mbit/s ve 1 Gbit/s ağlarındaki 1C performans göstergelerini karşılaştırarak test etmeye başladık.
Ağ üzerinden bir 1C dosya veritabanını başlattığınızda ne olur? İstemci, özellikle bu ilk "soğuk" başlangıç ise, oldukça büyük miktarda bilgiyi geçici klasörlere indirir. 100 Mbit/s'de kanal genişliğine ulaşmamız bekleniyor ve indirme işlemi önemli miktarda zaman alabilir, bizim durumumuzda yaklaşık 40 saniye (grafiği bölmenin maliyeti 4 saniyedir).
Verilerin bir kısmı önbellekte saklandığından ve yeniden başlatmaya kadar orada kaldığından ikinci başlatma daha hızlıdır. Gigabit ağına geçiş, hem "soğuk" hem de "sıcak" program yüklemesini önemli ölçüde hızlandırabilir ve değerlerin oranına saygı gösterilir. Bu nedenle her ölçümün en büyük değerini %100 alarak sonucu göreceli değerlerle 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üklenir, 100 Mbit/s'den 1 Gbit/s'ye geçiş, indirme süresini dört kat hızlandırmanıza olanak tanır. Bu modda optimize edilmiş ve optimize edilmemiş "troyka" veritabanları arasında hiçbir fark yoktur.
Ayrıca ağ hızının, örneğin grup aktarımları sırasında ağır modlarda çalışma üzerindeki etkisini de kontrol ettik. Sonuç ayrıca göreceli değerlerle de ifade edilir:
Burada daha ilginç olan, 100 Mbit/s ağdaki "üç"ün optimize edilmiş tabanı "iki" ile aynı hızda çalışıyor ve optimize edilmemiş olan iki kat daha kötü sonuçlar gösteriyor. Gigabit'te oranlar aynı kalıyor, optimize edilmemiş "üç" de "iki"nin yarısı kadar yavaş ve optimize edilmiş olan üçte bir oranında geride kalıyor. Ayrıca, 1 Gbit/s'ye geçiş, yürütme süresini sürüm 2.0 için üç kat ve sürüm 3.0 için yarı yarıya azaltmanıza olanak tanır.
Ağ hızının günlük işler üzerindeki etkisini değerlendirmek için şunları kullandık: Performans ölçümü, her veritabanında önceden belirlenmiş bir dizi eylemin gerçekleştirilmesi.
Aslında, günlük görevler için ağ verimi bir darboğaz değildir, optimize edilmemiş bir "üç", "iki" den yalnızca% 20 daha yavaştır ve optimizasyondan sonra hemen hemen aynı derecede daha hızlı olduğu ortaya çıkar - ince istemci modunda çalışmanın avantajları bellidir. 1 Gbit/s'ye geçiş, optimize edilmiş tabana herhangi bir avantaj sağlamaz ve optimize edilmemiş olan ve ikisi, aralarında küçük bir fark göstererek daha hızlı çalışmaya başlar.
Yapılan testlerde ağın yeni konfigürasyonlar için bir darboğaz olmadığı ve yönetilen uygulamanın normalden daha hızlı çalıştığı açıkça görülüyor. Ağır görevler ve veritabanı yükleme hızı sizin için kritikse 1 Gbit/s'ye geçmenizi de önerebilirsiniz; diğer durumlarda, yeni yapılandırmalar 100 Mbit/s'lik yavaş ağlarda bile etkili bir şekilde çalışmanıza olanak tanır.
Peki 1C neden yavaş? Daha ayrıntılı olarak inceleyeceğiz.
Sunucu diski alt sistemi ve SSD
Önceki yazımızda veritabanlarını SSD üzerine yerleştirerek 1C performansında artış elde etmiştik. Belki de sunucunun disk alt sisteminin performansı yetersizdir? Bir disk sunucusunun performansını iki veritabanında aynı anda grup çalışması sırasında ölçtük ve oldukça iyimser bir sonuç elde ettik.
Saniyede nispeten fazla sayıda giriş/çıkış işlemine (IOPS) - 913 rağmen, kuyruk uzunluğu 1,84'ü aşmadı; bu, iki diskli bir dizi için çok iyi bir sonuçtur. Buna dayanarak, sıradan disklerden yapılmış bir aynanın, 8-10 ağ istemcisinin ağır modlarda normal çalışması için yeterli olacağı varsayımını yapabiliriz.
Peki bir sunucuda SSD'ye ihtiyaç var mı? Bu soruyu cevaplamanın en iyi yolu, benzer bir yöntem kullanarak yaptığımız testlerden geçecektir; ağ bağlantısı her yerde 1 Gbit/s'dir, sonuç da göreceli değerlerle ifade edilir.
Veritabanının yükleme hızıyla başlayalım.
Bazıları için şaşırtıcı görünebilir ancak sunucudaki SSD, veritabanının yüklenme hızını etkilemez. Önceki testin gösterdiği gibi, buradaki ana sınırlayıcı faktör ağ verimi ve istemci performansıdır.
Tekrarlamaya geçelim:
Yukarıda disk performansının ağır modlarda çalışmak için bile oldukça yeterli olduğunu 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 ona erişim hızını artırdığını bir kez daha doğrulamaktadır.
Günlük görevlerde resim benzerdir:
Yalnızca optimize edilmemiş veritabanı SSD'den yararlanır. Elbette bir SSD satın alabilirsiniz, ancak veritabanının zamanında bakımını düşünmek çok daha iyi olacaktır. Ayrıca bölümü sunucudaki bilgi tabanlarıyla birleştirmeyi de unutmayın.
İstemci disk alt sistemi ve SSD
Önceki materyalde SSD'nin yerel olarak kurulu 1C'nin çalışma hızı üzerindeki etkisini tartıştık; söylenenlerin çoğu ağ modunda çalışmak için de geçerlidir. Gerçekten de 1C, arka plan ve rutin görevler de dahil olmak üzere disk kaynaklarını oldukça aktif olarak kullanıyor. Aşağıdaki şekilde, Muhasebe 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 veritabanıyla aktif çalışmanın yürütüldüğü bir iş istasyonu için sıradan seri üretilen bir HDD'nin performans kaynaklarının oldukça yeterli olduğunun da farkında olmalısınız. 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şlerinizde radikal bir hızlanma fark etmeyeceksiniz.
Yavaş bir sabit sürücü bazı işlemleri yavaşlatabilir ancak tek başına 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ığında takılı olan bellek miktarıyla çalışmaya devam ediyor. İlk sorunların pusuda olduğu yer burasıdır. Ortalama bir “troykanın” yaklaşık 500 MB bellek gerektirdiğini düşünürsek, toplam 1 GB RAM miktarının programla çalışmak için yeterli olmayacağını varsayabiliriz.
Sistem hafızasını 1 GB'a düşürdük ve iki adet bilgi veritabanını devreye aldık.
İlk bakışta her şey o kadar da kötü değil, program iştahını bastırdı ve mevcut hafızaya iyi yerleşti, ancak operasyonel verilere olan ihtiyacın değişmediğini de unutmayalım, peki nereye gitti? Diske, önbelleğe, takas vb.'ye dökülen bu işlemin özü, o anda ihtiyaç duyulmayan verilerin, miktarı yeterli olmayan hızlı RAM'den yavaş disk belleğine gönderilmesidir.
Nereye gidiyor? Ağır işlemlerde sistem kaynaklarının nasıl kullanıldığını görelim, örneğin iki veritabanında aynı anda grup yeniden aktarımı başlatalım. İlk olarak 2 GB RAM'e sahip bir sistemde:
Görüldüğü gibi sistem, veriyi almak için ağı ve onu işlemek için işlemciyi aktif olarak kullanıyor; disk etkinliği önemsizdir; işlem sırasında ara sıra artar, 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 sürücüye 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 öznel çalışmanın bile son derece rahatsız edici olduğu ortaya çıktı; dizinler ve dergiler önemli bir gecikmeyle ve diske aktif erişimle açıldı. Örneğin, Mal ve Hizmet Satışları günlüğünün açılması yaklaşık 20 saniye sürdü ve tüm bu süre boyunca yüksek disk etkinliği (kırmızı çizgiyle vurgulanmıştır) eşlik etti.
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: ilk veritabanının yükleme hızı, ikinci veritabanının yükleme hızı ve veritabanlarından birinde grubun yeniden çalıştırılması . Her iki veritabanı da tamamen aynıdır ve optimize edilmiş veritabanı kopyalanarak oluşturulmuştur. Sonuç göreceli birimlerle ifade edilir.
Sonuç kendi adına konuşuyor: 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 rahat bir çalışmadan bahsetmeye gerek yoktur. Bu arada, bir SSD satın almanın durumu iyileştirebileceği durum budur, ancak sonuçlarla değil sebeple 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 edici olmasının ana nedenidir. 2 GB belleğe sahip konfigürasyonların minimum düzeyde uygun olduğu 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 çalışıyordu. Gerçek hayatta, bir çalışma bilgisayarında, kural olarak, bir tarayıcı, bir ofis paketi açıktır, bir antivirüs çalışıyor vb. ağır işlemler sırasında hafıza eksikliği ve üretkenlikte keskin bir düşüşle karşılaşmazsınız.
İşlemci
Abartmadan, merkezi işlemciye bilgisayarın kalbi denilebilir, çünkü sonuçta tüm hesaplamaları işleyen odur. Rolünü değerlendirmek için, sanal makinenin kullanabileceği çekirdek sayısını ikiden bire düşürerek RAM için olduğu gibi başka bir test dizisi gerçekleştirdik ve test, 1 GB ve 2 GB bellek miktarlarıyla iki kez gerçekleştirildi.
Sonuç oldukça ilginç ve beklenmedik çıktı: Daha güçlü bir işlemci, kaynak eksikliği olduğunda, geri kalan zamanlarda herhangi bir somut avantaj sağlamadan yükü oldukça etkili bir şekilde üstlendi. 1C Enterprise'a işlemci kaynaklarını aktif olarak kullanan bir uygulama denemez, oldukça iddiasızdır. Ve zor koşullarda işlemci, uygulamanın verilerini hesaplamak yerine, ek girdi/çıktı işlemleri vb. genel giderlerin karşılanması yükünü üstlenir.
sonuçlar
Peki 1C neden yavaş? Her şeyden önce, bu 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 anlatılan durumu elde ederiz - "iki" iyi çalıştı, ancak "üç" çok yavaş.
İkinci sırada ise ağ performansı gelir; 100 Mbit/s'lik yavaş bir kanal gerçek bir darboğaz haline gelebilir, ancak aynı zamanda ince istemci modu yavaş kanallarda bile oldukça rahat bir çalışma seviyesini koruyabilir.
O halde disk sürücüsüne dikkat etmelisiniz; bir SSD satın almanın iyi bir yatırım olması pek mümkün değildir, ancak sürücüyü daha modern bir sürücüyle değiştirmek iyi bir fikir olacaktır. Sabit disk nesilleri arasındaki fark aşağıdaki materyalden değerlendirilebilir: İki ucuz Western Digital Blue serisi 500 GB ve 1 TB sürücünün incelemesi.
Ve son olarak işlemci. Daha hızlı bir model elbette gereksiz olmayacaktır, ancak bu bilgisayar ağır işlemler için kullanılmadığı sürece performansını artırmanın pek bir anlamı yoktur: grup işlemleri, ağır raporlar, ay sonu kapanışı vb.
Bu materyalin "1C'nin neden yavaş olduğu" sorusunu hızlı bir şekilde anlamanıza ve bunu en etkili şekilde ve ekstra maliyet olmadan çözmenize yardımcı olacağını umuyoruz.
Kuruluşun büyümesi ve yerel bilgisayar ağındaki 1C Enterprise bilgi tabanının kullanıcı sayısının artmasıyla birlikte, bilgi tabanının ana deposu olan sunucu üzerindeki yük artar. Bu nedenle, er ya da geç şirketin yöneticisi ve BT uzmanının bir sorusu olabilir: En düşük finansal maliyetle hızlı, güvenli ve verimli bir sistem nasıl sağlanır?
Öncelikle, 1C Enterprise 8 platformunda kurumsal bir otomatik bilgisayar kompleksi düzenlemek için bir yöntem seçmeniz gerekir.1C platformu iki işletim seçeneğini destekler: dosya ve istemci-sunucu. Her iki durumda da tüm uygulama çözümleri tamamen aynı şekilde çalışır.
1C çalışmasının dosya sürümü Bir veya daha fazla kullanıcının yerel bir ağ üzerinde çalışması için tasarlanmıştır. Bu durumda, tüm bilgi tabanı verileri (yapılandırma, veritabanı, yönetim bilgileri) tek bir dosyada bulunur - 1C Enterprise 8 uygulama çözümleri için özel olarak geliştirilmiş bir dosya veritabanı.
Dosya çalışma modunun avantajları
- Az sayıda kullanıcı için idealdir (5'e kadar)
- Sistemin kurulumu ve çalıştırılması kolaydır
- Bilgi tabanıyla çalışmak için işletim sistemi ve 1C Enterprise 8 dışında ek bir yazılıma gerek yoktur.
- Bilgisayar ve yerel ağ arızalarından dolayı veri bütünlüğünün ihlal edilmesi riski azalır.
- Bilgi tabanı dosyasını kopyalayarak kolayca yedeklemeler oluşturun.
Dosya sürümünde çalışmak hem doğrudan, doğrudan veritabanı dosyasıyla hem de istemci bağlantıları HTTP veya HTTPS protokolü aracılığıyla kullanılıyorsa bir web sunucusu aracılığıyla mümkündür.
1C çalışmasının istemci-sunucu sürümü Departmanlar, çalışma grupları veya kuruluş genelinde kullanılmak üzere tasarlanmıştır. Üç seviyeli bir istemci-sunucu mimarisine dayalı olarak uygulanır:
İstemci uygulaması - 1C Kurumsal sunucu kümesi - Veritabanı sunucusu
İstemci-sunucu sürümünde, bilgi tabanı desteklenen DBMS'lerden birinde depolanır: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Veritabanı. İstemci uygulamasının ihtiyaç duyduğu şekilde 1C Enterprise sunucularından oluşan bir küme aracılığıyla erişilir.
1C Enterprise 8 sisteminde üç istemci uygulaması vardır veya müşteri(kullanıcı için çalışan bir program) çeşitli yeteneklere sahip: kalın istemci, ince istemci, web istemcisi.
Şişman müşteri uygulama kodunun geliştirilmesi, yönetimi ve yürütülmesi açısından 1C Enterprise 8'in tüm yeteneklerini gerçekleştirmenizi sağlar. Ancak İnternet üzerinden bilgi veritabanlarıyla çalışmayı desteklemez, kullanıcının bilgisayarına önceden kurulum yapılmasını gerektirir ve oldukça etkileyici bir dağıtım boyutuna sahiptir.
Kullanıcılar genellikle "1C 8.3'ün yavaş olduğundan" şikayet ediyorlar: belge formları yavaş açılıyor, belgelerin işlenmesi uzun sürüyor, program başlıyor, raporların oluşturulması uzun sürüyor vb.
Üstelik bu tür "aksaklıklar" farklı programlarda ortaya çıkabilir:
Sebepler farklı olabilir. Bu geri yüklenen belgeler değil, zayıf bir bilgisayar veya sunucu, 1C sunucusu yanlış yapılandırılmış.
Bu yazıda yavaş bir programın en basit ve en yaygın nedenlerinden birine bakmak istiyorum - . Bu talimat, kaynaklar için rekabetin olmadığı 1-2 kullanıcılı dosya veritabanlarının kullanıcıları için geçerli olacaktır.
Sistemin çalışması için istemci-sunucu seçeneklerinin daha ciddi optimizasyonuyla ilgileniyorsanız, sitenin bölümünü ziyaret edin.
1C 8.3'te zamanlanmış görevler nerede?
Programı yüklemeye zamanım olmadan, 1C'de birçok arka plan görevi tamamlandı. Bunları “Yönetim” menüsüne ve ardından “Destek ve Bakım” menüsüne giderek görüntüleyebilirsiniz:
1C'de 267 video dersini ücretsiz alın:
Tamamlanan görevlerin bulunduğu pencere şöyle görünür:
Başlatılan tüm zamanlanmış görevlerin tam listesi:
Bu görevler arasında ““, çeşitli sınıflandırıcıların yüklenmesi, program sürümünün uygunluğunu kontrol etme vb. gibi görevleri görebilirsiniz. Mesela bu görevlerin neredeyse hiçbirine ihtiyacım yok. Para birimi kayıtlarını tutmuyorum, versiyonları kendim kontrol ediyorum ve gerektiğinde sınıflandırıcıları yüklüyorum.
Buna göre gereksiz görevleri devre dışı bırakmak benim (ve çoğu durumda sizin) yararımadır.
1C 8.3'te rutin ve arka plan görevlerini devre dışı bırakma
Fotoğraf: Alena Tulyakova, haber ajansı “Clerk.Ru”
Makale, acemi 1C yöneticilerinin yaptığı ana hataları tanımlıyor ve örnek olarak Gilev testini kullanarak bunların nasıl çözüleceğini gösteriyor.
Bu makaleyi yazmanın temel amacı, henüz 1C konusunda deneyim kazanmamış yöneticiler (ve programcılar) için bariz nüansları tekrar etmekten kaçınmaktır.
İkincil hedefim, herhangi bir eksikliğim varsa Infostart'ın bunu bana en hızlı şekilde belirtmesidir.
V. Gilev'in testi zaten bir tür "fiili" standart haline geldi. Yazar web sitesinde oldukça net tavsiyeler verdi, ancak ben sadece bazı sonuçları sunacağım ve en olası hatalar hakkında yorum yapacağım. Doğal olarak ekipmanınızdaki test sonuçları farklılık gösterebilir; bu sadece ne olması gerektiği ve ne için çabalayabileceğiniz konusunda bir rehberdir. Değişikliklerin adım adım yapılması gerektiğini ve her adımdan sonra hangi sonucu verdiğini kontrol etmek gerektiğini hemen belirtmek isterim.
Infostart'ta benzer makaleler var, ilgili bölümlere bunların bağlantılarını koyacağım (bir şeyi kaçırırsam lütfen yorumlarda bana önerin, ekleyeceğim). Öyleyse 1C'nizin yavaş olduğunu varsayalım. Sorun nasıl teşhis edilir ve kimin suçlanacağı, yöneticinin mi yoksa programcının mı olduğu nasıl anlaşılır?
İlk veri:
Test edilen bilgisayar, ana kobay: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2 ile donatılmıştır. Karşılaştırma için Core i3-2100, tek iş parçacıklı testte karşılaştırılabilir sonuçlar gösteriyor. Kasıtlı olarak seçtiğim ekipman en yenisi değildi; modern ekipmanlarla sonuçlar gözle görülür derecede daha iyi.
Ayrı 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ü. (veritabanı sunucuda paylaşılan bir klasörde bulunur, istemciler ağ, CIFS/SMB protokolü aracılığıyla bağlanır). Adım adım algoritma:
0. Gilev'in test veritabanını, ana veritabanlarıyla aynı klasördeki dosya sunucusuna ekleyin. İstemci bilgisayardan bağlanıp testi çalıştırıyoruz. Sonucu hatırlıyoruz.
10 yıl önceki eski bilgisayarlar için bile (775 soketinde Pentium), 1C:Enterprise kısayoluna tıklamaktan veritabanı penceresinin görünümüne kadar geçen sürenin bir dakikadan az sürmesi gerektiği anlaşılmaktadır. (Celeron = yavaş).
Bilgisayarınız 1 GB RAM'e sahip 775 soketli bir Pentium'dan daha kötüyse, o zaman size sempati duyuyorum ve dosya sürümünde 1C 8.2 üzerinde rahat çalışma elde etmeniz sizin için zor olacak. Yükseltmeyi (tam zamanı) veya bir terminal (veya ince istemciler ve yönetilen formlar durumunda web) sunucusuna geçmeyi düşünün.
Bilgisayar daha kötü değilse, yöneticiyi tekmeleyebilirsiniz. En azından ağın, antivirüsün ve HASP koruma sürücüsünün çalışmasını kontrol edin.
Gilev'in bu aşamadaki testi 30 "papağan" veya daha fazlasını gösteriyorsa ancak 1C çalışma tabanı hala yavaş çalışıyorsa sorular programcıya yönlendirilmelidir.
1. Bir istemci bilgisayarın ne kadar "sıkıştırabileceğine" dair bir kılavuz olarak, yalnızca bu bilgisayarın ağ olmadan çalışmasını kontrol ediyoruz. Test veritabanını yerel bir bilgisayara (çok hızlı bir diske) kuruyoruz. İstemci bilgisayarda normal bir SSD yoksa bir ramdisk oluşturulur. Şimdilik en basit ve ücretsiz olanı Ramdisk kuruluşudur.
Sürüm 8.2'yi test etmek için 256 MB'lık bir ramdisk yeterlidir ve! En önemli. Bilgisayarı yeniden başlattıktan sonra, ramdisk çalışırken, üzerinde 100-200 MB boş alan olmalıdır. Buna göre ramdisk olmadan normal çalışma için 300-400 MB boş hafıza bulunmalıdır.
Sürüm 8.3'ü test etmek için 256 MB'lık bir ramdisk yeterlidir, ancak daha fazla boş RAM'e ihtiyacınız vardır.
Test yaparken işlemci yüküne bakmanız gerekir. İdeale yakın bir durumda (ramdisk), yerel dosya 1c çalışırken 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 noktaları arayın. Biraz duygusal ama genel olarak doğru, işlemcinin 1C'nin çalışması üzerindeki etkisi anlatılıyor. Referans olması açısından, yüksek frekanslı modern Core i3'lerde bile 70-80 rakamları oldukça gerçekçi.
Bu aşamada en sık yapılan hatalar.
- Yanlış yapılandırılmış antivirüs. Pek çok antivirüs var, her birinin ayarları farklı, sadece doğru konfigürasyonla ne web ne de Kaspersky 1C'nin müdahale etmediğini söyleyeceğim. Varsayılan ayarlarla yaklaşık 3-5 papağan (%10-15) alınabilmektedir.
- Performans modu. Bazı nedenlerden dolayı, çok az kişi buna dikkat ediyor, ancak etki en önemli olanıdır. Hıza ihtiyacınız varsa, bunu hem istemci hem de sunucu bilgisayarlarda yapmanız gerekir. (Gilev'in iyi bir açıklaması var. Tek uyarı, bazı anakartlarda Intel SpeedStep'i kapatırsanız TurboBoost'u açamayacağınızdır).
Performans modunu iki yerden etkinleştirebilirsiniz (ve tercihen):
- BIOS aracılığıyla. C1, C1E, Intel C-state (C2, C3, C4) modlarını devre dışı bırakın. Farklı bios'larda farklı şekilde adlandırılırlar ancak anlamları aynıdır. Aramak uzun zaman alıyor, yeniden başlatma gerekiyor, ancak bunu bir kez yaparsanız unutabilirsiniz. BIOS'ta her şeyi doğru yaparsanız hız artacaktır. Bazı anakartlarda BIOS ayarlarını, Windows performans modunun bir rol oynamaması için yapılandırabilirsiniz. (Gilev'den BIOS ayarlarına örnekler). Bu ayarlar esas olarak sunucu işlemcileri veya "gelişmiş" BIOS'larla ilgilidir, eğer bunu bulamadıysanız ve Xeon'unuz YOKSA sorun değil.
- Kontrol paneli - Güç kaynağı - Yüksek performans. Eksi - Bilgisayara uzun süre bakım yapılmadıysa, fan sesi daha yüksek olacak, daha fazla ısınacak ve daha fazla enerji tüketecektir. Bu bir performans ücretidir.
| Bunlar varsayılan ayarlardır. BIOS C durumu etkin, dengeli güç tüketimi modu |  |
| BIOS C durumu etkin, yüksek performans modu Pentium ve Core için burada durabilirsiniz, Hala Xeon'dan biraz "papağan" çıkarabilirsiniz |  |
| BIOS'ta C durumu devre dışı, yüksek performans modu. Turbo güçlendirmeyi kullanmazsanız, böyle görünmesi gerekir performans için ayarlanmış sunucu |  |
Ve şimdi sayılar. Hatırlatayım: Intel Xeon 5650, ramdisk. İlk durumda test 23.26'yı, son durumda ise 49.5'i gösteriyor. Fark neredeyse iki kat. Sayılar değişebilir ancak oran Intel Core için esasen aynı kalır.
Sayın yöneticiler 1C'yi dilediğiniz kadar eleştirebilirsiniz ancak son kullanıcıların hıza ihtiyacı varsa yüksek performans modunu etkinleştirmeniz gerekmektedir.
c) Turbo Boost. Öncelikle işlemcinizin bu işlevi destekleyip desteklemediğini anlamanız gerekir. Destekliyorsa, yasal olarak hala bir miktar performans elde edebilirsiniz. (Frekans hız aşırtması konularına, özellikle de sunuculara değinmek istemiyorum, bunu kendi sorumluluğunuzda ve risk altında yapın. Ancak Bus hızını 133'ten 166'ya çıkarmanın hem hızda hem de ısı dağılımında çok gözle görülür bir artış sağladığına katılıyorum)
Turbo güçlendirmenin nasıl açılacağı yazılmıştır, örneğin . Ancak! 1C için bazı nüanslar vardır (en belirgin olanı değil). Zorluk, turbo güçlendirmenin maksimum etkisinin C durumu açıldığında ortaya çıkmasıdır. Ve şöyle bir şey elde ediyoruz:
Lütfen çarpanın maksimum olduğunu, Çekirdek hızının güzel olduğunu ve performansın yüksek olduğunu unutmayın. Peki 1'lerin sonucunda ne olacak?
Ancak sonuçta CPU performans testlerine göre çarpanı 23 olan sürümün önde olduğu, Gilev'in dosya sürümündeki testlerine göre ise 22 ve 23 çarpanı olan performansın aynı olduğu ancak istemci-sunucuda ortaya çıktığı ortaya çıktı. sürüm - çarpanı 23 olan sürüm çok berbat berbat (C -state 7'ye ayarlansa bile, C-state'in kapalı olmasına göre hala daha yavaştır). Bu nedenle tavsiyemiz her iki seçeneği de kendiniz kontrol etmeniz ve en iyisini seçmenizdir. Her durumda, 49,5 ile 53 papağan arasındaki fark, özellikle fazla çaba harcamadan oldukça önemlidir.
Sonuç - turbo takviyesinin açılması gerekiyor. BIOS'ta Turbo boost öğesini etkinleştirmek yeterli olmadığını, diğer ayarlara da bakmanız gerektiğini hatırlatayım (BIOS: QPI L0s, L1 - devre dışı bırak, talep temizleme - devre dışı bırak, Intel SpeedStep - etkinleştir, Turbo artır - Denetim Masası - Güç Seçenekleri - Yüksek Performans) . Ve ben yine de (dosya sürümü için bile) çarpan daha küçük olsa bile c-durumunun kapalı olduğu seçeneği seçerdim. Şöyle bir şey ortaya çıkacak...
Oldukça tartışmalı bir nokta hafıza frekansıdır. Örneğin, hafıza frekansının çok güçlü bir etkiye sahip olduğu gösterilmiştir. 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ı, ancak BIOS'ta daha düşük frekanslar ayarlamak zorunda kalıyoruz.
 |  |  |
Ve test sonuçları. 1C 8.2.19.83, yerel ramdisk dosya sürümü için, istemci-sunucu 1C ve bir bilgisayarda SQL için, Paylaşılan bellek. Turbo güçlendirme her iki versiyonda da devre dışıdır. 8.3 karşılaştırılabilir sonuçları göstermektedir.
Fark ölçüm hatası dahilindedir. Frekanstaki bir değişiklikle diğer parametrelerin de değiştiğini, aynı CAS Gecikmesinin ve RAS'tan CAS Gecikmesine, frekanstaki değişikliği nötralize ettiğini göstermek için özellikle CPU-Z'nin ekran görüntülerini çıkardım. Fark, bellek modülleri fiziksel olarak yavaştan hızlıya doğru değiştiğinde ortaya çıkacak, ancak orada bile rakamlar özellikle önemli değil.
2. İstemci bilgisayarın işlemcisini ve belleğini çözdüğümüzde, bir sonraki çok önemli yere, yani ağa geçiyoruz. Ağ ayarlama hakkında birçok cilt kitap yazıldı, Infostart (ve diğerleri) hakkında makaleler var, ancak burada bu konuya odaklanmayacağım. 1C'yi test etmeye başlamadan önce, lütfen iki bilgisayar arasındaki iperf'in tüm bant genişliğini gösterdiğinden emin olun (1 Gbit kartlar için - en az 850 Mbit veya daha iyisi 950-980), Gilev'in tavsiyesine uyulur. O zaman - en basit çalışma testi, garip bir şekilde, büyük bir dosyayı (5-10 gigabayt) ağ üzerinden kopyalamak olacaktır. 1 Gbit ağda normal çalışmanın dolaylı bir işareti, ortalama 100 MB/sn kopyalama hızı, iyi çalışma - 120 MB/sn olacaktır. Zayıf noktanın (dahil) işlemci yükü olabileceğine dikkatinizi çekmek isterim. Linux'taki SMB protokolü oldukça zayıf bir şekilde paralelleştirilmiştir ve çalışma sırasında bir işlemci çekirdeğini oldukça kolay bir şekilde "tüketebilir" ve artık tüketmeyebilir.
Ve ilerisi. Varsayılan ayarlarla, Windows istemcisi bir Windows sunucusuyla (veya hatta bir Windows iş istasyonuyla) ve SMB/CIFS protokolüyle en iyi şekilde çalışır; bir linux istemcisi (debian, ubuntu diğerlerine bakmadı) linux ve NFS ile daha iyi çalışır ( aynı zamanda SMB ile de çalışır, ancak NFS'de papağanlar daha uzundur). Bir Windows Linux sunucusunun NFS'ye doğrusal kopyalanması sırasında tek bir akışa daha hızlı kopyalanması hiçbir şey ifade etmez. 1C için Debian ayarı ayrı bir makalenin konusu, henüz buna hazır değilim, ancak dosya sürümünde aynı ekipmandaki Win sürümünden biraz daha iyi performans elde ettiğimi söyleyebilirim, ancak postgres ile üzerinde 50 kullanıcı hala her şeyim çok kötü.
"Yanmış" yöneticilerin bildiği, ancak yeni başlayanların hesaba katmadığı en önemli şey. 1c veritabanının yolunu ayarlamanın 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 yarayacaktır, ancak her zaman değil) ve ardından Z sürücüsünü belirtebilirsiniz. Görünüşe göre tüm bu yollar aynı şeyi aynı yere işaret edin, ancak 1C için normal performansı oldukça güvenilir bir şekilde sağlayan tek bir yöntem vardır. Yani, doğru bir şekilde yapmanız gereken şey budur:
Komut satırında (veya politikalarda veya sizin için uygun olan herhangi bir şeyde) - net olarak DriveLetter: Servershare'i kullanın. Örnek: net use m: sunucu tabanları. Özellikle IP adresini DEĞİL, sunucu adını vurguluyorum. Sunucu adı görünmüyorsa, onu sunucudaki DNS'ye veya yerel olarak hosts dosyasına ekleyin. Ancak adresin isme göre olması gerekir. Buna göre, veritabanına giderken bu diske erişin (resme bakın).
Şimdi bunun neden tavsiye olduğunu rakamlarla göstereceğim. Başlangıç verileri: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kartları. İşletim Sistemi Win 2008 R2, Win 7, Debian 8. En son sürücüler, güncellemeler uygulandı. Testten önce Iperf'in tam bant genişliği sağladığından emin oldum (10 Gbit kartlar hariç, yalnızca 7,2 Gbit'i sıkıştırmayı başardı, neden daha sonra test sunucusunun henüz düzgün yapılandırılmadığını göreceğim). Diskler farklı, ancak her yerde bir SSD (test için özel olarak tek bir disk yerleştirdim, başka hiçbir şey yüklü değil) veya bir SSD'den baskın var. Intel 362 adaptörünün ayarları sınırlandırılarak 100 Mbit hız 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 güçlendirme kapatılır (sadece sonuçların karşılaştırılabilirliği açısından, iyi sonuçlar için turbo güçlendirme %10'dan biraz daha az ekler, kötü sonuçlar için ise hiç etkisi olmayabilir). Sürümler 1C 8.2.19.86, 8.3.6.2076. Tüm sayıları vermiyorum, sadece en ilginç olanları veriyorum, böylece karşılaştırabileceğiniz bir şey olsun.
| 100 Mbit CIFS 2008'i Kazanın - 2008'i Kazanın ip adresiyle iletişim | 100 Mbit CIFS 2008'i Kazanın - 2008'i Kazanın ismiyle çağırmak | 1 Gbit CIFS 2008'i Kazanın - 2008'i Kazanın ip adresiyle iletişim | 1 Gbit CIFS 2008'i Kazanın - 2008'i Kazanın ismiyle çağırmak | 1 Gbit CIFS 2008'i Kazanın - 7'yi Kazanın ismiyle çağırmak | 1 Gbit CIFS 2008'i Kazanın - Debian ismiyle çağırmak | 10 Gbit CIFS 2008'i Kazanın - 2008'i Kazanın ip adresiyle iletişim | 10 Gbit CIFS 2008'i Kazanın - 2008'i Kazanın ismiyle çağırmak |
|
| 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 |
Sonuçlar (tablodan ve kişisel deneyimlerden. Yalnızca dosya sürümü için geçerlidir):
- Bu ağ doğru şekilde yapılandırılmışsa ve yol 1C'de doğru girilmişse, ağ üzerinden iş için oldukça normal sayılar alabilirsiniz. İlk Core i3 bile rahatlıkla 40'tan fazla papağan üretebiliyor ki bu oldukça iyi ve bunlar sadece papağan değil, gerçek işte fark da 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 sırasında engelleme (Gilev).
- 1C 8.3 platformu, uygun ağ yapılandırması açısından birçok kez daha talepkardır. Temel ayarlar - Gilev'e bakın, ancak her şeyin etkilenebileceğini unutmayın. Antivirüsün kaldırılmasında (ve yalnızca kapatılmasında değil), FCoE gibi protokollerin kaldırılmasında, sürücülerin daha eski ancak Microsoft sertifikalı bir sürüme değiştirilmesinde (özellikle ASUS ve DLC gibi ucuz kartlar için), ikinci ağ kartının çıkarılmasında bir hızlanma gördüm. sunucudan. Çok fazla seçenek var, ağınızı dikkatli bir şekilde kurun. 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. Platformun 8.3 sürümüyle oynamayı deneyin, bazen çok büyük bir etki elde edersiniz.
- 1C 8.3.6.2076'nın (belki daha sonra, tam sürümü henüz aramadım) ağ üzerinden yapılandırılması 8.3.7.2008'den daha kolaydır. 8.3.7.2008 tarihinden itibaren ağ üzerinden normal çalışmayı (karşılaştırılabilir papağanlarda) yalnızca birkaç kez başarabildim; daha genel bir durum için bunu tekrarlayamadım. Pek bir şey anlamadım ama Process Explorer'ın ayak sargılarına bakılırsa oradaki kayıt 8.3.6'daki kadar iyi değil.
- 100 Mbit ağ üzerinde ç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 Gbit'ten çok daha düşük. Bunun nedeni ağ gecikmesidir.
- 1C 8.2 için diğer tüm koşullar eşit olduğunda (iyi işleyen bir 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, paranız varsa Intel ağ kartlarını her yerde tutmak daha iyidir; paranız yoksa Intel'i yalnızca sunucuya (CO'nuz) yükleyin. Ve Intel ağ kartlarını ayarlamak için çok daha fazla talimat var.
- Varsayılan antivirüs ayarları (örnek olarak drweb sürüm 10'u kullanarak) papağanların yaklaşık %8-10'unu kaplar. Olması gerektiği gibi yapılandırırsanız (güvenli olmasa da 1cv8 işleminin her şeyi yapmasına izin verin), hız antivirüs olmadan aynı olur.
- Linux gurularını OKUMAYIN. Sambalı bir sunucu harika ve ücretsizdir, ancak sunucuya Win XP veya Win7 (veya daha iyisi - sunucu işletim sistemi) yüklerseniz, 1c'nin dosya sürümü daha hızlı çalışacaktır. Evet, samba, protokol yığını ve ağ ayarları ve çok daha fazlası debian/ubuntu'da iyi bir şekilde ayarlanabilir, ancak bu uzmanlar için önerilir. Linux'u varsayılan ayarlarla kurup sonra yavaş olduğunu söylemenin bir anlamı yok.
- Net use aracılığıyla bağlanan disklerin çalışmasını fio kullanarak kontrol etmek oldukça iyi bir fikirdir. En azından bunların 1C platformunda mı yoksa ağ/diskte mi sorun olduğu açık olacaktır.
- Tek kullanıcılı sürüm için 1 Gbit ile 10 Gbit arasındaki farkın görülebileceği testler (veya bir durum) aklıma gelmiyor. Dosya sürümü için 10 Gbit'in daha iyi sonuçlar verdiği tek şey diskleri iSCSI aracılığıyla bağlamaktır, ancak bu ayrı bir makalenin konusu. Yine de dosya versiyonu için 1 Gbit kartların yeterli olduğunu düşünüyorum.
- 100 Mbit ağda 8.3'ün neden 8.2'den belirgin şekilde daha hızlı çalıştığını anlamıyorum, ama bu bir gerçekti. Diğer tüm ekipmanlar, diğer tüm ayarlar kesinlikle aynıdır, sadece bir durumda 8.2 test edilirken diğerinde - 8.3.
- Ayarlanmamış NFS kazan-kazan veya kazan-lin 6 papağan veriyor, onları tabloya dahil etmedim. Ayarlamadan sonra 25 aldım ama kararsızdı (ölçümlerdeki fark 2 birimden fazlaydı). Henüz Windows ve NFS protokolünün kullanımına ilişkin önerilerde bulunamıyorum.
Terminal sunucusu. (veritabanı sunucudadır, istemciler ağ üzerinden bağlanır, RDP protokolü). Adım adım algoritma:
- Gilev’in test veritabanını sunucuya ana veritabanlarıyla aynı klasöre ekliyoruz. Aynı sunucudan bağlanıp testi çalıştırıyoruz. Sonucu hatırlıyoruz.
- İşlemciyi dosya sürümündekiyle tamamen aynı şekilde yapılandırıyoruz. Terminal sunucusu durumunda, işlemci genellikle ana rolü oynar (bellek eksikliği veya çok miktarda gereksiz yazılım gibi belirgin zayıf noktaların olmadığı varsayılır).
- Bir terminal sunucusu durumunda ağ kartlarını yapılandırmanın 1c'nin çalışması üzerinde neredeyse hiçbir etkisi yoktur. "Özel" konforu sağlamak için, sunucunuz 50'den fazla papağan üretiyorsa, 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ı aktif olarak çalışırken (ve burada 30 kişiyi tek bir veritabanına bağlamayı deneyebilirsiniz, eğer denerseniz), bir SSD sürücüsü kurmanız çok tavsiye edilir. Bazı nedenlerden dolayı, diskin 1C'nin çalışmasını özellikle etkilemediğine inanılıyor, ancak tüm testler denetleyici önbelleği yazma için etkinken yapılıyor ki bu yanlış. Test tabanı küçük, önbelleğe oldukça iyi uyuyor, dolayısıyla sayılar yüksek. Gerçek (büyük) veritabanlarında her şey tamamen farklı olacaktır, bu nedenle önbellek testler için devre dışı bırakılır.
| 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 | |
| 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 |
- Etkinleştirilmiş RAID denetleyici önbelleği, diskler arasındaki tüm farklılıkları ortadan kaldırır; sayılar hem sat hem de cas için aynıdır. Bununla az miktarda veri üzerinde test yapmak işe yaramaz ve herhangi bir gösterge değildir.
- Platform 8.2 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 “Aktif disk çalışma süresi (% olarak)” 80-95'i açıkça görebilirsiniz. Evet, kayıt için disklerin önbelleğini etkinleştirirseniz, baskın denetleyicinin önbelleğini etkinleştirirseniz hız 35'e yükselecektir - 49'a kadar (şu anda hangi disklerin test edildiğine bakılmaksızın). Ancak bunlar sentetik önbellek papağanlarıdır; büyük veritabanlarıyla yapılan gerçek çalışmada, yazma önbelleği isabet oranı hiçbir zaman %100 olmayacaktır.
- Ucuz SSD'lerin bile hızı (Agility 3'te test ettim) dosya sürümünü çalıştırmak için oldukça yeterli. Kayıt kaynağı başka bir konudur, ona her özel durumda bakmanız gerekir, Intel 3700'ün çok daha yüksek bir sıraya sahip olacağı açıktır, ancak fiyat buna karşılık gelir. Ve evet, bir SSD diski test ederken bu diskin önbelleğini de daha büyük ölçüde test ettiğimi anlıyorum, gerçek sonuçlar daha az olacak.
- En doğru (benim bakış açıma göre) çözüm, bir dosya veritabanı (veya birkaç dosya veritabanı) için yansıtılmış bir baskında 2 SSD diski tahsis etmek ve oraya başka hiçbir şey yerleştirmemek olacaktır. Evet, aynayla SSD'ler eşit şekilde aşınır ve bu bir eksi, ancak en azından denetleyici elektroniği bir şekilde hatalardan korunuyor.
- Dosya sürümü için SSD sürücülerin ana avantajları, her biri birkaç kullanıcıya sahip çok sayıda veritabanı olduğunda ortaya çıkacaktır. 1-2 veritabanı varsa ve yaklaşık 10 kullanıcı varsa SAS diskleri yeterli olacaktır. (ancak her durumda, bu diskleri en azından perfmon aracılığıyla yüklemeye bakın).
- Terminal sunucusunun temel avantajları, çok zayıf istemcilere sahip olabilmesi ve ağ ayarlarının terminal sunucusunu (yine K.O.'nuz) çok daha az etkilemesidir.
Gilev'in testi küçük sayılar gösteriyorsa ve yüksek saat hızına sahip bir işlemciniz ve hızlı diskleriniz varsa, o zaman yöneticinin en azından perfmon alması, tüm sonuçları bir yere kaydetmesi ve izlemesi, gözlemlemesi ve sonuçlar çıkarması gerekir. Kesin bir tavsiye olmayacak.
İstemci-sunucu seçeneği.
Testler yalnızca 8.2'de yapıldı çünkü 8.3'te her şey oldukça ciddi bir şekilde sürüme bağlı.
Test için ana eğilimleri göstermek amacıyla 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 | |
| 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 |
Görünüşe göre tüm ilginç seçenekleri değerlendirdim, ilgilendiğiniz başka bir şey varsa yorumlara yazın, yapmaya çalışacağım.
- Depolama sistemlerindeki SAS, depolama sistemlerinin önbellek boyutları daha büyük olmasına rağmen yerel SSD'lerden daha yavaştır. Gilev'in testi için hem yerel hem de depolama sistemlerindeki SSD'ler benzer hızlarda çalışıyor. MCC'nin 1C yük testi dışında herhangi bir standart çok iş parçacıklı testi (sadece kayıt değil, tüm ekipmanlar) bilmiyorum.
- 1C sunucusunu 5520'den 5650'ye değiştirmek performansı neredeyse iki katına çıkardı. Evet, sunucu konfigürasyonları tam olarak eşleşmiyor ancak bir eğilim gösteriyor (sürpriz değil).
- SQL sunucusundaki frekansın arttırılması kesinlikle bir etki yaratır, ancak 1C sunucusundakiyle aynı değildir; MS SQL sunucusu (eğer sorarsanız) çok çekirdekli ve boş hafıza kullanmak için mükemmeldir.
- 1C ile SQL arasındaki ağı 1 Gbit'ten 10 Gbit'e değiştirmek yaklaşık %10 papağan verir. Daha fazlasını bekliyordum.
- Paylaşılan belleğin etkinleştirilmesi, makalede anlatıldığı gibi %15 olmasa da yine de bir etki sağlar. Bunu yaptığınızdan emin olun, neyse ki hızlı ve kolaydır. Kurulum sırasında birisi SQL sunucusuna adlandırılmış bir örnek verdiyse, 1C'nin çalışması için sunucu adının FQDN tarafından değil (tcp/ip çalışacaktır), localhost veya yalnızca SunucuAdı aracılığıyla değil, SunucuAdıInstanceName aracılığıyla belirtilmesi gerekir, örneğin zz- testzztest. (Aksi takdirde DBMS hatası oluşacaktır: Microsoft SQL Server Native Client 10.0: Paylaşılan Bellek Sağlayıcısı: SQL Server 2000 ile bağlantı kurmak 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).
- Sayısı 100'ün altında olan kullanıcılar için, onu iki ayrı sunucuya bölmenin tek amacı, yalnızca 32 GB RAM'i destekleyen bir Win 2008 Std (ve daha eski) lisansıdır. Diğer tüm durumlarda, 1C ve SQL'in kesinlikle bir sunucuya kurulması ve daha fazla (en az 64 GB) bellek verilmesi gerekir. MS SQL'e 24-28 GB'tan daha az RAM vermek haksız 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'nin dosya sürümü sizin için yeterli olabilir?)
- 1C ve SQL kombinasyonunun sanal bir makinede ne kadar kötü çalıştığı ayrı bir makalenin konusudur (ipucu - belirgin şekilde daha kötü). Hyper-V'de bile her şey o kadar net değil...
- Dengeli performans modu kötü. Sonuçlar dosya sürümüyle oldukça tutarlıdır.
- Birçok kaynak, hata ayıklama modunun (ragent.exe -debug) performansta önemli bir düşüşe neden olduğunu söylüyor. Evet, azalır ama %2-3'ü önemli bir etki olarak adlandıramam.