Mengoptimalkan kinerja pembuatan cache peta di ArcGIS untuk Server 10.2.1


8

Saya relatif baru di ArcGIS untuk Server, jadi saya berharap seseorang dapat mengarahkan saya ke arah yang benar jika apa yang saya lakukan tidak praktik yang baik.

Saya punya 2 kotak dengan ArcGIS untuk server 10.2.1, keduanya di situs yang sama. Kedua kotak memiliki 4 prosesor dan 16gb RAM. Kedua kotak berjalan di Windows Server 2008.

masukkan deskripsi gambar di sini

Situs ini digunakan untuk menyediakan beberapa layanan peta dasar untuk sejumlah kecil pengguna (<5) dan untuk menghasilkan ubin cache untuk layanan di masa mendatang.

Saat ini saya menghasilkan ubin cache untuk layanan pemetaan (~ 50GB). Saya akan berharap untuk melihat penggunaan CPU pada 2 kotak berjalan cukup tinggi. Tetapi cenderung duduk antara 15% dan 30% pada setiap kotak.

Mesin virtual maksimum untuk alat caching diatur ke 6.

masukkan deskripsi gambar di sini

Jumlah instance maksimum per mesin ditetapkan ke 3.

masukkan deskripsi gambar di sini

Apakah saya salah berasumsi bahwa saya seharusnya melihat penggunaan CPU yang lebih tinggi?

Apakah saya belum memasukkan angka yang benar?

Atau apakah pengaturan saya bukan praktik terbaik? yaitu apakah saya harus menggunakan satu situs hanya untuk melayani peta dan situs lain hanya untuk caching?

Saya pikir saya sudah mengikuti pedoman yang disebutkan di sini dan di sini . Tapi saya cukup yakin bahwa caching berjalan lebih lambat dari yang seharusnya. Setelah 19 jam, ia hanya menyimpan 1,17% dari semua ubin saya.

masukkan deskripsi gambar di sini

Setiap saran praktik terbaik sangat kami sambut.

UPDATE: Setelah 21 jam penggunaan CPU di kedua mesin tidak ada artinya:

mesin 1: masukkan deskripsi gambar di sini

mesin 2:

masukkan deskripsi gambar di sini

Bilah status cache "sedang berlangsung" di server masih bergerak, tetapi cache% tidak meningkat dalam 2 jam terakhir.


Apakah server Anda di Linux atau Windows?
Mintx

Mintx, saya sudah memperbarui pertanyaan dengan info yang diminta.
Dan_h_b

tidak yakin, tetapi bisa jadi karena akses baca / tulis lebih dari CPU
radouxju

Akun ArcServer memiliki akses baca / tulis penuh ke folder tujuan dan akses baca ke database tempat data sumber disimpan. Saya telah menembolok area yang lebih kecil dari sumber yang sama ke tujuan yang sama tanpa masalah.
Dan_h_b

1
Saya pikir komentar radouxju mengacu pada pertengkaran I / O disk daripada izin. Kecepatan proses proses penulisan file gambar bisa menjadi hambatan.
tomfumb

Jawaban:


2

Sepertinya Anda telah melakukan pekerjaan yang cukup baik dalam mengikuti praktik terbaik untuk membuat cache. Server Anda memiliki cukup daya kuda, tetapi menarik data peta dari basis data Anda mungkin menjadi masalah. Berikut adalah sedikit ringkasan dari situs ini yang memiliki beberapa tips tambahan untuk mendapatkan hasil maksimal dari uang Anda.

1 - Analisis peta Anda sebelum menerbitkannya!

Ini mungkin jelas, tetapi saya sering terlalu cepat untuk mempublikasikan ke server tanpa memeriksa hasil analisis. Cukup buka File->Analyze Mapdan lakukan pemeriksaan cepat untuk melihat apakah peta Anda memiliki masalah. Semakin cepat peta Anda dirender, semakin cepat pula cache.

2 - Simpan data lokal

Jika Anda memiliki penyebaran mesin tunggal, simpan data peta di FGDB lokal ke server. Jika Anda memiliki banyak mesin, biarkan setiap mesin memiliki salinan data dan gunakan opsi "Gunakan direktori cache lokal saat membuat ubin di server" ketika mengatur cache.

Tautan di atas memiliki beberapa tips praktis untuk mengatasi kegagalan, bersama dengan skrip praktis ini yang mem-parsing kesalahan caching ke dalam jejak poligon sehingga Anda dapat dengan mudah kembali dan mencoba melakukan cache ulang area gagal.

Pertanyaan ini muncul sesekali. Mungkin kita bisa mendapatkan lebih banyak jawaban dan mengubahnya menjadi Wiki. :)


1

Hal lain yang bisa Anda lakukan adalah mengatur pengontrol caching dan alat caching ke cluster yang berbeda. Ini harus mengisolasi proses caching dari kumpulan proses reguler. Saya telah melihat ini menghasilkan caching mengisolasi kinerja yang lebih baik dari fungsi arcgisserver biasa. Saya biasanya menyebut caching cluster baru ini. Kemudian ketika Anda menambahkan mesin baru ke instalasi Anda cukup menambahkannya ke caching cluster versus default dan ini akan meningkatkan daya pemrosesan Anda. Selain itu, jika Anda melihat pemanfaatan yang rendah maka terus tambahkan lebih banyak dan lebih banyak sumber daya hingga Anda mencapai sekitar 70-80% pemanfaatan Anda masih ingin meninggalkan beberapa tenaga kuda untuk menyalin file bolak-balik dan mengurangi pertengkaran untuk sumber daya.


1

Berdasarkan pada dokumentasi ESRI ( http://server.arcgis.com/en/server/latest/publish-services/linux/accelerating-map-cache-creation.htm ) praktik terbaik untuk jumlah instance yang digunakan untuk caching adalah n + 1 di mana n adalah jumlah core yang berjalan di server. Server Anda masing-masing memiliki 4 prosesor dan setiap prosesor X5690 memiliki 6 core sesuai dengan dokumentasi:

http://ark.intel.com/products/52576/Intel-Xeon-Processor-X5690-12M-Cache-3_46-GHz-6_40-GTs-Intel-QPI

Berdasarkan ini, Anda secara teoritis dapat menangani 25 instance caching per server. Sekarang saya tahu dokumen ESRI adalah untuk 10.3 tetapi ini telah menjadi praktik yang disarankan untuk beberapa versi terakhir.

Saya memiliki pengaturan server yang sama dan saya dapat memberitahu Anda bahwa CPU saya akan mencapai 100% sebelum saya mendekati 25 instance tetapi saya dapat menggunakan 10-15 dengan cukup nyaman.

Jadi, jika Anda telah menguji bahwa IO disk atau database bukan hambatan, saya akan merekomendasikan meningkatkan jumlah instance menjadi 10. Jika ini tidak meningkatkan penggunaan CPU Anda itu berarti itu bukan faktor pembatas. Jika memang meningkat tetapi masih masuk akal Anda bisa mencoba meningkatkan lebih lanjut.

Pokoknya, moral dari cerita ini adalah jangan malu-malu tentang cranking contoh. Suatu kali saya juga bekerja pada server yang cukup kurang daya dengan hanya 2 core dan 3 instance membuat saya tidak punya tempat. Namun ketika saya meningkatkan instance ke 5 penggunaan CPU itu wajar. Praktik terbaik hanyalah titik awal.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.