Bagikan melalui

Pusat Sistem - Performa Manajer Layanan

  • Artikel

Penting

Versi Service Manager ini telah mencapai akhir dukungan. Kami menyarankan Anda untuk meningkatkan ke Service Manager 2022.

Performa untuk Pusat Sistem - Peran dan fitur server Manajer Layanan dipengaruhi oleh faktor yang berbeda. Umumnya, ada tiga area di mana performa positif dan negatif paling terlihat di Service Manager:

  • Responsivitas konsol Service Manager. Ini adalah lamanya waktu yang diperlukan sejak Anda mengambil semacam tindakan di konsol sampai selesai.

  • Waktu penyisipan data untuk konektor. Ini adalah berapa lama waktu yang dibutuhkan Service Manager untuk mengimpor data saat konektor disinkronkan.

  • Waktu penyelesaian alur kerja. Ini adalah lamanya waktu yang diperlukan alur kerja untuk menerapkan beberapa jenis tindakan secara otomatis.

Performa konektor

Sinkronisasi awal konektor dapat memakan waktu yang signifikan; misalnya, 8 hingga 12 jam untuk sinkronisasi awal besar dengan Configuration Manager. Saat konektor disinkronkan pada awalnya, Anda dapat mengharapkan performa menderita untuk semua peran dan proses server Manajer Layanan selama waktu ini. Ini terjadi karena cara data dimasukkan secara berurutan ke dalam database Service Manager, yang merupakan database Microsoft SQL Server. Meskipun Anda tidak dapat menyempurnakan proses sinkronisasi awal konektor, Anda dapat merencanakan sinkronisasi awal dan memastikan bahwa proses sinkronisasi selesai dengan baik sebelum Service Manager dimasukkan ke dalam produksi.

Ketika sinkronisasi awal selesai, Service Manager terus menyinkronkan perbedaan, yang tidak berdampak terukur pada performa.

Performa alur kerja

Alur kerja adalah proses otomatis yang terjadi. Mereka termasuk mengirim pemberitahuan email, langkah berikutnya dari permintaan perubahan yang diaktifkan, dan secara otomatis menerapkan templat.

Pertimbangan performa alur kerja meliputi yang berikut ini:

  • Biasanya, alur kerja dimulai dan selesai dalam waktu satu menit. Ketika peran server Service Manager berada di bawah beban kerja yang berat, alur kerja tidak selesai secepat normal.

  • Selain itu, saat Anda membuat alur kerja baru, seperti langganan pemberitahuan baru, beban tambahan ditempatkan pada sistem. Saat jumlah alur kerja baru yang Anda buat meningkat, waktu yang diperlukan untuk setiap alur kerja untuk berjalan juga meningkat.

Ketika sistem berada di bawah beban berat—jika, misalnya, sejumlah besar insiden baru sedang dibuat dan setiap insiden menghasilkan banyak alur kerja—performa mungkin terpengaruh secara negatif.

Dampak peran grup, antrean, dan pengguna pada performa

Anda harus merencanakan grup dan peran pengguna lebih awal. Anda harus membuat grup dengan hemat dan membuatnya untuk cakupan sekecil mungkin. Kemudian, Anda awalnya harus mengisi database Anda dengan data dari Active Directory Domain Services (AD DS), Configuration Manager, dan System Center Operations Manager sebelum membuat grup Anda.

Seringkali, administrator membuat grup untuk memastikan bahwa pengguna hanya memiliki akses ke grup tertentu. Misalnya, dalam satu skenario Anda mungkin ingin membuat subset insiden, seperti insiden yang memengaruhi komputer yang digunakan oleh personel sumber daya manusia. Dalam skenario ini, Anda mungkin hanya ingin personel tertentu yang dapat melihat atau memodifikasi grup Server Sensitif. Kemudian, untuk mengaktifkan jenis ini untuk akses, Anda harus membuat grup untuk semua pengguna dan grup untuk komputer sensitif lalu memastikan bahwa peran keamanan memiliki akses ke grup Semua Pengguna dan Server Sensitif. Tak pelak, membuat grup yang berisi semua pengguna menghasilkan dampak performa karena Service Manager sering memeriksa untuk menentukan apakah ada perubahan pada grup. Pemeriksaan ini terjadi setiap 30 detik sekali, secara default. Untuk grup besar, memeriksa perubahan membuat beban berat pada sistem, dan mungkin memperlambat waktu respons secara besar-besaran.

Solusi 1: Anda dapat menentukan secara manual seberapa sering Service Manager memeriksa perubahan grup dengan memodifikasi kunci registri. Misalnya, jika Anda mengubah frekuensi pemeriksaan grup dari 30 detik menjadi 10 menit, Anda secara signifikan meningkatkan performa. Namun, antrean dan tujuan tingkat layanan adalah jenis grup khusus yang menggunakan interval polling perhitungan grup yang sama. Jadi, meningkatkan nilai interval polling menghasilkan waktu yang lebih lama untuk penghitungan tujuan tingkat antrean dan layanan.

Perhatian

Pengeditan registri yang salah dapat sangat merusak sistem Anda. Sebelum membuat perubahan pada registri, Anda harus mencadangkan semua data berharga pada komputer.

Untuk menentukan interval pemeriksaan perubahan grup secara manual

  1. Jalankan Regedit, dan navigasi ke HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Buat nilai DWORD baru bernama GroupCalcPollingIntervalMilliseconds.

  3. Untuk nilainya, tentukan interval dalam milidetik. Hasilnya dikalikan dengan 6. Misalnya, untuk mengatur interval ke 10 menit, masukkan 600000.

  4. Mulai ulang layanan Manajemen Pusat Sistem.

Solusi 2: Anda dapat menggunakan skrip Windows PowerShell untuk menambahkan objek jenis, seperti "Pengguna", ke peran pengguna. Pada dasarnya, analis yang masuk dalam peran ini dapat mengakses semua objek yang memiliki jenis yang sama dengan "Pengguna". Jika Anda menggunakan metode ini, Anda menghilangkan kebutuhan akan grup besar ("Semua Pengguna") dan pemeriksaan mahal yang dilakukan Service Manager untuk menentukan keanggotaan grup ini. Di server manajemen Manajer Layanan, Anda dapat menjalankan skrip Windows PowerShell berikut untuk menambahkan jenis "pengguna" ke peran "RoleName". Anda harus mengubah contoh skrip ini untuk lingkungan Anda.

Untuk menjalankan skrip Windows PowerShell untuk menambahkan objek ke peran pengguna

  • Ubah skrip berikut seperlunya, lalu jalankan:
#  
# 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."  
}

Melihat performa

Saat Anda membuat tampilan, rencanakan penggunaan kelas "khas" dalam sistem jika memungkinkan. Sebagian besar kelas objek-misalnya, Manajemen Insiden-memiliki dua jenis: "khas" dan "tingkat lanjut". Jenis objek umum berisi referensi sederhana ke subset kecil data yang terkait dengan item. Jenis tingkat lanjut berisi banyak referensi kompleks ke data yang terkait dengan item. Jenis umumnya adalah proyeksi sederhana; jenis tingkat lanjut adalah proyeksi kompleks. Sebagian besar jenis objek tingkat lanjut digunakan untuk mengisi bidang yang berbeda dalam formulir yang biasanya tidak ingin Anda lihat ditampilkan dalam tampilan. Setiap kali Anda membuat tampilan berdasarkan jenis objek tingkat lanjut dan saat Anda membuka tampilan, Manajer Layanan meminta database dan sejumlah besar data dibaca. Namun, sangat sedikit dari data yang diambil ditampilkan atau digunakan.

Jika Anda mengalami masalah performa dengan tampilan yang telah Anda tentukan saat menggunakan jenis objek tingkat lanjut dalam tampilan, beralihlah menggunakan jenis umum. Atau, Anda dapat membuat jenis proyeksi Anda sendiri yang hanya berisi data yang Anda butuhkan untuk mendasarkan tampilan.

Performa database Service Manager

Performa database Service Manager dipengaruhi langsung oleh berbagai faktor, termasuk jumlah konsol Service Manager bersamaan yang membaca atau menulis data, interval pemeriksaan perubahan grup, dan data yang dimasukkan oleh konektor. Informasi lebih lanjut tersedia dalam dokumen ini. Berikut adalah beberapa poin penting:

  • Anda harus memiliki minimal 8 gigabyte (GB) RAM untuk server manajemen yang menghosting database Service Manager sehingga Anda dapat memiliki waktu respons yang dapat diterima dalam skenario umum.

  • Anda harus memiliki setidaknya 8 inti CPU di komputer yang menghosting database Service Manager.

  • Anda dapat mencapai performa database yang lebih baik dengan memisahkan file log dan file data untuk memisahkan disk fisik, jika memungkinkan. Anda dapat mencapai manfaat lebih lanjut dengan memindahkan tempdb Anda ke drive RAID fisik yang berbeda dari database Service Manager. Gunakan sistem disk RAID 1+0 untuk menghosting database Service Manager Anda, jika memungkinkan.

  • Performa dapat terpengaruh secara negatif jika database Service Manager dibuat dengan ukuran yang lebih kecil dan diatur ke pertumbuhan otomatis, terutama dengan kenaikan kecil.

Lihat alat Service Manager Sizing Helper yang disertakan dalam kumpulan dokumentasi bantuan pekerjaan Service Manager (SM_job_aids.zip) untuk bantuan dalam menilai ukuran database, dan membuat database dengan ukuran yang lebih dekat ke ukuran akhir. Ini akan membantu performa dengan mengurangi berapa kali database harus bertumbuh secara otomatis.

Demikian pula, semua praktik terbaik lainnya untuk database berkinerja tinggi juga berlaku. Misalnya, jika Anda dapat memanfaatkan subsistem disk yang unggul, Anda dapat memperoleh manfaat dari memisahkan grup tabel pada grup file masing-masing dan memindahkannya ke drive fisik yang berbeda.

Performa server manajemen Manajer Layanan

Performa server manajemen Manajer Layanan terutama dipengaruhi oleh jumlah konsol Service Manager bersamaan aktif. Karena semua peran Manajer Layanan berinteraksi dengan server manajemen, pertimbangkan untuk menambahkan server manajemen tambahan jika Anda berencana untuk memiliki sejumlah besar konsol bersamaan. Anda harus memiliki RAM 8 GB untuk server manajemen. Anda harus memiliki setidaknya 4 inti CPU per server manajemen, dengan asumsi Anda memiliki 10 hingga 12 konsol aktif per inti CPU.

Performa konsol Service Manager

Performa konsol Service Manager terutama dipengaruhi oleh jumlah formulir yang biasanya dibuka oleh analis Anda dan jumlah data yang diambil oleh tampilan. Anda harus memiliki RAM 4 GB di komputer tempat konsol Service Manager diinstal. Jika Anda memiliki tampilan yang mengambil sejumlah besar data, Anda akan memerlukan RAM tambahan. Anda harus memiliki setidaknya CPU 4-core untuk komputer tempat konsol Service Manager diinstal. Karena konsol Service Manager adalah aplikasi pengguna akhir, kami sarankan Anda memulai ulang jika Anda melihat konsumsi sumber daya yang berlebihan. Konsol Service Manager secara agresif menyimpan informasi dalam memori, yang dapat berkontribusi pada penggunaan memori secara keseluruhan.

Performa database gudang data Service Manager

Performa gudang data dipengaruhi langsung oleh berbagai faktor, termasuk jumlah server manajemen Manajer Layanan bersamaan yang mengirim data, volume data yang disimpan atau periode retensi data, laju perubahan data, dan frekuensi ekstraksi, transformasi, dan pemuatan (ETL). Jumlah data yang disimpan di gudang data meningkat dari waktu ke waktu. Memastikan bahwa Anda mengarsipkan data yang tidak perlu penting. Faktor lain yang memengaruhi performa gudang data adalah pengaturan BatchSize dari proses ETL.

Anda dapat mencapai performa yang lebih baik dengan memisahkan file log dan file data untuk memisahkan disk fisik. Namun, Anda harus menghindari penempatan lebih dari satu file log per disk. Demikian pula, Anda dapat mencapai throughput yang lebih baik dengan menempatkan tempdb pada disk fisik yang berbeda dari database lainnya. Terakhir, Anda juga dapat memperoleh manfaat dengan menempatkan database yang berbeda pada disk fisik masing-masing. Gunakan sistem disk RAID 1+0 untuk menghosting gudang data Anda, jika memungkinkan. Anda umumnya harus memiliki ram minimal 8 GB untuk komputer tempat database gudang data diinstal. Jika Anda memiliki sumber data gudang data tambahan dari Operations Manager atau Configuration Manager, Anda harus meningkatkan jumlah RAM untuk database. Anda akan mendapat manfaat dari lebih banyak memori di komputer yang berjalan SQL Server yang menghosting gudang data, dan bahkan lebih jika database Datamart dan Repositori berada di server yang sama. Namun, jika Anda memiliki 4.000 komputer atau kurang dalam topologi penyebaran Anda, 4 GB sudah cukup. Anda harus memiliki setidaknya 8 inti CPU di komputer tempat database gudang data diinstal. Inti tambahan akan membantu performa ETL dan laporan.

Performa dapat terpengaruh secara negatif jika semua database dalam sistem dibuat dengan ukuran yang lebih kecil dan diatur ke autogrow, terutama dengan kenaikan kecil. Lihat alat Service Manager Sizing Helper yang disertakan dalam kumpulan dokumentasi bantuan pekerjaan Manajer Layanan (SM_job_aids.zip) untuk menilai ukuran database dan membuat database dengan ukuran yang lebih dekat dengan ukuran akhir, yang akan membantu performa dengan mengurangi berapa kali database harus ditumbuhkan secara otomatis.

Manajer Layanan menyertakan dukungan bawaan untuk grup file. Anda dapat memperoleh manfaat dari ini dengan menempatkan grup file pada hard drive terpisah. Untuk informasi selengkapnya tentang praktik terbaik grup file, lihat dokumentasi SQL Server.

Performa server gudang data Service Manager

Performa server gudang data dipengaruhi oleh jumlah server manajemen Manajer Layanan yang terdaftar di gudang data, ukuran penyebaran Anda, dan jumlah sumber data. Anda umumnya harus memiliki ram minimal 8 GB untuk server gudang data. Namun, performa akan mendapat manfaat dengan memiliki memori tambahan untuk skenario penyebaran tingkat lanjut di mana lebih dari satu server manajemen Manajer Layanan menyisipkan data ke dalam gudang data. Jika Anda harus menukar performa, prioritas tertinggi Anda harus untuk memori untuk komputer yang berjalan SQL Server. Anda harus memiliki setidaknya 8 inti CPU untuk mencegah masalah performa.

Performa portal Layanan Mandiri

Portal Self-Service dirancang untuk akses mudah ke insiden dan pengajuan permintaan layanan. Ini tidak dirancang untuk menangani ribuan pengguna secara bersamaan.

Pengujian performa untuk portal Self-Service difokuskan pada skenario "Senin pagi" khususnya, untuk memastikan bahwa pada senin pagi ratusan pengguna dapat masuk dalam rentang 5 hingga 10 menit dan membuka insiden dengan waktu respons yang dapat diterima (kurang dari 4-hingga 5 detik). Tujuan ini dicapai dengan perangkat keras minimum yang direkomendasikan dalam dokumen ini.

Performa tujuan tingkat layanan

Tidak ada jumlah tujuan tingkat layanan tertentu yang didukung Oleh Service Manager. Misalnya, jika organisasi biasanya memiliki beberapa insiden, organisasi dapat mendukung lebih banyak tujuan tingkat layanan daripada yang mungkin mampu dilakukan. Namun, volume insiden yang lebih besar mungkin mengharuskan lebih sedikit tujuan tingkat layanan atau peluasan skala perangkat keras dan perangkat lunak tambahan, sebagaimana merujuknya. Kami menyarankan agar Anda membuat tidak lebih dari lima tujuan tingkat layanan untuk konfigurasi Service Manager 50.000 komputer biasa. Anda mungkin dapat membuat lebih banyak tujuan tingkat layanan. Namun, karena kondisi sangat bervariasi dari organisasi ke organisasi, Microsoft tidak dapat memberikan rekomendasi konkret untuk jumlah tujuan tingkat layanan yang tidak boleh Anda lampaui. Jika konfigurasi penyebaran Anda mengalami performa yang buruk sebagai akibat dari jumlah tujuan tingkat layanan, kami sarankan Anda memperluas skala menggunakan skenario penyebaran yang lebih besar berikutnya, seperti yang dijelaskan dalam artikel Konfigurasi untuk Skenario Penyebaran dari panduan ini.

Langkah berikutnya