internet pencereler Android

1s 8.3 dosyası için ssd disk. Gilyov - Yapılandırmayı yönetilen kilitlere aktarma

Makaleyi yazmanın asıl amacı, henüz 1C ile deneyim kazanmamış yöneticilere (ve programcılara) bariz nüansları tekrarlamamaktır.

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

V. Gilev'in testi şimdiden bir tür "fiili" standart haline geldi. Yazar, web sitesinde 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ılık gösterebilir, bu sadece bir kılavuzdur, ne olması gerektiği ve ne için çaba gösterebileceğinizdir. Değişikliklerin adım adım yapılması gerektiğini hemen belirtmek isterim ve her adımdan sonra ne sonuç verdiğini kontrol edin.

Infostart'ta buna benzer yazılar var, ilgili kısımlara linklerini koyacağım (eğer atladığım bir şey olursa lütfen yorumlarda belirtin, eklerim). Yani, 1C'yi yavaşlattığınızı varsayalım. Sorun nasıl teşhis edilir ve kimin, yöneticinin mi yoksa programcının mı suçlanacağı nasıl anlaşılır?

İlk veri:

Test edilmiş 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ı bir testteki karşılaştırılabilir sonuçlar Core i3-2100 tarafından gösterilmektedir. Ekipman en yeni değil özel olarak alındı, modern ekipmanda 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ü. (taban, paylaşılan klasördeki sunucuda bulunur, istemciler bir ağa, CIFS/SMB protokolüne bağlıdır). Adım adım algoritma:

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

10 yıl önce eski bilgisayarlar için bile (775 soketinde Pentium) olduğu anlaşılmaktadır. ) 1C:Enterprise etiketine tıklanmasından veritabanı penceresinin görünmesine 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 size sempati duyuyorum ve dosya sürümünde 1C 8.2'de rahat çalışmanız zor olacak. Yükseltmeyi (uzun süredir gecikmiş) veya bir terminale (veya ince istemciler ve yönetilen formlar durumunda web'e) geçmeyi düşünün.

Bilgisayar daha kötü değilse, yöneticiyi tekmeleyebilirsiniz. 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çin.

1. Bir istemci bilgisayarın ne kadar "sıkıştırabileceği" konusunda 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) yerleştirdik. İstemci bilgisayarda normal bir SSD yoksa, bir ramdisk oluşturulur. Şimdiye kadar, en basit ve ücretsiz olanı Ramdisk girişimidir.

8.2 sürümünü test etmek için 256 MB ramdisk yeterlidir ve! En önemli şey. Bilgisayarı çalışan bir ramdisk ile yeniden başlattıktan sonra 100-200 MB boş olması gerekir. Buna göre, bir ramdisk olmadan, boş belleğin normal çalışması için 300-400 MB olmalıdır.

8.3 sürümünü test etmek için 256 MB ramdisk yeterlidir, ancak daha fazla boş RAM gerekir.

Test ederken, işlemci yüküne bakmanız gerekir. İdeale (ramdisk) yakın bir durumda, 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 yönleri arayın. Biraz duygusal, ancak genel olarak doğru, işlemcinin 1C'nin çalışması üzerindeki etkisi açıklanmaktadır. 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. Birçok antivirüs var, her birinin ayarları farklı, sadece doğru konfigürasyonla ne web ne de Kaspersky 1C'nin müdahale ettiğ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 önemlisi. 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 kapatılırsa TurboBoost'un açılamamasıdır).

Kısacası, 1C işlemi sırasında diğer cihazlardan (disk, ağ vb.) Cevap beklerken performans modu dengeli ise işlemci frekansını düşürür. Cihazdan bir yanıt geliyor, 1C'nin (işlemcinin) çalışması gerekiyor, ancak ilk döngüler azaltılmış bir frekansta gidiyor, ardından frekans yükseliyor - ve 1C yine cihazdan bir yanıt bekliyor. Ve böylece - saniyede yüzlerce kez.

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

BIOS aracılığıyla. C1, C1E, Intel C durumu (C2, C3, C4) modlarını devre dışı bırakın. Farklı bios'larda farklı şekilde adlandırılırlar, ancak anlam aynıdır. Uzun süre arayın, yeniden başlatma gerekir, ancak 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'in 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 - bilgisayara uzun süre bakım yapılmadıysa, bir fan ile daha güçlü bir şekilde vızıldayacak, daha fazla ısınacak ve daha fazla enerji tüketecektir. Bu performans fiyatıdır.

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

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 orada durabilirsiniz,

hala bazı "papağanları" Xeon'dan sıkabilirsin


BIOS C durumu kapalı, yüksek performans modu.

Turbo boost kullanmazsanız - böyle görünmesi gerekir

performans için ayarlanmış sunucu


Ve şimdi sayılar. Size hatırlatmama izin verin: Intel Xeon 5650, ramdisk. İlk durumda, test 23.26'yı, ikincisinde - 49.5'i gösterir. Fark neredeyse iki katı. Rakamlar değişebilir, ancak oran Intel Core için hemen hemen aynı kalır.

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

c) Turbo Boost. Öncelikle, örneğin işlemcinizin bu işlevi destekleyip desteklemediğini anlamanız gerekir. Eğer öyleyse, o zaman hala yasal olarak biraz performans elde edebilirsiniz. (Özellikle sunucular olmak üzere hız aşırtma konularına 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ız hem de ısı dağılımında çok belirgin bir artış sağladığına katılıyorum)

Örneğin turbo boost nasıl açılır yazıyor. Fakat! 1C için bazı nüanslar var (en belirgin 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 boost olmadan

C durumu kapalı, turbo güçlendirme

53.19

40,32

C durumu açık, turbo güçlendirme

1080

53,13

23,04

Ama sonuçta, CPU performans testlerine göre, çarpanı 23 olan varyantın önde olduğu, Gilev'in dosya versiyonundaki testlerine göre 22 ve 23 çarpanlı performansın aynı olduğu ortaya çıktı. istemci-sunucu sürümü, 23 korku korku korku çarpanına sahip varyant (C durumu seviye 7'ye ayarlansa bile, C durumu kapatıldığından daha yavaştır). Bu nedenle, öneri, her iki seçeneği de kendiniz kontrol edin ve bunlardan en iyisini seçin. Her durumda, 49.5 ve 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ştirmek için yeterli olmadığını, diğer ayarlara da bakmanız gerektiğini hatırlatmama izin verin (BIOS: QPI L0s, L1 - devre dışı, talep ovma - devre dışı, Intel SpeedStep - etkinleştir, Turbo boost - etkinleştirin.Kontrol Paneli - Güç - Yüksek performans) . Ve yine de (dosya sürümü için bile) çarpan daha az olsa bile c-durumunun kapalı olduğu seçenekte dururdum. Böyle bir şey al...

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




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

2. İstemci bilgisayarın işlemcisini ve belleğini bulduğumuzda, 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 emin olun (1 Gbit kartlar için - yani, en az 850 Mbit, ancak daha iyisi 950-980), Gilev'in tavsiyesine uyulduğunu. O zaman - en basit çalışma testi, garip bir şekilde, büyük bir dosyayı (5-10 gigabayt) ağ üzerinden kopyalamak olacaktır. 1 Gbps ağda dolaylı bir normal çalışma işareti, ortalama 100 Mb / s kopyalama hızı, iyi iş - 120 Mb / s olacaktır. İşlemci yükünün de (dahil) zayıf bir nokta 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 tüketmez.

Ve Ötesi. Windows istemcisi varsayılan ayarlarla en iyi Windows sunucusu (hatta Windows iş istasyonu) ve SMB / CIFS protokolü ile çalışır, linux istemcisi (debian, ubuntu diğerlerine 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 tek bir akışa daha hızlı kopyalanması hiçbir şey ifade etmez. 1C için debian'ı ayarlamak 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 aldığımı söyleyebilirim, ancak postgres ile 50 yaş üstü kullanıcılar hala çok kötü her şeye sahibim.

En önemli şey "yanmış" yöneticiler tarafından bilinen, ancak yeni başlayanlar hesaba katmaz. 1c veritabanına giden yolu ayarlamanın 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 ardından 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 neyse) - DriveLetter: \\server\share'i net olarak kullanın. Örnek: net use m:\\server\bases. Özellikle bir IP adresinin DEĞİL olduğunu vurguluyorum, yani isim sunucu. Sunucu ada göre görünmüyorsa, sunucudaki dns'ye veya yerel olarak hosts dosyasına ekleyin. Ancak temyiz isme göre olmalıdır. Buna göre, veritabanına giderken bu diske erişin (resme bakın).

Ve şimdi neden böyle bir tavsiyenin olduğunu sayılarla göstereceğim. İlk veriler: 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ı. Testten önce, Iperf'in tam bir bant genişliği sağladığından emin oldum (10 Gbit kartlar hariç, yalnızca 7,2 Gbit'i sıkıştırdığı ortaya çıktı, daha sonra neden test sunucusunun henüz düzgün yapılandırılmadığını göreceğim). Diskler farklıdır, ancak her yerde bir SSD (test için özel olarak tek bir disk takılır, başka hiçbir şey yüklenmez) veya bir SSD'den baskın vardır. Intel 362 adaptörünün ayarları sınırlandırılarak 100 Mbit hız elde edildi.1 Gbit bakır Intel 350 ve 1 Gbit optik Intel X520-DA2 (adaptör hızı sınırlandırılarak elde edildi) arasında fark yoktu. Maksimum performans, turbo boost kapalı (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 ise hiç etkilemeyebilir). Sürümler 1C 8.2.19.86, 8.3.6.2076. Tüm sayıları değil, sadece en ilginçlerini veriyorum, böylece karşılaştıracak bir şey var.

2008'i Kazanın - 2008'i Kazanın

ip adresi ile arama

2008'i Kazanın - 2008'i Kazanın

Ada göre adres

2008'i Kazanın - 2008'i Kazanın

ip adresi ile arama

2008'i Kazanın - 2008'i Kazanın

Ada göre adres

2008 kazanın - 7 kazanın

Ada göre adres

Windows 2008 - Debian

Ada göre adres

2008'i Kazanın - 2008'i Kazanın

ip adresi ile arama

2008'i Kazanın - 2008'i Kazanın

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):

Ağ üzerinden, bu ağ normal olarak yapılandırılmışsa ve yol 1C'de doğru yazılmışsa, iş için oldukça normal sayılar alabilirsiniz. İlk Core i3'ler bile 40'tan fazla papağan verebilir, bu oldukça iyidir ve bunlar sadece papağanlar değil, gerçek çalışmada da fark göze çarpmaktadır. Fakat! 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, 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 kapatmalarından), FCoE gibi protokolleri kaldırmalarından, sürücüleri daha eski, ancak microsoft sertifikalı bir sürüme (özellikle asus ve dlinks gibi ucuz kartlar için) değiştirmekten, yazılımı kaldırmalarından 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 ve 8.3 - iki veya daha fazla kat daha az verdiği bir durum olabilir. Platform sürümleri 8.3 ile oynamayı deneyin, bazen çok büyük bir etki elde edersiniz.

1C 8.3.6.2076 (belki daha sonra, tam sürümü henüz aramadım) ağ üzerinden kurulumu 8.3.7.2008'den daha kolaydır. 8.3.7.2008'den itibaren normal ağ işletimini (karşılaştırılabilir papağanlarda) elde etmek için sadece birkaç kez çıktı, daha genel bir durum için tekrar edemedim. Pek bir şey anlamadım ama Process Explorer'dan gelen bilgilere bakılırsa, kayıt oraya 8.3.6'da olduğu gibi gitmiyor.

100Mbps'lik bir ağ üzerinde çalışırken, yükleme 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 azdır. 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 çöküntü verebilir. Bu nedenle, para varsa, Intel ağ kartlarını her yerde tutmak daha iyidir, para yoksa Intel'i yalnızca sunucuya (KO'nuz) koyun. Evet ve intel ağ kartlarını ayarlamak için çok daha fazla talimat var.

Varsayılan antivirüs ayarları (örneğin, drweb 10 sürümü) papağanların yaklaşık %8-10'unu alır. Düzgün yapılandırırsanız (1cv8 işleminin güvenli olmamasına rağmen her şeyi yapmasına izin verin) - hız antivirüs olmadan aynıdır.

Linux gurularını OKUMAYIN. Samba'lı bir sunucu harika ve ücretsizdir, ancak sunucuya Win XP veya Win7 (veya daha da iyisi - sunucu işletim sistemi) koyarsanız, dosya sürümü 1c'de daha hızlı çalışı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 kurmanın ve ardından yavaş olduğunu söylemenin bir anlamı yok.

fio ile net kullanım yoluyla bağlanan diskleri 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, 1Gb ile 10 Gb arasındaki farkın görülebileceği testler (veya bir durum) düşünemiyorum. Dosya sürümü için 10Gbps'nin daha iyi sonuçlar verdiği tek yer, diskleri iSCSI aracılığıyla bağlamaktı, ancak bu ayrı bir makalenin konusu. Yine de dosya sürümü için 1 Gbit kartların yeterli olduğunu düşünüyorum.

Neden, 100 Mbit ağ ile 8.3, 8.2'den belirgin şekilde daha hızlı çalışıyor - anlamıyorum, ama gerçek gerçekleşti. Diğer tüm ekipman, diğer tüm ayarlar tamamen aynıdır, sadece bir durumda 8.2 test edilir ve diğerinde - 8.3.

Ayarlanmamış NFS kazan - kazan veya kazan-lin 6 papağan verir, tabloya dahil etmedi. Ayarlamadan sonra 25 aldım, ancak kararsız (ölçümlerdeki artış 2 birimden fazla). Şu ana kadar windows ve NFS protokolünün kullanımı konusunda tavsiye veremem.

Tüm ayarlardan ve kontrollerden sonra, testi istemci bilgisayardan tekrar çalıştırıyoruz, iyileştirilmiş sonuçtan (işe yaradıysa) seviniyoruz. 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 var dosya sürümünün yeteneklerinin zirvesine ulaştı).

Terminal sunucusu. (taban sunucudadır, 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ıyoruz ve testi çalıştırıyoruz. Sonucu hatırlıyoruz.

1. Dosya versiyonunda olduğu gibi aynı şekilde çalışmayı kuruyoruz. Bir terminal sunucusu durumunda, işlemci genellikle ana rolü oynar (bellek eksikliği veya çok miktarda gereksiz yazılım gibi bariz zayıflıkların olmadığı anlaşılır).

2. Bir terminal sunucusu durumunda ağ kartlarının ayarlanması, 1'lerin çalışması üzerinde pratik olarak hiçbir etkiye sahip değildir. "Özel" rahatlık sağlamak için, sunucunuz 50'den fazla papağan veriyorsa, yalnızca kullanıcıların rahatlığı, daha hızlı yanıt ve kaydırma için RDP protokolünün yeni sürümleriyle oynayabilirsiniz.

3. Çok sayıda kullanıcının aktif çalışmasıyla (ve eğer denerseniz, burada 30 kişiyi bir üsse bağlamayı deneyebilirsiniz), bir SSD sürücüsü kurmak çok arzu edilir. Bazı nedenlerden dolayı, diskin özellikle 1C'nin çalışmasını etkilemediğine inanılmaktadır, ancak tüm testler yazma için etkinleştirilmiş denetleyici önbelleği ile gerçekleştirilir, bu yanlıştır. 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 eldeki diskleri koydum. 8.3.6.2076 ve 8.3.7.2008 arasındaki fark küçüktür (Ramdisk Turbo boost sürüm 8.3.6'da 56.18 verir ve 8.3.7.2008 55.56 verir, diğer testlerde fark daha da küçüktür). Güç tüketimi - maksimum performans, turbo boost devre dışı (aksi belirtilmedikçe).

Raid 10 4x SATA 7200

ATA ST3500341AS

Raid 10 4x SAS 10k

Raid 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 içerdiği önbellek, diskler arasındaki tüm farkı ortadan kaldırır, sayılar hem sat hem de sas için aynıdır. Az miktarda veri için onunla 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 katından 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ülebilir "Aktif disk süresi (% olarak)" 80-95. Evet, disklerin kendilerinin 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ğine bakılmaksızın). Ancak bunlar önbelleğin sentetik papağanlarıdır, büyük veritabanlarıyla gerçek çalışmada asla %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 yeterli. Yazma kaynağı başka bir konudur, burada her bir özel duruma bakmanız gerekir, Intel 3700'ün daha yüksek bir sıraya 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 anlıyorum, gerçek sonuçlar daha az olacak.

En doğru (bana göre) çö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 koymamaktır. Evet, bir ayna ile SSD'ler aynı şekilde yıpranır ve bu bir eksidir, ancak en azından kontrolör elektroniğindeki hatalara karşı bir şekilde sigortalıdırlar.

Dosya sürümü için SSD disklerinin ana avantajları, çok sayıda veritabanı olduğunda ve her birinin birkaç kullanıcısı olduğunda ortaya çıkacaktır. 1-2 baz ve 10 bölgesinde kullanıcılar varsa 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ışma 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österirse (30'un üzerinde), o zaman ana çalışan veritabanının yavaş çalışması, büyük olasılıkla bir programcının suçudur.

Gilev testi küçük sayılar gösteriyorsa ve hem yüksek frekanslı hem de hızlı disklere sahip bir işlemciniz varsa, o zaman 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 sürüme oldukça ciddi şekilde bağlıdır.

Test için, ana eğilimleri göstermek için farklı sunucu seçenekleri 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 düşündüm, başka bir şeyle ilgileniyorsanız - yorumları yazın, yapmaya çalışacağım.

Depolamadaki SAS, depolamanın büyük önbellek boyutlarına sahip olmasına rağmen 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ın neredeyse iki katına çıkmasını sağladı. Evet, sunucu konfigürasyonları tam olarak uyuşmuyor, ancak bir eğilim gösteriyor (şaşırtıcı bir şey değil).

SQL sunucusundaki frekansı artırmak kesinlikle bir etki sağlar, ancak 1C sunucusundakiyle aynı değil, MS SQL sunucusu (eğer isterseniz) çok çekirdekli ve boş bellek 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 etki sağlar. Bunu yaptığınızdan emin olun, hızlı ve kolaydır. Kurulum sırasında biri 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, örneğin SunucuAdı\ÖrnekAdı aracılığıyla belirtilmesi gerekir. zz-test\zztest. (Aksi takdirde bir DBMS hatası oluşur: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: 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 düzeyi=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 RAM'den daha azını vermek haksız bir açgözlülüktür (bunun için yeterli belleğe sahip olduğunuzu ve her şeyin yolunda gittiğini düşünüyorsanız, belki 1C dosya sürümü sizin için yeterli olabilir mi?)

Bir grup 1C ve SQL'in sanal bir makinede 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. Düşüyor, evet, ama %2-3'e önemli bir etki demezdim.

Orta ve büyük işletmeler için "1C:Enterprise 8" ihtiyaçlarına yönelik bir sunucu tasarlama

Materyal, 25-250 veya daha fazla kullanıcı yükü ile 1C:Enterprise 8'in ihtiyaçları için sunucu çözümleri tasarlayan teknik uzmanlara yöneliktir. Sunucu bileşenleri tarafından gerekli performansın değerlendirilmesi konuları, aşırı iş yükü durumları, sanallaştırmanın etkisi dikkate alınarak değerlendirilir. Büyük işletmeler için hataya dayanıklı kurumsal altyapı oluşturma konuları aşağıdaki materyalde tartışılacaktır.

Gerekli ekipman performansının tahmini.

Ekipman seçmek için en azından CPU, RAM, disk alt sistemi ve ağ arayüzü kaynakları ihtiyacının bir ön değerlendirmesi gereklidir.
Burada dikkate almanın iki yolu vardır:
a) Mevcut ekipman üzerindeki yük hakkında nesnel veriler elde etmenizi ve darboğazları belirlemenizi sağlayan deneysel;
b) Tahmini, ampirik olarak elde edilen ortalama verilere dayalı bir değerlendirme yapmanızı sağlar.
En etkili olanı, her iki metodolojinin ortak kullanımıdır.

  1. Yük izleme, sonuçları değerlendirme, darboğazları bulma ve gereksinimleri oluşturma

Halihazırda çalışan bir sisteminiz varsa yük analizi yapmak neden önemlidir?
Burada tıpla karşılaştırmak en doğru olur. Bir hasta doktora geldiğinde, önce bir muayene yapılır, testler reçete edilir, ardından mevcut bilgilerin tüm kompleksi değerlendirilir ve tedavi reçete edilir. Bir sunucu tasarlarken durum tamamen aynıdır.
Yük parametrelerini ölçmek ve sonuçları analiz etmek için çaba sarf ederek, ödül olarak tasarlanan sunucunun görevlerimize en uygun eşleşmesini alacağız. Nihai sonuç - gelecekte hem başlangıç ​​maliyetlerinde hem de işletme maliyetlerinde önemli tasarruflar olacaktır.

Sunucu performansını ana alt sistemler çerçevesinde değerlendireceğiz: merkezi işlemciler, RAM, disk giriş/çıkış alt sistemi ve ağ arayüzleri. Windows ortamında, hesaplama yükünü değerlendirmek için standart bir Windows Performans İzleyicisi (perfmon) araç takımı vardır. Diğer sistemlerin kendi eşdeğer değerlendirme araçları vardır.
Genel olarak, her bir alt sistemdeki yük, birlikte çalıştıkları uygulamalara ve veri türlerine büyük ölçüde bağlıdır. 1C ile ilgili uygulama bloğu için en kritik olanlar CPU, RAM ve SQL sunucusu için ayrıca disk alt sistemidir. Birden çok sunucuya yayıldığında, ağ arayüzü de kritiktir. Yalnızca uygulanan görev açısından bizim için önemli olan parametrelerle çalışacağız.
Analiz için veriler, tipik bir iş gününde en az 24 saat önceden toplanmalıdır. İdeal olarak - üç tipik iş günü için veri toplamak. Darboğazları bulmak için, en büyük yükün olduğu gün hakkında veri alınması arzu edilir.
Aşağıda açıklanan her şey, hem yeni bir sunucunun tasarımına hazırlık aşamasında (tedarikçi için bir görev belirlemek için) hem de çalışma sırasında, ekipman parametrelerindeki değişikliklerin objektif bir değerlendirmesi ve olası daha fazla “ayarlama” için kullanışlı olacaktır. Genel olarak "1C: Enterprise 8" altındaki yazılım ve donanım kompleksinin ”.

İŞLEMCİ. En çok bir parametreyle ilgileniyoruz - " İşlemci: % İşlemci Süresi» (« İşlemci: % İşlemci Süresi "). Microsoft bu parametre hakkında şunları söylüyor: “Bu sayaç, CPU'nun çalışırken bir iş parçacığı yürütmek için harcadığı zamanı izler. %80 ile %90 arasındaki kalıcı CPU kullanım düzeyi, bir CPU yükseltmesini veya birden çok işlemci ekleme ihtiyacını gösterebilir." Dolayısıyla CPU yükü ortalama olarak %70-80 seviyesinde ise bu, CPU kaynaklarını kullanma verimliliği ve yoğun dönemler için performans marjının optimal oranıdır. Daha az - sistem yetersiz. %80'den fazlası - risk altında, %90 - sistem aşırı yüklendi, yükü diğer ana bilgisayarlara dağıtmak veya yeni, daha üretken bir sunucuya geçmek gerekiyor.

CPU analizi . Modern işlemciler için önce kaç çekirdeğe ihtiyacınız olduğunu bulmak mantıklıdır. Windows'un kendisi yükü çekirdekler arasında oldukça etkili bir şekilde dağıtır ve çekirdeklere yazılım düzeyinde net bir bağlanma olduğu nadir durumlar dışında, tüm işlemci çekirdekleri aşağı yukarı eşit olarak yüklenir. Genel olarak, bir parametreniz varsa "% işlemci zamanı» %50-70 arasında - her şey yolunda, bir rezerv var. %50'den azsa, sisteminizde zaten fazla sayıda çekirdek vardır, bunların sayısını azaltabilir veya sunucuya başka görevler yükleyebilirsiniz. Ortalama %80 veya daha fazla yük - sisteminizin daha fazla çekirdeğe ihtiyacı var.

Veri deposu . Burada iki parametreyi izlemek mantıklıdır:
« Bellek: Kullanılabilir Mbayt» (« Bellek: Kullanılabilir MB "). Normal bir işletim sisteminde bu sayaç, sunucuda kurulu fiziksel bellek miktarının en az %10'u olmalıdır. Kullanılabilir bellek miktarı çok düşükse, sistem etkin işlemler için disk belleği dosyasını kullanmaya zorlanır. Sonuç olarak, sistemin "dondurulması" etkisine kadar gözle görülür gecikmeler olur.
« Hafıza:%Bağlılıkbaytİçindekullanmak», « Bellek: Ayrılan bellek kullanımı yüzdesi ". Bu sayacın yüksek bir değeri, sistemin RAM üzerinde büyük bir yük yaşadığını gösterir. Bu parametrenin %90'ın altında olması çok arzu edilir, çünkü. %95'te OutOfMemory hatası olasılığı vardır.

RAM Analizi . Anahtar parametre, yukarıdaki sayaçları oldukça etkili bir şekilde izlemenizi sağlayan sunucudaki kullanılabilir RAM'in mevcudiyetidir.

disk alt sistemi. Çok sık olarak, 1C:Enterprise 8'in performansıyla ilgili sorular, disk alt sisteminin yetersiz performansıyla ilgilidir. Ve burada, ekipmanı görev için optimize etmek için oldukça fazla fırsatımız var. Bu nedenle disk alt sistem sayaçlarının analizine azami özen göstereceğiz.

  1. « % Boş alan' mantıksal sürücüdeki boş alan yüzdesidir. Disk kapasitesinin %15'inden azı boşsa, aşırı yüklenmiş olarak kabul edilir ve daha sonraki analizi büyük olasılıkla tamamen doğru olmayacaktır - diskteki veri parçalanmasından büyük ölçüde etkilenecektir. Sunucu diskinde önerilen boş alan miktarı en az %20, tercihen SSD için daha fazladır.
  2. « Ağustos Disk sn/Aktarım» ortalama disk erişim süresidir. Sayaç, bir disk iletişim işlemi için gereken ortalama süreyi milisaniye cinsinden gösterir. Hafif yüklü sistemler için (örneğin dosya depoları, VM depoları), değerinin 25 - 30 ms arasında tutulması arzu edilir. Çok yüklü sunucular (SQL) için - 10 ms'yi geçmemek istenir. Büyük sayaç değerleri, disk alt sisteminin aşırı yüklendiğini gösterir. Bu, daha ayrıntılı bir analiz gerektiren ayrılmaz bir göstergedir. Sayaçlar ne tür işlemler, okuma veya yazma ve ne oranda gösterir? Ağustos Disk sn/Okuma(saniye cinsinden ortalama disk okuma süresi) ve Ağustos Disk sn/Yazma(yazma başına ortalama disk erişim süresi).
    Entegre gösterge Ort. RAID5/RAID6'da disk sn/Transfer, okuma işlemlerinin önemli bir baskınlığı ile normal aralıkta olabilir ve yazma işlemleri önemli gecikmelerle gerçekleştirilecektir.
    3.Ağustos Disk Sıra Uzunluğu(ortalama disk kuyruğu uzunluğu) aslında ayrılmaz bir göstergedir ve aşağıdakilerden oluşur: Ağustos Disk Okuma Kuyruğu Uzunluğu(okuma için diske giden kuyruğun ortalama uzunluğu) ve Ağustos Disk Yazma Kuyruğu Uzunluğu(diske yazma kuyruğunun ortalama uzunluğu). Sabit sürücü kullanılabilir olduğunda ortalama olarak kaç G/Ç işleminin beklendiğini size söyler. Bu ölçülebilir bir gösterge değildir, ancak kuyruk teorisinden Little yasasına göre N = A * Sr şeklinde hesaplanır, burada N sistemdeki bekleyen isteklerin sayısıdır, A taleplerin oranıdır, Sr yanıt süresidir. Normal çalışan bir disk alt sistemi için bu gösterge, RAID grubundaki disk sayısını 1'den fazla aşmamalıdır. SQL Server sınıfı uygulamalarda ortalama değerinin 0,2'den küçük bir seviyede tutulması istenir.
    4.Geçerli Disk Sıra Uzunluğu(geçerli disk kuyruğu uzunluğu), seçilen diske gönderilen bekleyen ve bekleyen isteklerin sayısını gösterir. Bu, mevcut değerdir, anlık bir göstergedir ve belirli bir süre boyunca ortalama bir değer değildir. Disk alt sistemine yapılan isteklerin işlenmesi için gecikme süresi, kuyruğun uzunluğu ile orantılıdır. Sabit durumda rahat çalışma için, bekleyen isteklerin sayısı dizideki fiziksel disklerin sayısını 1,5-2 katından fazla aşmamalıdır (birkaç disk dizisinde her diskin aynı anda bir istek seçebileceğini varsayıyoruz). sıra).
    5.Disk Transferleri/sn(disk erişimi/sn) - Bir saniye içinde tamamlanan bireysel disk G/Ç isteklerinin sayısı. Disk alt sistemine rastgele okuma ve yazma için uygulamaların gerçek ihtiyaçlarını gösterir. Birkaç bireysel sayacı özetleyen bir gösterge olarak, genel durumu hızlı bir şekilde değerlendirmenize olanak tanır.
    6.Disk Okuma Sayısı/sn- Saniyedeki okuma erişim sayısı, yani disk okuma işlemlerinin sıklığı. Disk alt sisteminin gerçek performansını belirleyen SQL Server sınıfı uygulamalar için en önemli parametre.
    Normal, yerleşik bir modda, erişimlerin yoğunluğu, disklerin fiziksel yeteneklerini - dizideki disk sayısı ile çarpılan bireysel limitlerini - aşmamalıdır.

SATA veya NL SAS sürücüsü başına 100-120 IOPS;

SAS 15000 rpm disk başına 200-240 IOPS;

Intel SSD sınıfı s3500 serisi (SATA) başına 65.000 IOPS;

7.Disk Yazma Sayısı/sn- saniyedeki yazma erişimi sayısı, yani diske yazma işlemlerinin sıklığı. SQL Server sınıfı uygulamalar için son derece önemli bir parametre. Normal modda çalışırken, erişim hızı, dizideki disk sayısı ile çarpılarak ve seçilen RAID tipi için yazma cezası dikkate alınarak, disklerin fiziksel sınırlarını aşmamalıdır.

SATA veya NL SAS sürücüsü başına 80-100 IOPS;

SAS diski başına 180-220 IOPS;

2 .20 GHz

DDR4
1600/1866/2133

3 .50 GHz

DDR4 1600/1866/2133/2400

Tablo 1 - RAM ile çalışma parametreleri

Veri deposu . Tüm sunucunun performansı, takılı bellek türünden etkilenecektir. Örneğin, LR DIMM, mimarisi nedeniyle her zaman normal DDR4 RDIMM belleğinden daha yüksek gecikme süresine sahip olacaktır. Özellikle 1C ile çalışırken SQL için tipik olan nispeten kısa sorgularda. Daha yüksek gecikme süresine ve önemli ölçüde daha yüksek fiyata bağlı olarak, yalnızca RDIMM'leri kullanarak gerekli miktarda RAM elde etmek mümkün değilse LR DIMM takmak mantıklıdır.
Benzer şekilde, DDR4 2400, eğer CPU yüksek frekansları destekliyorsa, DDR4 2133'ten biraz daha hızlı çalışacaktır.

ağ Arayüzü. Burada basit kurallara uymanız önerilir:
a) Sunucunun en az üç ağ arabirimi 1Gb Ethernet veya üzeri (10Gb, 40Gb) ve en az ikisinin sunucu ağ yongalarında olması gerekir. Tabii ki, ceteris paribus, özellikle ekipman fiyatlarındaki kaybolan küçük fark göz önüne alındığında, 10Gb Ethernet altyapısını tercih etmelisiniz (1GB / 10Gb anahtarlarda 10Gb ağ kartları ve 10Gb bağlantı noktaları).
b) Sunucu, uzaktan yönetim için şu veya bu IP üzerinden KVM teknolojisini desteklemelidir.
İnceliklerden biri, tüm Intel sunucu ağ yongaları tarafından sanallaştırma araçları için çok iyi destek ve 10Gb + için CPU çekirdekleri arasında yükü etkin bir şekilde dağıtma yeteneği olabilir.

Disk alt sistemi :

Disk alt sistemi iki bileşenden oluşur:
- SAS HBA denetleyicileri ve RAID denetleyicileri biçimindeki giriş/çıkış alt sistemi;
- depolama aygıtları veya bizim durumumuzda - SSD ve HDD diskleri.

YAĞMA.
İşletim sistemi ve veritabanı depolama görevleri için, kural olarak, çeşitli yazılım karşılıklarının yanı sıra RAID 1 veya RAID 10 kullanılır.

1. Windows Server aracılığıyla tam yazılım RAID (Soft RAID) bir önyükleme sürücüsü için kullanılamaz, ancak DB, tempDB ve SQL günlüğünün depolanması için oldukça uygundur. Windows Depolama Alanları teknolojisi, depolama güvenilirliği ve performansı açısından oldukça yüksek performans sağlar ve ayrıca en ilginç olanı 1C görevlerine uygun olan “Katmanlı depolama” olan bir dizi ek işlev sunar. Bu teknolojinin avantajı, en sık istenen verilerin bir kısmının sistem tarafından otomatik olarak SSD'ye yerleştirilmesidir.
1C görevleriyle ilgili olarak, genellikle bir All-Flash dizisi SSD'ler veya çok büyük (1TB ve üzeri) ve çok yıllı veritabanları için - Katmanlı depolama kullanırlar.
Windows Depolama Alanları teknolojisinin avantajlarından biri, NVMe sürücülerinde RAID oluşturma yeteneğidir.

2. İşletim sistemini barındırmak için, Intel ve Intel® Rapid Storage Technology'nin yonga seti temelinde oluşturulmuş donanım-yazılım RAID1 etkilidir ( IntelRST).
İçinde, donanım seviyesindeki giriş-çıkış işlemleri, pratik olarak CPU kaynakları kullanılmadan anakart yonga seti tarafından gerçekleştirilir. Ve dizi, Windows altındaki sürücüler sayesinde yazılım düzeyinde yönetilir.
Herhangi bir uzlaşma çözümü gibi, Intel RST'nin de bazı dezavantajları vardır.
a) Intel RST'nin çalışması, işletim sistemine yüklenen sürücülere bağlıdır. Ve bu, sürücüleri veya işletim sistemini güncellerken RAID diskinin kullanılamayacağı bir durumun ortaya çıkması gibi bazı potansiyel riskler taşır. Çok düşük bir ihtimal çünkü Intel ve Microsoft çok arkadaş canlısıdır ve yazılımlarını çok iyi test eder, ancak dışlanmaz.
b) Deneylerin sonuçlarına dayanarak, dolaylı kanıtlar Intel RST sürücü modelinin yazma önbelleği için RAM kaynaklarını kullandığını göstermektedir. Bu, performans artışı sağlar, ancak sunucunun gücü planlanmamışsa bazı veri kaybı riski de taşır.
Bu çözümün de avantajları vardır.
Bunlardan biri her zaman çok yüksek performanstır; bu, tüm donanıma sahip RAID denetleyicileriyle aynı düzeyde ve hatta bazen onlardan daha iyidir.
İkincisi, NVMe sürücüleri için donanım yazılımı RAID1 desteğidir (bu yazının yazıldığı sırada önyükleme sürücüleri için değil). Ve burada oldukça yüklü disk alt sistemleri kullananlar için ilginç bir özellik yatıyor. G/Ç ile kullanılan çekirdeği neredeyse %100'e "yükleyen" Windows Depolama Alanlarının aksine, çekirdek yükü yaklaşık %70'e ulaştığında Intel RST, sonraki çekirdeği G/Ç işlemine bağlar. Sonuç olarak, CPU çekirdeklerinde daha eşit bir yük ve yüksek yüklerde biraz daha iyi performans.

Şekil 4 - CPU Kullanımı Windows Depolama Alanları vs. Intel RST

3. RAID 1'de 2-6 SSD'ye sahip bir sunucuda tam donanım RAID, örneğin bir Intel® RAID Denetleyicisi RS3WC080 gibi bir LSI SAS 3008 yonga setinde bir SAS HBA ile elde edilebilir. Bunu yapmak için, SAS HBA'ya özel bir “IR” bellenimi kurulur. Ayrıca, bu SAS HBA, yaklaşık 300 $ fiyatla SAS 3.0 standardını (12 Gb / s) destekler. Burada mükemmel bir seçim, gerekli donanım yazılımıyla birlikte gelen Intel® RAID Denetleyici RS3WC080 olacaktır.
Bu çözümün özü, sunucu SSD'lerinin yazma önbelleğine ihtiyaç duymamasıdır. Ayrıca, daha gelişmiş RAID denetleyicileri, bir SSD ile çalışırken yerleşik yazma önbelleklerini de devre dışı bırakır. Böylece, RAID denetleyici modunda bir SAS önbelleği olmayan HBA, yüksek hızlı yazma ve doğrudan SSD'den okuma görevleriyle oldukça başarılı bir şekilde başa çıkarak oldukça iyi bir performans sağlar.

4. Çok sayıda SAS veya SATA SSD sürücüsüne sahip yüksek yüklü sunucular için, Intel® RAID Controller RS3MC044 veya Adaptec RAID 8805 sınıfının tam teşekküllü bir RAID denetleyicisinin kurulması tavsiye edilir. Arızalı bir diski değiştirdikten sonra dizinin montajını hızlandırmanıza izin verenler de dahil olmak üzere, HDD ve SSD disklerle çalışmak için daha verimli G / Ç işlemcileri ve gelişmiş algoritmaları vardır.

Depolama Aygıtları (SSD'ler)ve HDD).
a) Güvenilirlik SSD ve HDD .
Genellikle, disklerin teorik güvenilirliği, "Okunan bit sayısı başına kurtarılamayan bir okuma hatası olasılığı" olarak çevrilebilen "Okunan Bit Başına Kurtarılamayan Okuma Hataları" parametresi ile değerlendirilir. Diskten ne kadar veri okunduğunu gösterir, istatistiklere göre kurtarılamaz bir hata beklemelisiniz.
Diğer bir önemli parametre, disk arızası olasılığını gösterir - AFR (yıllık arıza oranı) veya "Yıllık arıza oranı".
Aşağıdaki tablo, SATA Enterprise HDD 7200 prm (SATA Raid Edition), SAS HDD Enterprise 15.000 prm, SATA SSD Enterprise için tipik sürücüler için verileri gösterir.

Parametre

disk türü

Kurumsal SATA\SAS NL 7200 prm

Kurumsal SAS 15.000 sayfa/dakika
(10.000 sayfa/dakika)

Kurumsal SATA SSD

Okunan Bit Başına Kurtarılamaz Okuma Hataları

İstatistiksel olarak okunduğunda kurtarılamaz bir hataya neden olması beklenen birim

Sekme. 2 - HDD ve SSD'nin teorik güvenilirliği

Intel® SSD DC S3510 Serisi sınıfının Enterprise SATA SSD'si, SAS HDD Enterprise 15.000 prm'den 10 kat ve SATA Enterprise HDD 7200 prm'den 100 kat daha düşüktür. Bu nedenle, Enterprise sınıfı SSD'ler teorik olarak ve herhangi bir HDD'den daha güvenilirdir.

b) Sonra, tahmin ediyoruz verim SSD ve HDD .
Aslında 1C olan veritabanı açısından en önemlisi sadece üç disk parametresidir:
- gecikme (Gecikme) veya disk yanıt süresi, mikrosaniye cinsinden ölçülür (daha az daha iyidir);
- IOPS cinsinden ölçülen saniye başına okuma işlemi sayısı (Disk Okumaları / sn), (daha fazlası daha iyidir);
- IOPS cinsinden ölçülen, saniyedeki yazma işlemi sayısı (Disk Yazma/sn).
Bu üç parametreyi tek bir tabloda özetleyelim:

Parametre

disk türü

Kurumsal SATA / SAS NL 7200 prm

Kurumsal SAS 15.000 sayfa/dakika
(10.000 sayfa/dakika)

Kurumsal SATA SSD

Kurumsal NVMe SSD

Gecikme (disk okuma/yazma yanıt süresi), mikrosaniye

Disk Okuma Sayısı/sn (saniyedeki okuma işlemi sayısı), IOPS

Disk Yazma/sn (saniyedeki yazma işlemi sayısı), IOPS

Sekme. 3 - HDD ve SSD performansı.

Tablodan açıkça görülebileceği gibi, NVMe SSD (örneğin, Intel® SSD DC P3600 Serisi) gecikme Enterprise SAS HDD'den daha iyi performans gösterir 100 kere ve tarafından G/Ç işlemlerinin sayısı saniyede - in 200 kez kayıt için ve 1500 kez okumak için.
Veritabanlarını barındırmak için HDD teknolojisini kullanmak mantıklı mı?

v) Sunucu için günlük üzerine yazma hacmi SSD .
Formdaki herhangi bir "çörek" e ek olarak süper kapasitör bir elektrik kesintisi ve donanım şifreleme modülleri durumunda, sunucu SSD'leri en önemli parametreye sahiptir - SSD diskinin toplam kapasitesinden günlük tahmini yeniden yazma miktarı. Intel sunucu SSD'lerinden bahsediyorsak, garantiye dahil olan bu hacmin 5 yıl boyunca günlük olarak yeniden yazılmasını kastediyoruz. Bu seçenek, SSD'leri "öncelikle okuma", "yazma okuma odaklı" ve "ağır yazma odaklı" olarak sıralamanıza olanak tanır. Tablo biçiminde, şöyle görünür:

Intel SSD Sürücü

Günlük üzerine yazma (kapasiteden itibaren)

Sekme 4. - Günlük SSD üzerine yazma hacmi.

Buna göre, sunucudaki görev için özel olarak diskleri doğru bir şekilde seçebilirsiniz.
Örneğin, Intel SSD s3510, OS ve SQL günlüğünü depolamak için yeterlidir.
DB ve tempDB depolama için Intel SSD s3610 veya Intel SSD s3710 daha uygundur.

Disk alt sistemleri tasarlama örnekleri.
Yukarıdakilerle donanmış olarak, çeşitli gereksinimler için birkaç disk alt sistemini bir araya getirelim.
a) 45 kullanıcı için sunucu, DB - 15 GB, yıllık büyüme - 4 GB, tempDB - 0,5 GB, SQL log - 2 GB.
Burada, OS ve SQL Log ihtiyaçları için iki Intel SSD s3510 240 GB diskten RAID1'i ve DB ve tempDB ihtiyaçları için iki Intel SSD s3510 120 GB diskten RAID1'i kurmak ekonomik olarak haklıdır. Yerleşik bir Intel® RAPID, RAID denetleyicisi olarak uygundur.
b) 100 kullanıcı için sunucu, DB - 55 GB, yıllık büyüme - 15 GB, tempDB - 4 GB, SQL log - 8 GB.
Böyle bir sunucu için, OS ve SQL Log ihtiyaçları için iki adet Intel SSD s3510 240 GB diskten RAID1'ini ve DB ve tempDB ihtiyaçları için iki adet Intel SSD s3610 200 GB diskten RAID1'ini sunabilirsiniz. Bir RAID denetleyicisi olarak, Intel® RAID Denetleyicisi RS3WC080 (basit donanım, önbelleksiz) en uygunudur.
c) 200 kullanıcı için sunucu, DB - 360 GB, yıllık büyüme - 70 GB, tempDB - 24 GB, SQL log - 17 GB.
Bu sunucu zaten oldukça meşgul. İşletim sistemi için hala iki Intel SSD s3510 240 GB diskin RAID1'ini alıyoruz. SQL Log ve tempDB, iki Intel SSD s3510 120 GB sürücüden oluşan özel bir RAID1'de barındırılabilir. Ve DB tabloları için dört Intel SSD s3610 400 GB diskten RAID10 toplayın. Bir RAID denetleyicisi olarak "gelişmiş" Intel® RAID Controller RS3MC044'ü kullanmak uygundur.

sanallaştırma
Modern sunucuların performansı, genellikle bir fiziksel - bir dizi sanal sunucuya yerleştirmenize izin verir. Optimum yerleşimleri için sanallaştırmanın sunucu bileşenlerinin her birini nasıl etkilediğini akılda tutmak tavsiye edilir.
CPU ve RAM, sanal bir ortamda en az performans kaybına uğrayan alanlardır. Buna göre, esas olarak bunları kullanan yazılım bileşenleri, Sanal Makineye (VM) sorunsuz bir şekilde yerleştirilebilir. Bunlara 1C:Enterprise 8 dahildir. Uygulama Sunucusu x64, Uzak Masaüstü hizmeti ve IIS.
G / Ç alt sistemleri, sanallaştırma sırasında gözle görülür şekilde daha büyük kayıplara maruz kalır: %5-15 - ağ arabirimi ve %25'e kadar - disk alt sistemi. Disk alt sisteminin performansına duyarlı bir SQL Serve yazılım bileşenimiz var - onu "VM" yerine fiziksel "donanım" içine yerleştirmek oldukça mantıklı.
Genellikle bunu ayrı sunucularla veya 1C altındaki bir sunucu grubuyla yaparlar:
- Donanım üzerinde işletim sistemi Windows ve MS SQL Server kuruludur;
- 1C:Enterprise 8. Uygulama Sunucusu x64, VM'de ve Lisans Sunucusu aynı VM'de başlatılır;
- ayrı bir VM hizmetinde Uzak Masaüstü veya IIS.
Bir sunucuda birkaç yazılım bileşeni kullanırken, dahil. farklı VM'lerde, disk alt sistemi düzeyinde yerleştirmeleri için ek alan sağlamak gerekir. Kural olarak, bunlar işletim sistemine sahip sistem diskleridir - 480 GB veya daha fazlasına yükseltilirler.

Destek olmak
Oldukça yaygın bir uygulama, dosya depolamanın yanı sıra veritabanlarının yerel kopyalarını depolamak için RAID1'de iki büyük kapasiteli HDD'yi (4-8 TB) bir sunucuya kurmaktır. Böyle bir depolama, rastgele erişim hızı için yüksek gereksinimlere sahip değildir. Hem okuma hem de yazmanın doğrusal hızı, günlük yedeklemeleri ve kullanıcı dosyalarını buna kaydetmek için oldukça yeterlidir. Bu tür bir birimi RAID denetleyicisinin mevcut herhangi bir sürümünde bir araya getirebilirsiniz ve Intel® RAPID'de oldukça hızlı çalışmaya devam edecektir.

Ve lütfen, sorumlu görevler için ayrı bir sunucunun olması gerektiğini unutmayın. aşırı beslenme .

Uzun yıllardır, 1C dosyasının çalışmasını neyin hızlandırabileceği konusunda forumlarda tartışmalar oldu.

Tabii ki aralarında benim de paylaştığım pek çok tarif var.

Ama kim ne derse desin, 1C dosyası için 1 numaralı darboğaz elbette disk alt sistemidir!

Aslında "Dosya".

Birden çok disk erişimi, 1C Enterprise'daki tüm çalışmaları gerçekten "yavaşlatabilir".

Ve eğer çok kullanıcılı erişimden bahsediyorsak, o zaman bu burada açıktır.

Bu sorun nasıl çözülebilir?

Tabii ki, daha hızlı HDD'lere, SAS sürücülerine, RAID'lere, SSD'lere ve hatta "aşırılık arayanlar" için veritabanını bir RAM diskine, yani bir PC veya sunucunun RAM'ine yerleştirmenin bir yoluna geçerek.

Aslında bu yazıda tüm yöntemlere değineceğiz, ancak elbette sonuncusuna özellikle dikkat edeceğiz.

Ağda, hem 1C hem de RAM disklerini kullanmanın birçok nüansını ve ayrıca 1C'deki günlük çalışmaları dikkate alarak diğer tüm disk alt sistemlerinde akıllı testleri ortaya çıkarabilecek yeterli makale bulunmadığından.

Ama burada birçok soru var:

Kimler ve ne zaman kullanabilir?

Hangi durumlarda?

Güvenilirlik?

Uygulama alanı?

1C'de çeşitli işlemlerde gerçek hız testleri?

Belki de sıradan HDD'lerden başlayalım.

Tabii ki, sorunun özü, 1C'de (özellikle çok kullanıcılı erişim) dosya çalışması için gerekli hızları sağlamayan HDD'nin mekaniğinde yatmaktadır.

HDD'yi hızlandırmanın tek yolu, 5400 rpm HDD'yi 7200 rpm HDD ile değiştirmektir.

Evet, dönme hızı önemlidir ve 7200 rpm kesinlikle 5400'den daha hızlıdır.

Farkı hissetmek istiyorsak budur. (Ancak bugün neredeyse tüm HDD'lerin 7200 hızda çalıştığını belirtmekte fayda var.)

7200 rpm'deki sürücüler yaklaşık olarak aynı sonucu gösterir.

Ve ister SATA 2 ister SATA 3 olsun.

SATA (eng. Seri ATA), bilgi depolama aygıtları ile bir seri veri alışverişi arabirimidir.

SATA III arabirimini (HDD için) takip ediyorsanız, burada somut bir hız olmayacak, yalnızca sayılar çok küçük olacaktır. (daha sonra sadece SATA II ve SATA III desteği ile HDD hızını test edeceğiz).

Bu arada, " CrystalDiskInfo» programını kullanarak diskinizin şu anda hangi arabirimde çalıştığını (ve hangi arabirimi desteklediğini) öğrenebilirsiniz.

SATA/300MB/s - SATA 2

SATA/600MB/s - SATA 3

—| SATA/300 (bkz. Şekil 1) - birincisi diskin mevcut çalışma modu ve ikincisi SATA/300 desteklenen çalışma modudur. (Bazen ilki eski disklerde görüntülenmez).

İkinci şekilde SATA 3 yani 600 MB/sn'ye sahip olduğumuz hem çalışma hem de HDD desteği olduğunu görüyoruz. - arayüzün verimi.

(Arayüzler konusuna daha sonra döneceğiz).

Başka bir şey, sıradan HDD'leri RAID - 0'a (Şerit) koyarsak.

İki veya dört diskli RAID 0, veri aktarım hızında gözle görülür bir kazanç sağlar, ancak hiç güvenilirlik sağlamaz. Herhangi bir ucuz ve hatta yazılım RAID denetleyicisi, yapımı için uygundur. Minimum maliyetle geleneksel HDD'lerdeki dosya sisteminden maksimum performansı sıkıştırması gerekenler için uygundur.

Hız, bazı eski SSD'lerle bile karşılaştırılabilir, ancak ne yazık ki, burada güvenilirlikle hız için para ödüyoruz. En az bir disk arızalanırsa, her iki diskteki tüm bilgiler kaybolur!

Bu nedenle, böyle bir RAID ile 1C veritabanlarının sık sık yedeklenmesi gerekir.

Hangi hız nedeniyle?

RAID - 0'daki veriler, dizinin diskleri arasında eşit olarak dağıtılır, diskler birkaçına bölünebilen bir diskte birleştirilir. Dağıtılmış okuma ve yazma işlemleri, birkaç disk aynı anda veri bölümlerini okuduğundan / yazdığından, çalışma hızını önemli ölçüde artırmanıza izin verir.

Başka bir deyişle, RAID 0, bu hız nedeniyle mekaniği ustaca atlar.

Bu RAID-10

Ancak bu sistemi düzenlemek için gereken minimum disk sayısı 4'tür.

Tabii ki, bu yazıda basit bir 1C dosyasından bahsediyoruz, bu yüzden sadece giriş seviyesi sunucuların hiç bulunmadığı küçük şirketler için bütçe çözümlerini analiz ediyoruz.

Aynı nedenle, daha hızlı ve daha pahalı SAS sürücüleri, iSCSI protokolleri analiz edilmeyecektir.

Yalnızca SSD sürücüler, sunucu SAS'ından daha hızlıdır.

Birkaç yıl önce, 1C'de çalışmak için "katı hal" satın almanızı tavsiye etmem.

Ancak bu görüş, günümüzün güvenilir ve nispeten ucuz SSD sürücülerinin ardından değişti.

Örneğin, SAMSUNG bugün bazı diskleri için 10 yıl garanti veriyor!

Intel, SanDisk, Corsair ve diğerleri SSD'de 5 yıl garanti!

SSD'ler çok daha güvenilir, daha hızlı çalışmaya başladı ve denetleyiciler gözle görülür şekilde daha akıllı hale geldi, dolayısıyla bu tür garantiler.

Fiyatlar hakkında

Elbette INTEL'in kurumsal düzeydeki SSD sürücüleri bize bir kuruşa mal olacak.

Ama aynı zamanda iyi bütçe alternatifleri de var.

Örneğin, SanDisk X400 256 GB'den "katı hal" bize sadece 95 dolara mal olacak!

Aslında, makalenin sonraki bölümünde 1C'de de test edeceğiz.

SanDisk X400 sürücü iyi, güvenilir (5 yıl garanti), hızlıdır (540/520 MB/sn'ye kadar okuma/yazma).

Ve hızlardan bahsettiğimize göre, burada SATA 3 gibi bir anı dikkate almalıyız.

Resmi olarak SATA 6 Gb/s olarak bilinen SATA III (sürüm 3.x) arabirimi, 6.0 Gb/s'de çalışan üçüncü nesil SATA arabirimleridir. Arayüz tarafından desteklenen bant genişliği 600 MB/sn'dir. Bu arabirim, SATA II -3Gb/s arabirimiyle geriye dönük olarak uyumludur.

SATA II'nin bant genişliği yalnızca 300 MB / s'dir, bu bir HDD için oldukça yeterlidir, ancak kesinlikle günümüzün SSD'leri için değildir.

Bir SSD'nin potansiyelini açığa çıkarmak için en az 600 MB/s bant genişliğine sahip bir arayüze, yani SATA III'e ihtiyacınız var.

Ama merak etmeyin, 2010'dan sonra bir PC veya sunucu aldıysanız, büyük ihtimalle stokta vardır. (Aksi takdirde anakartı değiştirmeniz gerekir).

Bu arada, dikkatinizi farklı üreticilerin (aynı anakartta) SATA III denetleyicilerine, örneğin Intel ve Marvell'e çekmek istiyorum, burada birincisi hız açısından önemli ölçüde kazanabilir. (Aslında geçen gün buna kendim de ikna oldum. Intel'in yüzde 35'e varan oranlarda daha hızlı olduğu ortaya çıktı).

Elbette SATA III, bir SSD sürücüsü ile iletişim kurmak için tek arayüz değildir.

"Katı hal" geliştiricileri, SATA III - 600 MB / s'nin verimine dayandı ve SATA Express, M.2, mSATA, PCI Express bağlantı arayüzleri ile piyasaya yeni cihazlar sundu.

Zaten tamamen farklı hızlar var:

PCI Express x2 2.0 8Gb/sn (800MB/sn)

SATA Express 10 Gb/sn (1000 MB/sn)

PCI Express x4 2.0 16 Gb/sn (1600 MB/sn)

PCI Express x4 3.0 32Gb/sn (3200MB/sn)

Ne yazık ki, şimdi bu cihazlar çok paraya mal oluyor ve böyle bir çözümü bütçe olarak adlandırmak zor.

SSD'nizi daha da hızlandırmak için, SSD'nin hızını iki katına çıkaracak iki sürücüden oluşan bir RAID 0 oluşturabilirsiniz.

Ancak bir SSD'den daha hızlı ne olabilir?

Tabii ki RAM!

Buradaki hızlar HDD, RAID veya SSD ile karşılaştırılamaz.

RAM'in bir parçası olmanın ve ondan bir disk oluşturmanın yolları (özel yazılım) vardır.

Şimdi "RAM" 5 yıl öncesine göre çok daha ucuz ve "karttaki" birçoğunun zaten 8-16 veya daha fazla GB RAM'i var.

İşin püf noktası, gerekli boyutu tahsis etmektir (1C tabanının altında, hız ve boyut izin veriyorsa, tüm platformu bu diske itin.).

yol dedim zaten "aşırı" nedenini görmek zor değil.

Aniden sistemde bir arıza olursa, veritabanını ve bu diskte olacak her şeyi hemen kaybedersiniz!

Tabii ki, bir RAM disk üzerinde bulunan 1C'de gerçekten çalışmak için sunucu donanımına, sunucu RAM'ine, kesintisiz güç kaynaklarına ve güvenilir donanıma ihtiyacınız var. (anakart, işlemci vb.)

+ sık yedeklemeler.

Daha sonra tabiki 1C'de bu şekilde çalışabilirsiniz.

Peki ya böyle bir “demir” yoksa, bütçe çözümleriyle ilgileniyoruz?

O zaman neden 1C'nin çalışmasını bir RAM diskinde sökün?

Fayda arkadaşlar!, Elbette, 1C'deki kullanıcıların sürekli çalışması için değil, çeşitli rutin işlemleri gerçekleştirmek için.

Çok sayıda belge, dizin ve diğer her şeyle ilişkili ayı kapatma, yeniden planlama, silme, "temel kesme" (diğer benzer işler).

Bu operasyonların çoğu günler alabilir! Oysa RAM'de birkaç saat!

Örneğin, kullanıcılarınız bir web tarayıcısı aracılığıyla 1C'de çalışıyorsa, tamamen RAM'e yerleştirilebilir, bu, kullanıcının web üzerinden 1C'deki çalışmasını önemli ölçüde hızlandıracaktır.

Başka bir deyişle, işlemi hızlandırmak için 1C'de çeşitli ağır işlemleri gerçekleştirmek için RAM diskini geçici olarak kullanabilir ve ardından tabanı SSD veya HDD'ye geri döndürebilirsiniz.

Bu iyi bir numara, kullanabilirsin!

Yukarıdaki disk sistemlerinde 1C dosyasının gerçek testini başlatmak için RAM diski dışında hemen hemen her şey hazır.

Hadi onu yaratalım!

Ücretsiz program "Dataram RAMDisk" bize yardımcı olacak

Ücretsiz sürümü 4 GB'lık bir disk oluşturmak için yeterli olacaktır. (Daha fazla - ödenen ~21$).

LinkedIn grubu “Depolama Uzmanları” (bu arada, LinkedIn'deki tartışma gruplarının varlığına dikkat etmenizi öneririm, ilginç olabilir) bir haftadır konuyu tartışıyor:
SSD sürücüleri arıza oranları
Oradan bazı alıntılar, her şey açık olduğu için tercüme etmeden vereceğim (her paragraf bu konudaki bireysel bir kişinin mesajından alıntıdır).
Ortabatıda bir bankada müteahhit olarak çalışıyorum ve yaklaşık 9 aydır EMC VMAX'lerde SSD'lerimiz var. Henüz bir başarısızlık görmedik
Bir keresinde, çeşitli satıcıların SSD'lerini yakmak için çok haftalık bir girişimde bulundum. Onları yaklaşık bir ay boyunca %100 rastgele yazılarla çalıştırdım. Füzyon IO'lar sürücü başına 30k IOP gibi bir değerde, STEC'ler / Intel'ler yaklaşık 7k. Hiçbirini başarısızlığa uğratmayı asla başaramadı.
Fusion IO, o ay, tek bir SAS sürücüsünün on yıldan fazla bir sürede yapabileceği kadar çok yazı yazdı.

Yaklaşık 150 SSD sürücümüz var ve son 12 ayda 1 arıza gördük.
SSD'leri bir cx4-960 clariion'da 12 aydan kısa bir süredir hatasız kullanıyorum (büyük ms sql tempdb'yi kapsıyor).
Kendi deneyimlerime göre (ilk olarak 2 buçuk yıl önce sevk edilen SSD sistemleri), SLC SSD arıza oranı dönen sürücülerle aynı aralıkta.

Bu kadar. Hala SSD kaynağının yazmak için olduğuna inananlar için düşünecek bir şey var. çok sınırlı SSD'nin güvenilmez olduğunu ve çalışırken Enterprise Flash Sürücülerinin yanmış bir Çin USB flash sürücüsü gibi öldüğünü Kingston.

Dosya modunda 1C performansı sorunu, özellikle ekipmana önemli yatırımlar yapamayan küçük firmalar için oldukça akut. Bununla birlikte, uygulamanın "iştahı" yalnızca sürümden sürüme büyüyor ve makul bütçe maliyetleriyle performansı artırma görevi giderek daha acil hale geliyor. Bu durumda, temelleri bir SSD'ye satın almak ve yerleştirmek iyi bir çözüm olacaktır.

Küçük bir muhasebe firması olan müşterilerimizden biri, 1C:Enterprise'ın yavaş performansından şikayet etmeye başladı. Aslında uygulamanın çok hızlı olmayan işleyişi, Muhasebe 2.0'dan Muhasebe 3.0'a geçişten sonra oldukça kasvetli hale geldi.

Core i3 2120, 8 GB RAM'de, her biri aynı anda iki veya üç tabanla çalışan üç ila altı kullanıcıya hizmet veren iki Western Digital RE4'ten oluşan bir RAID 1 disk dizisine sahip basit bir terminal sunucusu vardı.

Performans analizi hemen bir darboğaz ortaya çıkardı - disk alt sistemi (ekran görüntüsü SSD'yi kurduktan sonra çekildi, bu nedenle RAID dizisi C: ve E: mantıksal sürücülerini içerir).

Basit hesaplamalar, bir bilgi bankasının başlatılmasının bile dizinin performansını neredeyse tamamen kullandığını gösterdi, mevcut okuma/yazma oranında yaklaşık 150 IOPS - iki ayna için gerçek sınır en hızlı disk değil. Dolaylı olarak sıranın boyutunu gösteren şey.

Çalışma gününün başında birkaç veritabanının aynı anda başlatılması, sunucunun önemli ölçüde yavaşlamasına ve sistem yanıt hızının azalmasına neden oldu. Ayrıca dergilerle çalışırken, raporlar oluştururken vb.

Dizi performans testi de düşük bir sonuç gösterdi, günümüz standartlarına göre taşınabilir sürücüler için daha uygun.

Disk alt sisteminin yükseltilmesi gerektiği ortaya çıktı. Ön tahminlere göre bile, yığın HDD'lere dayalı üretken bir dizinin oluşturulması, hem uygun bütçe hem de donanımın fiziksel yetenekleri ile sınırlıydı, bu durumda gerekli sayıda SATA bağlantı noktası ve disk kafesi yoktu. Bu nedenle SSD almaya karar verildi.

Yüksek disk yükleri öngörülmediğinden, seçim öncelikle fiyat nedenleriyle yapıldı. Darboğaz SATA-II arayüzü olduğu için hız özellikleri de arka plana kayboldu. Sonuç olarak satın alındı 128Gb Corsair Neutron LAMD, sunucuya kurulduğunda aşağıdaki hız özelliklerini gösteren:

Gördüğünüz gibi, sıralı erişim işlemleri beklendiği gibi arayüz bant genişliğine ulaştı, ancak bizim durumumuzda bu ikincil öneme sahip. Ana dikkat, geleneksel HDD'lerden çok daha üstün olan rastgele erişim işlemlerine verilmelidir.

Karar verilmesi gereken bir sonraki soru, SSD'yi yansıtmak ve hata toleransı için TRIM'i feda etmek mi yoksa tek bir sürücü olarak bırakıp hata toleransı yerine hızı mı tercih etmek. Modern SSD'lerin, TRIM komutuna ek olarak, çöp toplama gibi kendi bozulma önleme teknolojilerini kullandıkları ve TRIM'siz sistemlerde bile oldukça verimli çalışmalarına izin verdiği belirtilmelidir. Bu seride kullanılan LAMD (Link_A_Media Devices) SSD denetleyicisi, kurumsal düzeydeki sürücüler düzeyinde çok verimli çöp toplama teknolojileriyle aynıdır; bu, geliştiricileri bir süredir kurumsal segmentte çalıştığı için genel olarak şaşırtıcı değildir. uzun zaman.

Günlük olarak girilen belge hacmi küçük olduğundan, kendimizi zorunlu günlük yedeklemeleri olan tek bir SSD ile sınırladık. Dolaylı olarak, katı hal sürücüsü kullanmanın etkisi performans izleyicisi tarafından değerlendirilebilir:

Kuyruk uzunluğu bir taneyi geçmezken, G / Ç işlemlerinin sayısı ve diskle değişim hızı önemli ölçüde arttı. Bunlar çok iyi göstergeler, eylemlerimizin doğrudan 1C:Enterprise ile çalışmayı ne kadar hızlandırdığını kontrol etmeye devam ediyor.

Bunu yapmak için, bilgi bankasının yüklenme süresini ve belirli bir süre boyunca bir dizi belgenin grup halinde yeniden gönderilme süresini ölçtüğümüz küçük bir ekspres test gerçekleştirdik. Test sırasında yapılandırma kullanıldı 1C: Muhasebe 3.0.27.7 platformda 8.3.3.721 .

Ayrıca, performans analizi sırasında, 1C:Enterprise'ın çalışmasında, bizim durumumuzda sabit sürücüde bulunan geçici klasörleri aktif olarak kullandığına dikkat ettik. Bu nedenle, maksimum performans elde etmek için SSD'ye de aktarılmalıdır, ancak katı hal sürücülerinin kaynağını korumak isteyenler için teste her iki seçeneği de dahil ettik: veritabanları SSD'de bulunduğunda ve HDD'deki geçici klasör ve uygulama SSD tarafından tamamen kullanıldığında.

Gördüğünüz gibi, bilgi tabanlarının SSD'ye aktarılması, yükleme sürelerini anında yarıdan fazla azalttı ve aktarım yaklaşık %30 hızlandı. Aynı zamanda, ortak çalışma sırasında üretkenlik düşüşü sorunu tamamen ortadan kalktı.

Geçici klasörleri SSD'ye aktarmak, yükleme süresini üçte birden fazla azaltmanıza ve belgelerin hızını yaklaşık olarak iki katına çıkarmanıza olanak tanır. Disk kaynaklarını korumanın sadık taraftarları için bile düşünülmesi gereken bir şey var. Bu konudaki düşüncemiz şu şekilde, SSD aldıysanız sonuna kadar kullanmalısınız.

Küçük bir inceleme yapalım. kullandığımız disk Korsan Nötron sahip kaynak 2-3K silme/yazma döngüsü. Basit hesaplamalar, her gün tüm disk kapasitesinin üzerine tamamen yazılırsa, kaynağın tüketilmesinin 5-8 yıl süreceğini göstermektedir. Ek olarak, istatistikler, garanti süresi boyunca SSD arızasının ana nedeninin kaynağın tükenmesi ile ilgili olmadığını, üretim hatası veya bellenimdeki hatalar olduğunu göstermektedir.

Sonuç olarak, günümüzde SSD kullanımının dosya modunda 1C:Enterprise'ın performansını önemli ölçüde artırmanın belki de tek etkili yolu olduğunu söylemek isterim. Ve en önemlisi, küçük işletmeler için bile uygun fiyatlı.