Otomasyon İpuçları. 1'leri otomatikleştirmek için ipuçları 8 yavaş

Bu makale ana faktörleri tartışmaktadır: 1C yavaşladığında, 1C donar ve 1C yavaş çalışır. Veriler, SoftPoint'in 1C + MS SQL kombinasyonu üzerine kurulu büyük BT sistemlerini optimize etme konusundaki uzun yıllara dayanan deneyimine dayanarak hazırlanmıştır.

Başlangıç ​​\u200b\u200bolarak, 1C'nin çok sayıda kullanıcının eşzamanlı çalışması için tasarlanmadığı, bu gönderilerde her şeyi olduğu gibi bırakmak için rahatlık ve sebep bulan forum kullanıcıları tarafından aktif olarak desteklendiği efsanesini belirtmekte fayda var. Yeterli sabır ve bilgi düzeyi ile sistemi istediğiniz sayıda kullanıcıya ulaştırabilirsiniz. Yavaş çalışma ve 1C'nin donması artık sorun olmayacak.

Uygulamadan: 1C v7.7'yi optimize etmek en kolayıdır (Uygulama 3 bağlantıdan oluştuğu için 1C 8.1, 1C 8.2, 1C 8.3 optimizasyonu daha zor bir iştir). 400'e kadar eşzamanlı kullanıcıya ulaşmak oldukça tipik bir projedir. 1500'e kadar zaten zor, sıkı çalışma gerektiriyor.

İkinci efsane: 1C'nin performansını artırmak ve 1C donmalarından kurtulmak için daha güçlü bir sunucu kurmanız gerekir. Kural olarak, optimizasyon projelerinde, vakaların% 95'inde, ya hiç yükseltme yapmadan ya da örneğin RAM ekleyerek ekipmanın önemsiz bir bölümünü güncelleyerek kabul edilebilir performans elde etmek mümkündür. Aynı zamanda, ekipmanın, özellikle disk alt sisteminin hala sunucu tabanlı olması gerektiğine dikkat edilmelidir. Eski bir disk alt sistemi, 1C'nin yavaş olmasının nedenlerinden sadece biridir.

1C'de çok kullanıcılı çalışmadaki ana sınırlama, engelleme mekanizmasıdır. Genellikle çok sayıda insanın veritabanında çalışmasını engelleyen sunucu ekipmanı değil, 1C'deki kilitlerdir. Bu sorunun üstesinden gelmek için, çok çalışmanız ve 1C'deki kilitlerin mantığını değiştirmeniz gerekir - onları tablodan satır satıra indirin. Ardından, örneğin, bir belgeyi tutmak, sistemdeki tüm belgeleri değil, yalnızca birini engeller.

Şekil 1. PerfExpert izleme sistemindeki 1C engelleme kuyruğu, 1C kullanıcıları hakkında bilgiler, bir yapılandırma modülü ve bu modülde belirli bir kod satırı.

1C kilit mekanizmasını değiştirmek çok karmaşık bir teknolojidir. Herkes böyle bir numara yapamaz ve onlar için tek bir yol kalır - yapıyı optimize etmek ve operasyonların yürütme süresini hızlandırmak. Gerçek şu ki, 1C'de engelleme ve işlemleri tamamlamak için geçen süre birbiriyle oldukça ilişkili göstergelerdir. Örneğin, belge gönderme işlemi 15 saniye sürerse, o zaman çok sayıda kullanıcıyla, gönderme sırasında başka birinin belgeyi göndermeye çalışması ve kilitte beklemesi büyük olasılıktır. Yürütme süresini en az 1 saniyeye getirirseniz, bu işlem için 1C engelleme önemli ölçüde azaltılacaktır.

Engelleme açısından daha tehlikeli olan, yürütme süresi uzun olabilen ve aynı zamanda 1C engellemesine neden olabilen grup işlemedir. Belgelerin yeniden sıralanması veya toplu işlenmesi gibi verileri değiştiren herhangi bir işlem, tabloları kilitler ve diğer kullanıcıların belgeleri göndermesini engeller. Doğal olarak bu işlemler ne kadar hızlı yapılırsa engelleme süresi o kadar kısalır ve kullanıcıların çalışması o kadar kolay olur.

Yalnızca okuma işlemleri gerçekleştiren ağır raporlar, verileri kilitliyor gibi görünse de kilitler açısından da tehlikeli olabilir. Bu tür raporlar, 1C'deki engelleme yoğunluğunu etkileyerek sistemdeki diğer işlemleri yavaşlatır. Yani, rapor çok ağırsa ve sunucu kaynaklarının büyük bir kısmını kaplıyorsa, rapor başlatılmadan önce aynı yürütmelerin 1 saniye ve raporun yürütülmesi sırasında 15 saniye gerçekleştirildiği ortaya çıkabilir. Doğal olarak, işlemlerin yürütme süresi arttıkça engelleme yoğunluğu da artacaktır.

Şekil 2. Tüm kullanıcılardan yapılandırma modülleri bağlamında çalışan sunucuya yükleyin. Her modülün kendi rengi vardır. 1C'den oluşan yükte bariz bir dengesizlik var.

Optimize ederken ana kural, belgenin süresinin minimum zaman alması ve yalnızca gerekli işlemleri gerçekleştirmesidir. Örneğin, kayıt hesaplamaları genellikle filtreleme koşullarını belirtmeden kayıt işlemede kullanılır. Bu durumda, filtreleme koşullarına göre kaydın karşılık gelen indekslere sahip olması gerektiğini unutmadan, kayıtlar için en iyi seçiciliği elde etmenize izin veren filtreler belirtmeniz gerekir.

Ağır raporların çalıştırılmasına ek olarak, MS SQL ve MS Windows'un optimal olmayan ayarları, işlemlerin yürütme süresini yavaşlatabilir ve bu nedenle 1C engellemenin yoğunluğunu artırabilir. Bu sorun müşterilerin %95'inde bulunur. Bunların ciddi kuruluşların sunucuları olduğu ve yüksek nitelikli yöneticilerin tüm departmanlarının destek ve yapılandırmalarına dahil olduğu unutulmamalıdır.

Sunucunun düzgün yapılandırılmamasının ana nedeni, yöneticilerin çalışan bir sunucudaki herhangi bir şeyi değiştirme korkusu ve "En iyi, iyinin düşmanıdır" kuralıdır. Yönetici sunucu ayarlarını değiştirirse ve sorunlar başlarsa, yetkililerin tüm öfkesi ihmalkar yöneticiye dökülecektir. Bu nedenle, kendi sorumluluğu altında deney yapmaktansa, her şeyi olduğu gibi bırakmak ve üstlerinin emri olmadan tek bir adım atmamak onun için daha karlı.

İkinci neden, ağ optimizasyon sorunları hakkında net bilgi eksikliğidir. Genellikle birbiriyle tamamen çelişen birçok görüş vardır. Optimizasyona adanmış her görüşün, onu savunacak rakipleri ve fanatikleri vardır. Sonuç olarak, internet ve forumlar yardım etmekten çok sunucu ayarlarını karıştırır. Böyle bir belirsizlik durumunda, yönetici en azından bir şekilde işe yarayan sunucuda bir şeyi değiştirmek için daha az istek duyar.

İlk bakışta resim net - 1C sunucusunu yavaşlatan her şeyi optimize etmeniz gerekiyor. Ancak kendimizi böyle bir optimize edicinin yerinde hayal edelim - diyelim ki 1C 8.1 8.2 8.3 SCP'miz var ve aynı anda 50 kullanıcı çalışıyor. Korkunç bir gün, kullanıcılar 1C'nin yavaş olduğundan şikayet etmeye başlar ve bu sorunu çözmemiz gerekir.

Her şeyden önce, sunucuda neler olup bittiğine bakıyoruz - birdenbire tam sistem taraması yapan bir tür bağımsız antivirüs var. İnceleme, her şeyin yolunda olduğunu gösteriyor - sunucu %100'ün altında ve yalnızca sqlservr işlemi tarafından yüklendi.

Uygulamadan: genç yöneticilerden biri kendi inisiyatifiyle sunucuda otomatik güncellemeyi açtı, Windows ve SQL mutlu bir şekilde güncellendi ve güncellemeden sonra 1C kullanıcılarının çalışmalarında büyük bir yavaşlama başladı veya 1C basitçe donuyor .

Bir sonraki adım, hangi programların MS SQL yüklediğini kontrol etmektir. İnceleme, yükün yaklaşık 20 uygulama sunucusu bağlantısından üretildiğini gösteriyor.

Uygulamadan: sitedeki verileri hızlı bir şekilde güncelleyen program takıldı ve her 4 saatte bir güncelleme yapmak yerine, bunu durmadan, duraklamadan, sunucuyu ağır bir şekilde yüklemeden ve verileri engellemeden yaptı.

Durumun daha fazla analizi büyük zorluklarla karşı karşıyadır. Yükün doğrudan 1C'den geldiğini zaten öğrendik, ancak kullanıcıların tam olarak ne yaptığını nasıl anlayabiliriz? Ya da en azından kim olduklarını. Pekala, kuruluşta 10 1C kullanıcısı varsa, o zaman bunların arasından geçip şu anda ne yaptıklarını öğrenebilirsiniz, ancak bizim durumumuzda elli kişi var ve birkaç binaya dağılmış durumdalar.

İncelediğimiz örnekte durum henüz karmaşık değil. Ve yavaşlamanın bugün değil dün olduğunu hayal edin. Bugün durum kendini tekrar etmiyor, her şey yolunda, ancak operatörlerin dün neden çalışamadığını anlamanız gerekiyor (doğal olarak sadece evden çıkmadan önce şikayet ettiler, çünkü bütün gün sohbet etmeyi seviyorlar, çünkü hiçbir şey çalışmıyor, bundan hoşlanıyorlar. çalışmaktan daha fazlası). Bu durum, her zaman sunucunun ana parametrelerinin geçmişini tutacak ve olaylar dizisinin geri yüklenebileceği bir sunucu kayıt sistemine olan ihtiyacı vurgulamaktadır.

Kayıt sistemi, sistem optimizasyonunda vazgeçilmez bir araçtır. Mevcut durumu çevrimiçi olarak görüntüleme yeteneğini eklerseniz, sunucunun durumunu izlemek için bir sistem elde edersiniz. Her optimizasyon projesi, darboğazları belirlemek için sunucu durumu istatistiklerinin toplanmasıyla başlar.

Optimizasyon alanında çalışmaya başladığımızda birçok sunucu izleme sistemi denedik, maalesef bu sorunu uygun seviyede çözen bir şey bulamadık, bu yüzden kendi başımıza bir sistem oluşturmak zorunda kaldık. Sonuç, BT sistemlerini optimize etme süreçlerini otomatikleştirmeyi ve kolaylaştırmayı mümkün kılan benzersiz bir ürün olan PerfExpert oldu. Program, 1C ile sıkı entegrasyon, gözle görülür herhangi bir ek yükün olmaması ve savaş durumlarında pratik kullanım için defalarca kanıtlanmış uygunluğu ile ayırt edilir.

Örneğimize dönersek, en olası sonuç şudur: Yönetici "Yapılandırmayı yazan programcılar suçludur" der, programcılar - "Her şeyi iyi yazdık - sunucu iyi çalışmıyor" diye yanıt verir. Ve dedikleri gibi, araba hala orada. Sonuç olarak, 1C yavaşlar, donar veya yavaş çalışır.

Her durumda, 1C performans sorunlarını çözmek için önce performans izlemeyi satın almanızı ve kullanmanızı öneririz. Mükemmel Uzman , bu, doğru yönetim kararını vermenize ve paradan tasarruf etmenize olanak tanır. Ürün, hem küçük IS 1C:Enterprise - 50 kullanıcıya kadar hem de 1000 kullanıcılı sistemler için uygundur. Temmuz 2015'ten itibaren performans izleme Mükemmel Uzman 1C sertifikası aldı: Uyumlu, test edildi Microsoft ve yalnızca 1C sistemleri için değil, aynı zamanda diğer bilgi sistemleri için de performans sorunlarını çözmeye yardımcı olur. MS SQL Server (Axapta, CRM Dynamics, Doc Vision ve diğerleri).

Bilgileri beğendiyseniz, önerilen sonraki adımlar şunlardır:

- 1C'nin teknik performans problemleriyle bağımsız olarak ilgilenmek istiyorsanız (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) ve diğer bilgi sistemleri, o zaman sizin için Almanac'ımızdaki benzersiz teknik makaleler listesi (Kilitler ve kilitlenmeler, ağır CPU ve disk yükü, veritabanı bakımı ve dizin ayarı orada bulacağınız teknik materyallerin sadece küçük bir kısmıdır).
.
- Performans sorunlarını uzmanımızla görüşmek veya bir PerfExpert performans izleme çözümü sipariş etmek istiyorsanız daha sonra bir istek bırakın ve en kısa sürede sizinle iletişime geçeceğiz.

Çeşitli nedenlerle, 1C programının kullanıcıları zaman zaman 1C performans sorunları ile karşılaşırlar. Örneğin: bir belge uzun süre işlenir, uzun süre rapor oluşturulur, işlem hataları, programın donması, kullanıcı eylemlerine yavaş yanıt verilmesi vb. Talimatlarımızı izleyerek, programın hızında önemli bir başarı elde edebilir, sistem limitinin aşılmasını önleyebilirsiniz. Bu, tüm hastalıklar için her derde deva değil, ancak 1C frenlerinin nedenlerinin çoğu tam olarak bu konularda yatmaktadır.

1. Kullanıcılar çalışırken planlanmış ve arka plan görevlerini çalıştırmayın

Sistem yöneticileri için ilk ve en önemli kural, tüm arka plan görevlerini mesai saatleri dışında çalıştırmaktır. Rutin görevleri (dizinleme, belge gönderme, veri yükleme) gerçekleştirmek ve aynı zamanda kullanıcıların işine müdahale etmemek için sistem mümkün olduğunca boşaltılmalıdır. Farklı zamanlarda çalışırlarsa ne sistem ne de kullanıcılar birbirine karışmaz.

2. Kullanıcıların iş günü boyunca RIB verilerini değiş tokuş etmeyin

Şirketler son zamanlarda çevrimiçi mod ve terminal erişimi lehine RIB veri değişim sistemini terk etmiş olsalar da, değişim verilerinin yüklenmesi ve indirilmesi sırasında programda belge yürütmenin ve işleri tamamlamanın imkansız olduğunu hatırlamak yersiz olmayacaktır. Mümkünse, varsa bu prosedür, geceleri arka plan görevleri kullanılarak gerçekleştirilmelidir.

3. PC performansını zamanında iyileştirin, gücünü gerçek ihtiyaçlarla eşleştirin

Unutmayın sistemde 30 ve 100 kullanıcının aynı anda çalışması ayrı bir yük vermektedir. Buna göre, kullanıcıların nicel büyümesi planlanıyorsa, BT hizmeti, şirket yönetimi ile makine filosunu genişletme, ek bellek veya sunucu satın alma sorununu zamanında değerlendirmelidir.

4. 1C'nin çalıştığı yazılım

1C programı, işletim sistemlerinde farklı çalışacak şekildedir. Tam olarak neden bilinmez ama öyledir. Örneğin, SQL Postgre ile birlikte Linux işletim sistemindeki 1C veritabanının sunucu sürümü, aynı 1C veritabanından çok daha yavaştır, ancak Windows işletim sisteminde MS SQL ile bağlantılıdır. Bu gerçeğin kesin nedenleri bilinmiyor, ancak görünüşe göre 1C platformunun derinliklerinde bir yerlerde işletim sistemleri ve Microsoft dışı DBMS ile uyumluluk sorunları var. Önemli veritabanı yükleri planlanıyorsa, sistemi 64 bitlik bir sunucuya dağıtmaya da değer.

5. Veritabanı indeksleme

Sistemi içeriden "taran" 1C programının dahili prosedürü. Geceleri arka planda zamanlanmış bir görev olarak çalışacak şekilde ayarlayın ve sakin olun.

6. Operasyonel toplu muhasebeyi devre dışı bırakma

Gerçek şu ki, belgelerin operasyonel olarak işlenmesi sırasında hareketler, toplu muhasebe kayıtları da dahil olmak üzere kayıtlara kaydedilir. Belgeleri gönderirken toplu muhasebe kayıtlarının kaydedilmesi program ayarlarında devre dışı bırakılabilir. Ayda bir kez, örneğin veritabanı üzerindeki yükün en az olduğu veya en az kullanıcının çalıştığı bir zamanda, toplu olarak belgelerin gönderilmesini işlemeye başlamak gerekli olacaktır.

7. Bellek

Aşağıdaki formülü kullanın:

RAM = (DB 1+DB 2+DB N) / 100 * 70

Veritabanlarının toplam fiziksel hacminin yaklaşık %70'i. 1C bazları RAM ile iyi yemek yemeyi sever. Bunu unutma.

8. Mümkünse, kendi yazdığı raporları ve işlemeyi kusurlu ve eskimiş kodlarla optimize edin

Bir şirketin yaşamı boyunca, iş süreçlerinin yönetilmesi ve belirli bilgilerin çıkarılması için iyileştirmelerin yanı sıra rapor yazma ve işleme ihtiyaçları vardır. Sadece tüm bu iyileştirmeler hatalı olabilir, işi yavaşlatabilir, çünkü. a) bazı kulibinler, program tarafından yürütülmesi zor olan ve yürütmek için büyük çaba gerektiren ağır bir yanlış kodu bir kez alt üst edebilir b) işlemenin veya raporun yazıldığı kod ahlaki açıdan geçersiz hale gelebilir ve revizyon, yeniden programlama gerektirebilir. Kuralı kullanın - Programda bir şeyi ne kadar az değiştirirsek o kadar iyi.

9. Önbelleği temizleme

Normal bir sunucu yeniden başlatması bazen eski bir 1C önbelleğiyle ilgili sorunları çözer. Sadece dene. Boşaltma da yardımcı olabilir - bilgi tabanını yapılandırıcı aracılığıyla yüklemek. Ve belirli bir kullanıcının önbelleğini son temizleme, şu formun 1C sistem dizinindeki klasörleri silmektir: kexifzghjuhfv8j33hbdgk0. Ancak kullanıcının önbelleğe alınmış klasörlerini silmek son şeydir, çünkü. çöpü kaldırmanın yanı sıra, önbelleği temizlemenin, kullanıcı menüsü arabirimi olan kaydedilen rapor ayarlarını silme şeklinde hoş olmayan sonuçları vardır.

10. Veritabanlarının fiziksel hacminin azaltılması

Daha fazla taban, daha fazla kaynak anlamına gelir. Doğal olarak. Tabanı sarmak için standart 1C araçlarını kullanın. Bir düşünün, üretkenliği artırmak için beş yıl önce birdenbire verilerden vazgeçebilirsiniz. Ve hala son beş yılın verilerine ihtiyacınız varsa, her zaman veritabanının bir kopyasını kullanabilirsiniz.

11. Mimarinin uygun organizasyonu

Genel olarak kurumsal bilgi sisteminin mimarisi doğru olmalıdır. Doğru sistem derken neyi kastediyoruz? Sisteme atanan görevlerin mevcut ekipman ve yazılımlarla karşılaştırılabilirliği. Sistemi şunlarla birlikte planlayın: sistem yöneticisi (çünkü o makine filosunu biliyor), 1C programcısı (çünkü 1C'nin kaynak ihtiyaçlarını biliyor) ve şirket başkanı (çünkü gelecekteki büyümeyi veya küçülmeyi biliyor) şirket).

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, ağ uygulamaları için en önemli parametrelerden biridir, özellikle dosya modunda 1C olarak, ağ üzerinde önemli miktarda veri taşır. Küçük işletmelerin ağlarının çoğu, ucuz 100 Mbps ekipman temelinde inşa edilmiştir, 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 bizim durumumuzda yaklaşık 40 saniye kadar önemli bir süre alabilir (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şlatmaya 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 iş 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 düzeyini 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.

Interface LLC'deki meslektaşlarımız sayesinde, özellikle 1s 8.3 sürümüne geçerken 1'leri neyin yavaşlattığına dair sık ​​sık sorular alıyoruz, ayrıntılı olarak anlatıyoruz:

Önceki yayınlarımızda, disk alt sisteminin 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 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 gerçek 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 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, 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, ağ uygulamaları için en önemli parametrelerden biridir, özellikle dosya modunda 1C olarak, ağ üzerinde önemli miktarda veri taşır. Küçük işletmelerin ağlarının çoğu, ucuz 100 Mbps ekipman temelinde inşa edilmiştir, 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 bizim durumumuzda yaklaşık 40 saniye kadar önemli bir süre alabilir (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şlatmaya 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 iş 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

Önceki makalede SSD'nin yerel olarak kurulan 1C'nin hızı üzerindeki 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, 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 düzeyini 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: İki ucuz Western Digital Blue serisi sürücüye genel bakış 500 GB ve 1 TB.

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.

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.

Bundan 10 yıl önceki eski bilgisayarlar için bile (Pentium 775 soket üzerinde) anlaşılmaktadır. ) 1C:Enterprise etiketine tıklanmasından veritabanı penceresinin görüntülenmesine kadar geçen süre bir dakikadan az olmalıdır. ( Celeron = yavaş çalışma).

Bilgisayarınız bir Pentium'dan daha kötüyse 775 soket 1 GB RAM ile, 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.

a) 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.

b) 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 dahil, dengeli güç modu
BIOS C durumu dahil, yüksek performans modu Pentium ve Core için burada durabilirsiniz, hala Xeon'dan bazı "papağanlar" çıkarabilirsiniz
BIOS C durumu 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?

	faktör	Çekirdek hızı (frekans), GHz	CPU-Z Tek İş Parçacığı	Gilev Ramdisk testi dosya sürümü	Gilev Ramdisk testi müşteri sunucusu
turbo desteği olmadan
C-durumu kapalı, turbo boost				53.19	40,32
C-durumu açık, turbo boost			1080	53,13	23,04

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. KOBİ Linux'taki 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). Bir win-linux sunucusunu doğrusal olarak nfs'ye kopyalarken 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 yöneticileri "yaktığı" bilinen, ancak yeni başlayanlar dikkate almıyor. 1c veritabanına giden yolu belirlemenin birçok yolu vardır. \\server\share yapabilirsiniz, \\192.168.0.1\share yapabilirsiniz, net use z: \\192.168.0.1\share yapabilirsiniz (ve bazı durumlarda bu yöntem de işe yarar, ancak her zaman değil) ve sonra belirtin Z sürücüsü Tüm bu yollar aynı yere işaret ediyor gibi görünüyor, 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: \\server\share yapın. Örnek: net kullanım m:\\server\bases. Özellikle bir IP adresinin DEĞİL olduğunu vurguluyorum, yani İsim sunucu. 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.

	2008 Kazan - 2008 Kazan ip adresi ile arama	2008 Kazan - 2008 Kazan Ada göre adres	2008 Kazan - 2008 Kazan ip adresi ile arama	2008 Kazan - 2008 Kazan Ada göre adres	Win 2008 - Win 7 Ada göre adres	Windows 2008 - Debian Ada göre adres	2008 Kazan - 2008 Kazan ip adresi ile arama	2008 Kazan - 2008 Kazan Ada 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.

1C 8.3 platformu, yetkin 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:

0. Gilev test veritabanını ana veritabanlarıyla aynı klasördeki sunucuya ekleyin. Aynı sunucudan bağlanıp testi çalıştırıyoruz. Sonucu hatırlıyoruz.

1. Dosya sürümünde olduğu gibi çalışmayı 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).

2. Bir terminal sunucusu durumunda ağ kartlarının ayarlanmasının 1'lerin çalışması üzerinde pratik olarak hiçbir etkisi yoktur. "Ö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.

3. Ç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 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		ö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.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiber kanal-SSD	SQL: Xeon E5-2630 Fiber kanal - SAS	SQL: Xeon E5-2630 Yerel SSD	SQL: Xeon E5-2630 Fiber kanal-SSD	SQL: Xeon E5-2630 Yerel SSD	1C: Xeon 5650 =	1C: Xeon 5650 = paylaşılan hafıza	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 Server (eğer sorarsanız) çok çekirdekli ve boş hafızayı mükemmel bir şekilde 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, 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 tarafından (tcp / ip çalışacaktır), localhost veya yalnızca SunucuAdı aracılığıyla değil, SunucuAdı\ÖrnekAdı yoluyla belirtilmesi gerekir. örnek zz-testi\zztest. (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.