System Center - Service Manager performansı
System Center - Service Manager sunucu rolleri ve özellikleri için performans farklı faktörlerden etkilenir. Genellikle, Service Manager'da pozitif ve negatif performansın en belirgin olduğu üç alan vardır:
Service Manager konsolu yanıt verme hızı. Bu, konsolunda bir eylem uyguladığınızda tamamlanan kadar gereken süredir.
Bağlayıcılar için veri ekleme zamanı. Bağlayıcı eşitlendiğinde Service Manager'ın verileri içeri aktarması bu kadar sürer.
İş Akışı tamamlanma zamanı. Bu iş akışlarının otomatik olarak eylem uygulaması için gereken süredir.
Bağlayıcı performansı
Bağlayıcının ilk eşitlemesi önemli ölçüde zaman alabilir; örneğin, Configuration Manager ile büyük bir ilk eşitleme için 8-12 saat. Bağlayıcı başlangıçta eşitlenirken, bu süre boyunca tüm Service Manager sunucu rolleri ve işlemleri için performansın düşmesini bekleyebilirsiniz. Bunun nedeni, verilerin Bir Microsoft SQL Server veritabanı olan Service Manager veritabanına sırayla eklenmesidir. Bağlayıcının ilk eşitleme işlemini hızlı bir şekilde tamamlayabilmenize rağmen, ilk eşitlemeyi planlayabilir ve Service Manager üretime geçmeden önce eşitleme işleminin iyi tamamlandığından emin olabilirsiniz.
İlk eşitleme tamamlandığında Service Manager, performans üzerinde ölçülebilir bir etkisi olmayan farkları eşitlemeye devam eder.
İş akışı performansı
İş akışları otomatik süreçlerdir. E-posta bildirimleri gönderme, bir sonraki adım değişiklik isteği etkinleştirme ve otomatik olarak bir şablon uygulamayı içerirler.
İş Akışı performans sorunları şunları içerir:
Normalde, iş akışları bir dakika içinde başlar ve biter. Service Manager sunucu rolleri yoğun bir iş yükü altında olduğunda, iş akışları normal kadar hızlı tamamlanmaz.
Ayrıca, bir yeni bildirim aboneliği gibi yeni iş akışları oluşturduğunuzda, sisteme ek yük yerleştirilir. Oluşturduğunuz yeni iş akışlarının sayısı arttıkça, her iş akışını çalıştırmak için için gereken zaman da artar.
Sistem ağır bir yük altında olduğunda—örneğin, çok sayıda yeni olayların oluşturuyorsa ve her olay birçok iş akışı üretiyorsa—performans olumsuz etkilenebilir.
Grup, kuyruk ve kullanıcı rolünün performans üzerindeki etkisi
Gruplar ve kullanıcı rolleri için erken planlama yapmalısınız. Grupları az sayıda oluşturmalı ve olası en küçük kapsam için oluşturmalısınız. Ardından, gruplarınızı oluşturmadan önce başlangıçta veritabanınızı Active Directory Etki Alanı Services (AD DS), Configuration Manager ve System Center Operations Manager'dan alınan verilerle doldurmanız gerekir.
Yöneticiler genellikle, kullanıcıların yalnızca belirtilen gruplara erişebilmesini sağlamak için gruplar oluşturur. Örneğin, bir senaryoda insan kaynakları personeli tarafından kullanılan bilgisayarları etkileyebilecek olaylar gibi olayların bir alt kümesini oluşturmak isteyebilirsiniz. Bu senaryoda, sadece özel personelin Hassas Sunucular grubunu görüntüleyebilmesini veya değiştirebilmesini isteyebilirsiniz. Sonra, bu tür erişimi etkinleştirmek için, tüm kullanıcılar için bir grup ve hassas bilgisayarlar için için bir grup oluşturmanız ve daha sonra bir güvenlik rolünün Tüm Kullanıcılar ve Hassas Sunucular gruplarına erişimi sağlamanız gerekir. Kaçınılmaz olarak, tüm kullanıcıları içeren bir grup oluşturmak performansı etkiler çünkü Service Manager sık sık grupta değişiklik olup olmadığını denetler. Bu kontrol, varsayılan olarak, her 30 saniyede gerçekleşir. Büyük bir grup için değişikliklerin denetlenerek sistem üzerinde yoğun bir yük oluşturulur ve yanıt süresi önemli ölçüde yavaşlar.
Çözüm 1: Service Manager'ın kayıt defteri anahtarını değiştirerek grup değişikliklerini ne sıklıkta denetleyeceğini el ile belirtebilirsiniz. Örneğin, grup kontrol onay sıklığını 10 dakikadan 30 saniyeye değiştirirseniz, önemli ölçüde performans artışı sağlarsınız. Ancak kuyruklar ve hizmet düzeyi hedefleri, aynı grup hesaplama yoklama aralığını kullanan özel grup türleridir. Bu nedenle, yoklama aralığının değerini artırmak, kuyruk ve hizmet düzeyi hedef hesaplamaları için daha uzun sürelere neden olur.
Dikkat
Kayıt defterinin hatalı şekilde düzenlenmesi sisteminizde ciddi arızalara yol açabilir. Kayıt defterinde değişiklik yapmadan önce, bilgisayarınızdaki önemli verileri yedeklemelisiniz.
Grubu değişiklik kontrol aralığını el ile belirtmek için
Regedit'i çalıştırın ve HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\ adresine gidin.
GroupCalcPollingIntervalMillisecondsadlı yeni bir DWORD değeri oluşturun.
Değeri için milisaniye cinsinden aralığı belirtin. Sonuç 6 ile çarpılır. Örneğin, aralığı 10 dakika olarak ayarlamak için 600000 girin.
System Center Yönetim hizmetini yeniden başlatın.
Çözüm 2: Kullanıcı rolüne "Kullanıcılar" gibi bir türdeki nesneleri eklemek için Windows PowerShell betiği kullanabilirsiniz. Temelde, bu rolde oturum açmış bir analist , "Kullanıcı" türüne sahip tüm nesnelere erişebilir. Bu yöntemi kullanırsanız, büyük bir grup ("Tüm Kullanıcılar") gereksinimini ve Service Manager'ın bu grup üyeliğini belirlemek için gerçekleştirdiği pahalı denetimi ortadan kaldırırsınız. Service Manager yönetim sunucusunda, "user" türünü "RoleName" rolüne eklemek için aşağıdaki Windows PowerShell betiğini çalıştırabilirsiniz. Ortamınız için bu örnek betiği değiştirmeniz gerekir.
Bir kullanıcı rolüne nesneleri eklemek için bir Windows PowerShell komut dosyasını çalıştırmak için
- Aşağıdaki komut dosyasını gereken şekilde değiştirin ve çalıştırın:
#
# Insert a "type" scope in a role
# Syntax:
# AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"
#
# Note: This is a simple demonstration script without error checking.
#
# set script parameter defaults
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")
$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")
$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server
# Get Type object
# Note: If you need to get a list of all available classes related to (for example) "User", use this command:
# $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}
#
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}
# Get role object, and insert the type GUID into scope
$role = $m.Security.GetUserRoles() | ?{ $_.DisplayName -eq $RoleName}
$role.Scope.Objects.Add($type.Id)
$role.Update()
#
# Get the value from the database again and validate it is there
if ( $role.scope.objects.Contains($type.Id) ) {
write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)
} else {
write-host "There was an error trying to insert the scope into the role."
}
Performansı görüntüleme
Görünüm oluşturduğunuzda, mümkün olduğunda sistemde "tipik" sınıfları kullanmayı planlayın. Örneğin, Olay Yönetimi gibi çoğu nesne sınıfı iki türe sahiptir: "tipik" ve "gelişmiş". Tipik nesne türü bir öğe ile ilgili verilerin küçük bir alt kümesine basit başvurular içerir. Gelişmiş tür bir öğe ile ilgili verilere çok karmaşık başvurular içerir. Tipik türler basit projeksiyonlardır; gelişmiş türler karmaşık projeksiyonlardır. Çoğu gelişmiş nesne türü, normalde görünümde görüntülenmesini istemediğiniz formlardaki farklı alanları doldurmak için kullanılır. Gelişmiş nesne türünü temel alan bir görünüm oluşturduğunuzda ve görünümü açtığınızda Service Manager veritabanını sorgular ve büyük miktarda veri okunur. Ancak, alınan verilerin çok azı görüntülenir veya kullanılır.
Görünümlerde gelişmiş nesne türlerini kullanırken tanımladığınız görünümlerle ilgili performans sorunlarıyla karşılaşırsanız, tipik türleri kullanmaya geçin. Alternatif olarak, yalnızca bir görünümü temel almak için ihtiyacınız olan verileri içeren kendi projeksiyon türlerinizi oluşturabilirsiniz.
Service Manager veritabanı performansı
Service Manager veritabanının performansı, verileri okuyan veya yazan eşzamanlı Service Manager konsollarının sayısı, grup değişikliği denetim aralığı ve bağlayıcılar tarafından eklenen veriler gibi çeşitli faktörlerden doğrudan etkilenir. Daha fazla bilgi bu belgede mevcuttur. İşte birkaç önemli nokta:
Tipik senaryolarda kabul edilebilir bir yanıt süresine sahip olabilmeniz için Service Manager veritabanını barındıran yönetim sunucusu için en az 8 gigabayt (GB) RAM'iniz olmalıdır.
Service Manager veritabanını barındıran bilgisayarda en az 8 CPU çekirdeğiniz olmalıdır.
Mümkünse, günlük dosyaları ve veri dosyalarını fiziksel disklere ayrıştırarak daha iyi veritabanı performansı elde edebilirsiniz. Tempdb'nizi Service Manager veritabanından farklı bir fiziksel RAID sürücüsüne taşıyarak daha fazla avantaj elde edebilirsiniz. Mümkünse, Service Manager veritabanınızı barındırmak için bir RAID 1+0 disk sistemi kullanın.
Service Manager veritabanı daha küçük bir boyutla oluşturulduysa ve özellikle küçük artışlarla otomatik olarak büyütülecek şekilde ayarlandıysa performans olumsuz etkilenebilir.
Veritabanının boyutunu değerlendirme konusunda yardım için Service Manager iş yardımları belge kümesinde (SM_job_aids.zip) bulunan Service Manager Boyutlandırma Yardımcısı aracına bakın ve veritabanını son boyuta daha yakın bir boyutla oluşturun. Bu, veritabanının otomatik olarak büyümesi gereken sayısını azaltarak performansa yardımcı olur.
Benzer şekilde, yüksek performanslı bir veritabanı için diğer tüm en iyi yöntemler de geçerlidir. Örneğin, üstün bir disk alt sisteminden yararlanabiliyorsanız, ilgili dosya gruplarında tablo gruplarını bölme ve bunları farklı bir fiziksel sürücüye taşıma avantajından yararlanabilirsiniz.
Service Manager yönetim sunucusu performansı
Service Manager yönetim sunucusunun performansı öncelikli olarak etkin eşzamanlı Service Manager konsollarının sayısından etkilenir. Tüm Service Manager rolleri yönetim sunucusuyla etkileşimde olduğundan, çok sayıda eşzamanlı konsola sahip olmak istiyorsanız ek yönetim sunucuları eklemeyi göz önünde bulundurun. Yönetimi sunucusu için 8 GB RAM olmalıdır. CPU çekirdeği başına 10 ila 12 etkin konsolunuz olduğu varsayılarak, yönetim sunucusu başına en az 4 CPU çekirdeğiniz olmalıdır.
Service Manager konsol performansı
Service Manager konsolunun performansı öncelikli olarak analistlerinizin normalde açık olan form sayısından ve görünümler tarafından alınan veri miktarından etkilenir. Service Manager konsolunun yüklü olduğu bilgisayarda 4 GB RAM'e sahip olmanız gerekir. Büyük miktarda veri alan görünümleriniz varsa ek RAM'e ihtiyacınız olacaktır. Service Manager konsolunun yüklü olduğu bilgisayar için en az 4 çekirdekli BIR CPU'nuz olmalıdır. Service Manager konsolu bir son kullanıcı uygulaması olduğundan, aşırı kaynak tüketimi görüyorsanız yeniden başlatmanızı öneririz. Service Manager konsolu bilgileri bellekte agresif bir şekilde önbelleğe alır ve bu da genel bellek kullanımına katkıda bulunabilir.
Service Manager veri ambarı veritabanı performansı
Veri ambarının performansı, veri gönderen eşzamanlı Service Manager yönetim sunucularının sayısı, depolanan veri hacmi veya veri saklama süresi, veri değişim hızı ve ayıklama, dönüştürme ve yükleme (ETL) sıklığı gibi çeşitli faktörlerden doğrudan etkilenir. Veri ambarında depolanan veri miktarı zamanla artar. Gereksiz verileri arşivlemeyi sağlamanız önemlidir. Veri ambarı performansını etkileyen diğer bir etken ETL süreçlerinin BatchSize ayarıdır.
Günlük dosyaları ve veri dosyalarını fiziksel disklere ayrıştırarak daha iyi performans elde edebilirsiniz. Ancak, disk başına birden fazla günlük dosyası yerleştirmekten kaçınmalısınız. Benzer şekilde, tempdb'yi diğer veritabanlarından farklı bir fiziksel diskte koyarak daha iyi verim elde edebilirsiniz. Son olarak, farklı veritabanlarını kendi fiziksel disklerine yerleştirmek de yararlı olabilir. Mümkünse, veri ambarınızı barındırmak için,bir RAID 1+0 disk sistemi kullanın. Genel olarak, veri ambarı veritabanları yüklü olan bilgisayarda en az 8 GB RAM olmalıdır. Operations Manager veya Configuration Manager'dan ek veri ambarı veri kaynaklarınız varsa veritabanları için RAM miktarını artırmanız gerekir. Veri ambarı barındıran SQL Server çalıştıran bilgisayarda daha fazla bellek yararlı olacaktır ve Datamart ve Depo veritabanları aynı sunucu üzerindeyse daha iyi olur. Ancak, dağıtım topolojinizde 4.000 veya daha az bilgisayar varsa 4 GB yeterlidir. Veri ambarı veritabanı yüklü olan bilgisayarda en az 8 CPU çekirdeği olmalıdır. Ek çekirdekler ETL ve rapor performansına yardım eder.
Sistemde tüm veritabanları küçük bir boyut ile oluşturulur ve özellikle küçük artışlarla, otomatik olarak büyümeye ayarlanırsa performans olumsuz etkilenebilir. Veritabanının boyutunu değerlendirmek için Service Manager iş yardımları belge kümesine (SM_job_aids.zip) dahil edilen Service Manager Boyutlandırma Yardımcısı aracına bakın ve veritabanını son boyuta daha yakın bir boyuta sahip olarak oluşturun. Bu araç, veritabanının otomatik olarak büyümek için gereken sayısını azaltarak performansa yardımcı olur.
Service Manager, dosya grupları için yerleşik destek içerir. Bu dosya gruplarını ayrı sabit sürücülere yerleştirerek bundan yararlanabilirsiniz. Dosya grubu en iyi yöntemleri hakkında daha fazla bilgi için SQL Server belgelerine bakın.
Service Manager veri ambarı sunucu performansı
Veri ambarı sunucusunun performansı, veri ambarı için kaydedilen Service Manager yönetim sunucularının sayısından, dağıtımınızın boyutundan ve veri kaynaklarının sayısından etkilenir. Genel olarak, veri ambarı sunucusu için en az 8 GB RAM olmalıdır. Ancak, birden fazla Service Manager yönetim sunucusunun veri ambarı içine veri eklediği gelişmiş dağıtım senaryoları için ek belleğe sahip olmak performanstan yararlanacaktır. Eğer performanstan ödün vermeniz gerekirse, en yüksek önceliğiniz SQL Server çalıştıran bilgisayar için bellek olmalıdır. Performans sorunlarını önlemek için en az 8 CPU çekirdeği olmalıdır.
Self Servis portalı performansı
Self Servis Portalı, olay ve hizmet isteği dosyalama işlemine kolay erişim için tasarlanmıştır. Aynı anda binlerce kullanıcıyı işleyecek şekilde tasarlanmamıştır.
Self Servis Portalı'nın performans testi tipik "Pazartesi sabahı" senaryolarına odaklanarak Pazartesi sabahı yüzlerce kullanıcının 5 ile 10 dakika arasında oturum açabilmesini ve kabul edilebilir (4-5 saniyeden az) yanıt süresine sahip olayları açabilmesini sağladı. Bu hedefe, bu belgede önerilen en düşük donanım ile ulaşılmıştı.
Hizmet düzeyi hedef performansı
Service Manager'ın desteklediği belirli sayıda hizmet düzeyi hedefi yoktur. Örneğin, bir kuruluşta tipik olarak az sayıda olay oluşuyorsa, normalde yapabileceğinden daha fazla hizmet düzeyi hedefi destekleyebilir. Ancak, daha büyük bir olay miktarı, duruma göre ya daha az sayıda hizmet düzeyi hedefi olmasını ya da ölçeğin ek donanım ve yazılım ile genişletilmesini gerektirir. Tipik bir 50.000 bilgisayarlı Service Manager yapılandırması için en fazla beş hizmet düzeyi hedefi oluşturmanızı öneririz. Daha fazla sayıda hizmet düzeyi hedef oluşturmanız olanaklıdır. Ancak, koşullar kuruluştan kuruluşa büyük ölçüde farklılık gösterdiğinden Microsoft, aşmamanız gereken hizmet düzeyi hedeflerinin sayısı için somut bir öneri sağlayamaz. Dağıtım yapılandırmanız hizmet düzeyi hedeflerinin sayısının bir sonucu olarak düşük performanstan muzdaripse, bu kılavuzun Dağıtım Senaryoları için Yapılandırmalar makalesinde açıklandığı gibi sonraki daha büyük dağıtım senaryosunu kullanarak ölçeği genişletmenizi öneririz.
Sonraki adımlar
- Service Manager dağıtım senaryolarına yönelik donanım ve yazılım yapılandırmaları hakkında bilgi edinmek için Önerilen dağıtım topolojisi senaryoları'na bakın.
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin