05.04.2017 |

Küme 1C 8.3

Öncelikle 1C kümesini kurduktan sonra iş akışları oluşturmak gerekiyordu. Anlaşıldığı üzere veritabanının yüküne bağlı olarak küme süreçleri otomatik olarak oluşturulmaya başlandı.

Ana veritabanının arka plan işlerinin bir test çalıştırması, 1C kümesinin rphost.exe'yi sonsuz şekilde aşırı yüklemesine ve ek rphost.exe'nin oluşturulmak istememesine neden oldu. Ayarları inceledikten sonra her şey netleşti.

Maksimum İş Akışı Belleğiçalışan süreçlerin birlikte kullanabileceği bellek miktarıdır. Bayt cinsinden ölçülen parametreyi ayarlarken çok dikkatli olmanız gerekir. Yanlış değeri ayarlarsanız (normal kullanıcı işlemi için yetersiz), kullanıcılar "1C sunucusunda yeterli boş bellek yok" hatasını alırlar. Bu hatayı 1C sunucusundaki bellek kotası dolduğunda da alabilirsiniz.

Arama başına güvenli hafıza tüketimi- bir sunucu çağrısı sırasında bayt cinsinden ölçülen bellek tüketimini kontrol etmenizi sağlar. Bir çağrı beklenenden daha fazla bellek kullanıyorsa, bu çağrı, alt işlemi (rphost.exe) yeniden başlatmadan 1C kümesi içinde tamamlanacaktır. Buna göre sunucu çağrısını yapan "kaybeden", diğer kullanıcıların çalışmalarını etkilemeden 1C veritabanındaki oturumunu kaybedecek.

bir GB - 1073741824 Bayt, dolayısıyla 2 GB - 2147483648 Bayt

Sunucunun üretken kabul edildiği iş süreçleri için bellek miktarı - bu parametre aşılırsa, 1C kümesindeki sunucu yeni bağlantıları kabul etmeyi durduracaktır.

İşlem başına bilgi güvenliği sayısı- iş süreçleri için bilgi tabanlarını izole etmenize olanak tanır. Varsayılan olarak mevcut 1C kümesi "8" olarak ayarlandı, ancak birkaç saatlik çalışma boyunca sunucu çok kararsız hale geldi ve kullanıcı oturumları dondu. Her bilgi tabanını izole ettikten sonra (değer - "1") sorunlar ortadan kalktı.

İşlem başına bağlantı sayısı- varsayılan değer "128"dir. Mevcut veri tabanında arka plan görevlerinin (lojistik hesaplamalar, fiyat listesi analizi, rakip analizi vb.) çok büyük bir yükü olduğundan bu sayının “25”e düşürülmesine karar verildi.

1C kümesinin ayarları biraz değişti:

Hata toleransı seviyesi- bu, aynı anda arızalanabilecek çalışan sunucuların sayısıdır ve bu, kullanıcıların anormal şekilde sonlandırılmasına yol açmaz. Yedekleme hizmetleri, belirtilen hata toleransını sağlamak için gereken miktarda otomatik olarak başlatılır. Gerçek zamanlı olarak etkin hizmet, yedek hizmetlere kopyalanır.

Paylaşım modunu yükle- parametre için iki seçenek vardır: "Performansa göre öncelik" - daha fazla sunucu belleği harcanır ve performans daha yüksektir, "Belleğe göre öncelik" - 1C kümesi sunucu belleğinden tasarruf sağlar.

Sunucu 8.3, yeni tasarlanmış bir dahili kodla karakterize edilir, ancak "dışarıdan" biraz değiştirilmiş bir 8.2 gibi görünebilir.

Sunucu daha "otomatik olarak yapılandırılabilir" hale geldi; çalışan süreçlerin sayısı gibi bazı parametreler artık manuel olarak oluşturulmuyor, hata toleransı ve güvenilirlik görevlerinin gereksinimlerinin tanımlarına göre hesaplanıyor.

Bu, sunucunun yanlış yapılandırılması olasılığını azaltır ve yöneticilerin yeterlilik gereksinimlerini azaltır.

Bir bütün olarak sistemin performansını artırmak veya yapılandırmanın zor olduğu durumlarda "sınırlı bellekle" çalışmanıza olanak tanıyan yeni bir "bellek tasarrufu" modunu kullanmak için kullanılabilecek bir yük dengeleme mekanizması geliştirilmiştir. "Hafızayı yemeyi sever."

Büyük miktarda bellek kullanıldığında işlemin kararlılığı, üretim sunucusunun yeni parametreleriyle belirlenecektir.

"Çağrı başına güvenli bellek tüketimi" parametresi özellikle ilgi çekicidir. Ne olduğu hakkında çok az fikri olanlar için “üretken” bir temelde antrenman yapmamak daha iyidir. "Çalışma süreçlerinin maksimum bellek boyutu" parametresi, "taşma" durumunda tüm çalışma sürecinin çökmesine değil, "kaybedenle" yalnızca bir oturumun çökmesine olanak tanır. "Sunucunun üretken kabul edildiği çalışma süreci belleği miktarı", bu bellek eşiği aşıldığında yeni bağlantıları engellemenize olanak tanır.

İş süreçlerinin bilgi tabanına göre yalıtılmasını, örneğin "İşlem başına bilgi güvenliği sayısı = 1" parametresinin belirtilmesini öneririm. Çok sayıda yüksek yüklü veritabanı söz konusu olduğunda bu, hem güvenilirlik hem de performans açısından karşılıklı etkiyi azaltacaktır.

Lisansların/anahtarların “harcamaları” sistemin istikrarına ayrı bir katkı sağlar. 8.3'te "aladin" yöneticisini anımsatan bir "yazılım lisans yöneticisi" kullanmak mümkün hale geldi. Amaç, anahtarı ayrı bir makineye yerleştirebilmektir.

Küme yöneticisinde başka bir “hizmet” olarak uygulanır. Örneğin "ücretsiz" bir dizüstü bilgisayar kullanabilirsiniz. 1C 8.3 kümesine ekleyin, “lisanslama hizmeti” hizmetiyle üzerinde ayrı bir yönetici oluşturun. Dizüstü bilgisayarınıza bir donanım karma anahtarı takabilir veya yazılım lisanslarını etkinleştirebilirsiniz.

Programcıların en çok ilgisini çeken konu “İşlevsellik Atama Gereksinimleri” olmalıdır.

1c'nin atanan işlevselliğine ilişkin gereksinimler

Bu nedenle, güvenlik anahtarı olan bir dizüstü bilgisayarda, kullanıcıları küme sunucusunda başlatmamak için, "Bilgi güvenliğine istemci bağlantısı" - "Atama" gereksinim nesnesi için "gereksinimler" eklemeniz gerekir, yani. Bu sunucudaki çalışan işlemlerinin istemci bağlantılarını işlemesini önleyin.

Daha da ilginci, kullanıcı oturumları olmadan kümenin üretim sunucusunda "yalnızca arka plan işlerini" çalıştırabilme yeteneğidir. Bu şekilde çok yüklü görevleri (kod) ayrı bir makineye taşıyabilirsiniz. Ayrıca, bir bilgisayarda "Ek parametrenin değeri"ni kullanarak "ayı kapatma" arka plan görevini çalıştırabilir ve diğer bilgisayarda "Tam metin dizinini güncelleme" arka plan görevini "Değeri" göstergesiyle gerçekleştirebilirsiniz. ek bir parametre”. Örneğin, değer olarak Arka PlanJob.CommonModule'ü belirtirseniz, kümedeki çalışan sunucunun çalışmasını yalnızca herhangi bir içeriğe sahip arka plan işleriyle sınırlayabilirsiniz. ArkaplanJob.CommonModule değeri.<Имя модуля>.<Имя метода>- belirli bir kodu gösterecektir.

Küme 1C 8.2

Oturumlar, yönetilen bir uygulama içinde yük dengelemeye ve hata toleransına olanak tanır.

Küme yöneticisi artık daha karmaşık hale geldi. Artık bazı işlevler ayrı bir işleme ayrılabilir ve hatta kümedeki başka bir çalışan sunucuya yerleştirilebilir. Bu, sunucu yükünü dengelemenizi sağlar.

Sunucu 8.2 hata toleransı şu yollarla sağlanır:

• Kullanıcının oturumuyla ilgili bilgilerin saklanması.
• Kullanıcı artık iş akışına bağlı değildir.
• Bir kümedeki iş süreçlerinin rezervasyonu.
• Yedekli olanlar da dahil olmak üzere çeşitli çalışan süreçleri olmalıdır
• Küme rezervasyonu.

Yedek bir küme belirtilir; bağlandığında bağlantı satırında listelenir.

Bu, işin sürekliliğini sağlamanıza olanak tanır!

Müşterinin kümeyle fiziksel bağlantısı kopmuşsa (temizlikçi kadın kabloyu çıkarmış, ağ ekipmanına giden güç kapatılmış, sağlayıcıda bir sorun olmuşsa), bilgi tabanına yeniden bağlanıp tüm işlemleri başlatmaya gerek yoktur. iş yeniden başlıyor. Fiziksel bağlantı yeniden sağlandıktan sonra kullanıcı, kesildiği yerden çalışmaya devam edebilir.

Küme bilgisayarlarının bakımı gerekiyorsa, kullanıcıların bilgi tabanı ile çalışmasını engellemeden çalışma sırasında kapatılabilirler.

Kümedeki herhangi bir sunucunun arızalanması durumunda kullanıcının çalışması durmaz; otomatik olarak yedekleme kümesine ve/veya yedekleme iş süreçlerine aktarılır. Kullanıcılar için böyle bir geçiş görünmez olacaktır.

Kümenin çalışan süreçlerinden biri başarısız olursa, kümeye bağlanan kullanıcılar otomatik olarak diğer veya yedek çalışan süreçlere aktarılacaktır. Böyle bir geçiş kullanıcılar tarafından da görülmeyecek.

PEKİ KÜME 1C 8.3'TE NELER DEĞİŞTİ:

Öncelikle 1C kümesini kurduktan sonra iş akışları oluşturmak gerekiyordu. Anlaşıldığı üzere,küme süreçleriVeritabanının yüküne göre otomatik olarak oluşturulmaya başlandı.

Ana veritabanının arka plan işlerinin test çalışması, 1C kümesinin rphost.exe'yi sonsuz şekilde aşırı yüklemesine ve ek rphost.exe'nin oluşturulmak istememesine neden oldu. Ayarları inceledikten sonra her şey netleşti.

Maksimum İş Akışı Belleği çalışan süreçlerin birlikte kullanabileceği bellek miktarıdır. Ölçülen parametreyi ayarlarken çok dikkatli olmanız gerekir. bayt. Yanlış değeri ayarlarsanız (normal kullanıcı işlemi için yetersiz) kullanıcılar bir hata atılacak"1C sunucusunda yeterli boş bellek yok". Bu hatayı 1C sunucusundaki bellek kotası dolduğunda da alabilirsiniz.

Arama başına güvenli hafıza tüketimi- bir sunucu çağrısı sırasında ölçülen bellek tüketimini kontrol etmenizi sağlar. bayt. Bir çağrı beklenenden daha fazla bellek kullanıyorsa, bu çağrı, alt işlemi (rphost.exe) yeniden başlatmadan 1C kümesi içinde tamamlanacaktır. Buna göre sunucu çağrısını yapan "kaybeden", diğer kullanıcıların çalışmalarını etkilemeden 1C veritabanıyla olan oturumunu kaybedecek.

Sunucunun üretken kabul edildiği iş süreci belleği miktarı- en Bu parametre aşılırsa 1C kümesindeki sunucu yeni bağlantıları kabul etmeyi bırakacaktır.

İşlem başına bilgi güvenliği sayısı- iş süreçleri için bilgi tabanlarını izole etmenize olanak tanır. Varsayılan olarak mevcut 1C kümesi şu şekilde ayarlandı:- "8", ancak birkaç saatlik çalışma sırasında sunucu çok kararsız hale geldi, kullanıcı oturumları dondu. Her bilgi tabanını izole ettikten sonra (değer- "1") sorunlar ortadan kalktı.

İşlem başına bağlantı sayısı- varsayılan değer "128"dir. Mevcut veri tabanında arka plan görevlerinin (lojistik hesaplamalar, fiyat listesi analizi, rakip analizi vb.) çok büyük bir yükü olduğundan bu sayının “25”e düşürülmesine karar verildi.

1C kümesinin ayarları biraz değişti:

Hata toleransı seviyesi- Bu Kullanıcıların çökmesine neden olmadan aynı anda arızalanabilecek çalışan sunucuların sayısı. Yedekleme hizmetleri, belirtilen hata toleransını sağlamak için gereken miktarda otomatik olarak başlatılır. Gerçek zamanlı olarak etkin hizmet, yedek hizmetlere kopyalanır.

Paylaşım modunu yükle - parametre için iki seçenek vardır: "Performansa göre öncelik" - daha fazla sunucu belleği harcanır ve performans daha yüksektir, "Belleğe göre öncelik" - 1C kümesi sunucu belleğinden tasarruf sağlar.

Sonsöz yerine. 1C 8.3 kümesi fark edilir derecede daha hızlı ve daha güvenilir çalışır, bilgi tabanı ile bir kullanıcı oturumu oluşturmak birçok kez daha hızlıdır, 1C 8.2.16 ile uyumluluk modundaki arayüzün uçtuğu söylenebilir. Elbette nüanslar var ama onlar olmasaydı biz nerede olurduk? Yeni 1C 8.3 kümesinin kurulumunda iyi şanslar.

Yapılandırılmış kümeye ait tüm sunucuların ayarlarından küme ayarlarının sorumlu olduğunu lütfen unutmayın. Bir küme, aynı bilgi veritabanları ile çalışan birden fazla fiziksel veya sanal sunucunun çalışmasını içerir.

Yeniden başlatma aralığı– küme çalışanı işlemlerinin yeniden başlatılmasının sıklığından sorumludur. Bu parametre, sunucu günün her saati çalışırken ayarlanmalıdır. Yeniden başlatma sıklığının küme bilgi tabanlarının teknolojik döngüsüyle ilişkilendirilmesi önerilir. Tipik olarak bu her 24 saatte birdir (86400 saniye). Bildiğiniz gibi 1C sunucularının iş süreçleri iş verilerini işler ve saklar.

Otomatik yeniden başlatma, "iş akışlarındaki parçalanma ve bellek sızıntılarının olumsuz etkilerini en aza indirmek için" platformda tasarlandı. ITS, diğer parametrelere (bellek boyutu, kullanılan kaynaklar vb.) dayalı olarak iş süreçlerinin yeniden başlatılmasının nasıl organize edileceğine dair bilgilere bile sahiptir.

İzin verilen bellek boyutu– 1C sunucularını belleğin aşırı kullanımına karşı korur. Süreç bu hacmi aşarsa izin verilen hacmi aşma aralığı, süreç yeniden başlatılır. Sunucu yükünün yoğun olduğu dönemlerde "rphost" işlemlerinin kapladığı maksimum bellek boyutu olarak hesaplanabilir. İzin verilen hacmi aşmak için küçük bir aralık ayarlamaya da değer.

Sunucu hatası sayısında izin verilen sapma. Platform, 5 dakika içinde sunucuya yapılan çağrı sayısına göre ortalama sunucu hatası sayısını hesaplar. Bu oran izin verilen değeri aşarsa, iş akışı "sorunlu" olarak kabul edilir ve bayrak ayarlandığında sistem tarafından sonlandırılabilir. “Sorunlu süreçleri zorla sonlandırın.”

Daha sonra devre dışı bırakılan işlemleri durdurun.İzin verilen bellek miktarı aşılırsa, çalışan süreç hemen sonlandırılmaz, ancak "kapalı" hale gelir, böylece çalışan verileri kayıpsız yeni çalışan alt sürece "aktarmak" için zaman olur. Bu parametrenin belirtilmesi halinde, bu süre geçtikten sonra “kapatma” işlemi her halükarda sona erecektir. 1C sunucusunun çalışmasında "donmuş" iş süreçlerini gözlemlerseniz, bu parametreyi 2-5 dakikaya ayarlayabilirsiniz.
Bu ayarlar her 1C sunucusu için ayrı ayrı ayarlanır.

Maksimum İş Akışı Belleği– bu hacim Toplam geçerli kümedeki çalışan işlemler (rphost) tarafından doldurulabilen bellek. Parametre “0” olarak ayarlanırsa sunucu RAM'inin %80'ini kaplar. “-1” - kısıtlama yok. Bir DBMS ve 1C sunucusu aynı sunucuda çalışırken, RAM'i paylaşmaları gerekir. Çalışma sırasında DBMS sunucusunun yeterli belleğe sahip olmadığı ortaya çıkarsa, bu parametreyi kullanarak 1C sunucusuna ayrılan belleği sınırlayabilirsiniz. DBMS ve 1C sunucular tarafından ayrılmışsa, bu parametreyi aşağıdaki formülü kullanarak hesaplamak mantıklıdır:

“Maksimum hacim” = “Toplam RAM” – “İşletim Sistemi RAM'i”;

“OS RAM”, her 16 GB sunucu RAM'i için 1 GB prensibine göre hesaplanır

Arama başına güvenli hafıza tüketimi. Genel olarak, bireysel çağrılar bir çalışan işlemine ayrılan RAM'in tamamını kaplamamalıdır. Parametre "0" olarak ayarlanırsa güvenli akış hızı "" değerinin %5'ine eşit olacaktır. Çalışma süreçleri için maksimum bellek kapasitesi". “-1” - sınırlama olmaksızın, kesinlikle tavsiye edilmez. Çoğu durumda bu parametreyi “0” olarak bırakmak daha iyidir.

Parametrelerin kullanılması “İşlem başına bilgi güvenliği sayısı” ve “İşlem başına bağlantı sayısı” 1C sunucu çalışmasının iş süreçleri arasındaki dağılımını kontrol edebilirsiniz. Örneğin, her bilgi tabanı için ayrı bir "rphost" çalıştırın, böylece işlem çökmesi durumunda yalnızca bir veritabanının kullanıcılarının bağlantısı kesilir. Bu parametreler her sunucu konfigürasyonu için ayrı ayrı seçilmelidir.

DBMS sunucusu tarafından RAM kullanımına ilişkin sınırlama– MS SQL DBMS sunucusunun dikkate değer bir özelliği vardır; aktif olarak çalıştığı veritabanlarını tamamen RAM'e yüklemeyi sever. Eğer sınırlamazsanız, alabileceği tüm RAM'i alacaktır.

• 1C:Enterprise sunucusu Microsoft SQL Server ile birlikte kurulursa, üst bellek eşiği 1C sunucusunun çalışması için yeterli miktarda azaltılmalıdır.
• Sunucuda yalnızca DBMS çalışıyorsa, o zaman DBMS için aşağıdaki formüle göre:

“DBMS belleği” = “Genel RAM” – “İşletim Sistemi RAM'i”;

Paylaşılan hafıza– bu parametre hakkında çok şey biliniyor, ancak yine de insanlar bunu unutuyor. 1C sunucusu ve DBMS aynı fiziksel veya sanal sunucuda çalışıyorsa bunu “1” olarak ayarlıyoruz. Bu arada 8.2.17 platformundan itibaren çalışıyor.

Maksimum paralellik derecesi– bir istek yürütülürken kaç işlemcinin kullanılacağını belirler. DBMS, birden fazla iş parçacığı üzerinde karmaşık sorgular yürütülürken veri alımını paralelleştirir. 1C için, tek bir iş parçacığında "1" olarak ayarlanması önerilir.

Veritabanı dosyalarının otomatik olarak genişletilmesi- veritabanı dosyasının “genişletildiği” adımı MB cinsinden belirleriz. Adım küçükse, veritabanının aktif büyümesiyle birlikte sık genişletmeler disk sistemi üzerinde ek yüke yol açacaktır. 500 – 1000 MB olarak ayarlamak daha iyidir.

Dizinleri yeniden indeksleme ve birleştirme– haftada en az bir kez birleştirmeniz/yeniden indekslemeniz önerilir. Yeniden indeksleme tabloları kilitler, bu nedenle çalışma saatleri dışında veya minimum yük dönemlerinde çalıştırmak en iyisidir. Dizini yeniden oluşturduktan (yeniden indeksleme) sonra birleştirme yapmanın bir anlamı yoktur. Microsoft'un önerisine göre dizin parçalanması %30'u geçmiyorsa birleştirme yapılır. Daha yüksekse, yeniden indekslenmesi önerilir.

Güç planı– işletim sisteminin güç ayarlarını yüksek performansa ayarlayın.

Zafer kolay olmadı...
Üzerinden epey zaman geçmesine rağmen her şeyi ayrıntılı olarak anlatmaya çalışacağım. Umarım topladığım bilgiler sistem yöneticilerine yardımcı olur ve bana düşünecek bir şeyler verir.
Veritabanlarını 1 okula taşıdım ve kullanıcıyı 8.3 aracısı için yeniden atadım - bunun bir faydası olmadı...

RuNet'imizi baştan başa dolaştım ve iki ilginç makale buldum, sizin de okumanızı öneririm.

İlk kez iki platform arasında oldukça ayrıntılı bir test: PS orta sürümü ve çift çekirdekli sunucu. Başka firmalarda çalışırken benim de vurguladığım çok ilginç noktalar ortaya çıkıyor.
efsol.ru/articles/tuning-1c.html

İkincisi sanal makinelerdeki 1c testleriyle ilgilidir. Yapılandırmanın başlatılmasındaki gecikmenin nedenini burada gördüm:
efsol.ru/articles/performans-comparison-1c.html

Yaklaşık bir hafta kadar araştırıp birkaç yöntem denedikten sonra ilk çalıştırmada sorunu çözemedim. Ama bir ilginç model fark ettim... İnce istemci çalışırken, sistemin ikinci başlatılması neredeyse anında gerçekleşir. İşlem başına bilgi güvenliği sistemi sayısına ilişkin ayarları değiştirdim: 8 (şu ana kadar 8.3 temel alınarak 5). Sonuç olarak, sunucu ize girerken RPHOST oluşturarak zaman kaybetmeyi bıraktığından beri. üssü ve geri kalanını yalnızca konferansı sızlanmaktan kurtarmak için harcadı. İkinci kalenin başlama süresi 10-7 saniye kısaltıldı.

Prensip olarak, her veritabanında 7-10 kullanıcının çalıştığı, conf'un RPHOSTe'de sürekli tutulduğu ve oturum açma süresinin birlikte kimlik doğrulamayla birlikte 4-8 saniye olduğu göz önüne alındığında, bu seçenek bana tamamen uyuyor.

Veritabanının sık açılmaması gibi sorunlar yaşıyorsanız, bir seçenek olarak küçük bir kayıt defterini kesmenizi önerebilirim. kullanıcı giriş görevi her veritabanına ekleyin ve hizmeti akşam yeniden başlatılacak şekilde yapılandırın (hizmetler veya yeniden başlatma aralığı yoluyla). Bunun yardımcı olacağını düşünüyorum, ancak burada bir lisansın mevcudiyeti ile sınırlıyız, bu yüzden düşünmeliyiz)))

Ancak forumlardan birinde şu cevabı aldığım başka bir hoş olmayan an daha ortaya çıktı:
Üstü kapalı. CORP lisanslarınız var mı?

CORP düzeyi sunucu "1C:Enterprise 8.3"ün 64 bit PROF düzeyi sunucuyla karşılaştırıldığında gelişmiş yetenekleri:
* arama başına güvenli hafıza tüketimi;
* işlem başına bilgi güvenliği sayısı;
* sunucunun üretken kabul edildiği iş süreçlerine ilişkin bellek miktarı;
* çalışma süreçlerinin maksimum hafıza kapasitesi;
*dengeleme stratejisi (bellek, performans);

Listelenen işlevlerin PROF düzeyindeki “1C:Enterprise 8. Sunucu Lisansı (x86-64)” ürünleri, yani adında CORP adı bulunmayan ürünler kullanılarak kullanılması yasa dışıdır.

Üç farklı şirketten adamların kurumsal ve profesyonel bir platform olup olmadığını kontrol etmeye karar verdim. Bunun cevabını tapınakta dönen bir parmak ve 1c forumuna gönderme şeklinde aldı. Ve aşağıda 1c desteğinden gelen yanıt var:

1) >>> 8.3 Corp ve 8.3 Prof platformu arasındaki farklara açıklık getirmek istiyorum.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

Aslında PROF Platformunu kullanırken lisansa göre yalnızca varsayılan küme ayarlarını kullanabilirsiniz.

"Varsayılan" küme ayarlarıyla ilgili sorunlarla karşılaşırsanız (bellek eksikliği, yapılandırmanın güncellenememesi vb.),
bu davranış bir hatadır (platformdan veya bu uygulama çözümünden).
Lütfen spesifik örneklerle düzeltme talepleri oluşturun.
Hata düzeltilirken, Corp. lisansının işlevselliğini kullanmak için yazılı olarak (JSC 1C yöneticisi tarafından imzalanmış) izin verilebilir.
2) >>> Lütfen açıklığa kavuşturun, yani. iki adet 8.3 platformu var mı?
HAYIR. Platform şu anda yalnız değil.
Ancak CORP işlevselliğini kullanma hakkı yalnızca uygun lisansın satın alınmasıyla ortaya çıkar.
Şu anda bu lisans için herhangi bir yazılım kontrolü de mevcut değildir.
Dolayısıyla CORP lisansı daha çok hukuki bir kavramdır.

Açıkçası ben çeşitli komplo türlerine inanmıyorum ama bir şirket küçük ve orta ölçekli işletme pazarında neredeyse %100 tekele sahip olduğunda aklıma farklı düşünceler geliyor.
“Raporların gönderilmesi için bir tür konfigürasyon güncellemesi olacak ve bu, yazılım kontrolünün halihazırda uygulanacağı platformun güncellenmesini gerektirecek... Ve sonra siz (1c) bize tam ödeme yapacaksınız... siz çocuklar. ”
Not: Sunucumun 2008r2 tabanlı olduğunu ve 2012'den farklılıklar olabileceğini belirtmek isterim. Yine de çekirdek detaylı olarak yeniden kesildi ve hyper-v 3.0 da büyüme için bir bonus. Ama dedikleri gibi “O Yaşıyor!!!” ve 1C'yi sanal makinelerde çalıştırmak sadece mümkün değil, aynı zamanda teşvik ediliyor. Sonuç olarak 30 8.2 kullanıcımız, 20 8.3 kullanıcımız var. Hepinize iyi şanslar, sabırlı olun ve asla pes etmeyin)))

Sunucu 8.3, yeni tasarlanmış bir dahili kodla karakterize edilir, ancak "dışarıdan" biraz değiştirilmiş bir 8.2 gibi görünebilir.

Sunucu daha "otomatik olarak yapılandırılabilir" hale geldi; çalışan süreçlerin sayısı gibi bazı parametreler artık manuel olarak oluşturulmuyor, hata toleransı ve güvenilirlik görevlerinin gereksinimlerinin tanımlarına göre hesaplanıyor.

Bir bütün olarak sistemin performansını artırmak veya yapılandırmanın zor olduğu durumlarda "sınırlı bellekle" çalışmanıza olanak tanıyan yeni bir "bellek tasarrufu" modunu kullanmak için kullanılabilecek bir yük dengeleme mekanizması geliştirilmiştir. "Hafızayı yemeyi sever."

Büyük miktarda bellek kullanıldığında işlemin kararlılığı, üretim sunucusunun yeni parametreleriyle belirlenecektir.

"Çağrı başına güvenli bellek tüketimi" parametresi özellikle ilgi çekicidir. Ne olduğu hakkında çok az fikri olanlar için “üretken” bir temelde antrenman yapmamak daha iyidir. "Çalışma süreçlerinin maksimum bellek boyutu" parametresi, "taşma" durumunda tüm çalışma sürecinin çökmesine değil, "kaybedenle" yalnızca bir oturumun çökmesine olanak tanır. "Sunucunun üretken kabul edildiği iş süreçleri için bellek miktarı", bu bellek eşiği aşıldığında yeni bağlantıları engellemenize olanak tanır.

İş süreçlerinin bilgi tabanına göre yalıtılmasını, örneğin "İşlem başına bilgi güvenliği sayısı = 1" parametresinin belirtilmesini öneririm. Çok sayıda yüksek yüklü veritabanı söz konusu olduğunda bu, hem güvenilirlik hem de performans açısından karşılıklı etkiyi azaltacaktır.

Lisansların/anahtarların “harcamaları” sistemin istikrarına ayrı bir katkı sağlar. 8.3'te "aladin" yöneticisini anımsatan bir "yazılım lisans yöneticisi" kullanmak mümkün hale geldi. Amaç, anahtarı ayrı bir makineye yerleştirebilmektir.

Küme yöneticisinde başka bir “hizmet” olarak uygulanır. Örneğin "ücretsiz" bir dizüstü bilgisayar kullanabilirsiniz. 1C 8.3 kümesine ekleyin, “lisanslama hizmeti” hizmetiyle üzerinde ayrı bir yönetici oluşturun. Dizüstü bilgisayarınıza bir donanım karma anahtarı takabilir veya yazılım lisanslarını etkinleştirebilirsiniz.

Programcıların en çok ilgisini çeken konu “İşlevsellik Atama Gereksinimleri” olmalıdır.

Bu nedenle, güvenlik anahtarı olan bir dizüstü bilgisayarda, kullanıcıları küme sunucusunda başlatmamak için, "Bilgi güvenliğine istemci bağlantısı" - "Atama" gereksinim nesnesi için "gereksinimler" eklemeniz gerekir, yani. Bu sunucudaki çalışan işlemlerinin istemci bağlantılarını işlemesini önleyin.

Daha da ilginci, kullanıcı oturumları olmadan kümenin üretim sunucusunda "yalnızca arka plan işlerini" çalıştırabilme yeteneğidir. Bu şekilde çok yüklü görevleri (kod) ayrı bir makineye taşıyabilirsiniz. Ayrıca, bir bilgisayarda "Ek parametrenin değeri"ni kullanarak "ayı kapatma" arka plan görevini çalıştırabilir ve diğer bilgisayarda "Tam metin dizinini güncelleme" arka plan görevini "Değeri" göstergesiyle gerçekleştirebilirsiniz. ek bir parametre”. Örneğin, değer olarak ArkaplanJob.CommonModule belirtirseniz, kümedeki çalışan sunucunun çalışmasını yalnızca herhangi bir içeriğe sahip arka plan işleriyle sınırlayabilirsiniz. Arka PlanJob.CommonModule..- değeri belirli kodu gösterecektir.

Belgeleri yeniden anlatmanın bir anlamı olmadığı açıktır. Ancak birisi yararlı tavsiyeler verirse makaleyi genişleteceğim.