Kami membeli beberapa perangkat lunak dari perusahaan kecil, itu adalah manajer alur kerja konten video Windows 32-bit, telah ada beberapa penyesuaian oleh mereka.
Kami telah bekerja dengan baik selama lebih dari setahun menjalankan kode ini dalam VMWare ESXi 4.1u2 VM pada W2K3EE-32-bit (itulah yang mereka dukung saat menjalankannya).
Kemudian mereka memperbarui kode mereka sekitar sebulan lalu dan kami mulai melihat salah satu vCPU secara berkala mematok 100%, vCPU kedua cukup menganggur, katakanlah 5-7% - jadi kami hanya berasumsi bahwa kode tersebut di-threaded dengan buruk dan menghubungi mereka tentang Itu.
Mereka sekarang kembali kepada kami dengan mengatakan bahwa kode mereka tidak berfungsi dalam VM, mereka telah mengetahui tentang persyaratan ini selama 18 bulan atau lebih, dan bahwa mereka ingin kita menggunakannya. Mereka mengatakan mereka hanya melihat masalah ini ketika dijalankan di dalam VM. Saya sudah menelepon dengan programmer senior mereka yang dijadwalkan dalam beberapa jam untuk berdiskusi.
Sekarang untungnya kita memiliki beberapa fisik yang dapat kita lakukan ini, sedikit memakan waktu tetapi bisa dilakukan.
Namun pertanyaan saya adalah bahwa mengingat VM ini tidak menyentuh perangkat keras secara langsung, ada di host yang sangat modern dan sebenarnya memiliki persyaratan yang sangat rendah (2 x vCPU, 4GB, 20GB boot vdisk, 100GB data vdisk, vNIC tunggal dan tidak ada yang lain) apa mungkin masalah dengan menjalankannya di VM, jika ada?
Jelas saya sangat mengejar ini dengan mereka tetapi saya hanya bertanya-tanya apakah orang lain telah menemukan aplikasi reguler, yang entah bagaimana berkelakuan buruk di dalam VM tetapi tidak pada fisik.
sumber
Jawaban:
Meskipun saya tidak dapat berbicara untuk vendor ini atau paket perangkat lunak, saya telah bekerja untuk vendor besar (multinasional), di mana salah satu bagian dari perangkat lunak yang mereka jual memiliki masalah yang sangat spesifik ketika dijalankan pada VMware.
Dalam kasus ini, satu masalah dapat menyebabkan perangkat lunak menemui jalan buntu, dan yang lainnya dapat menyebabkan kerusakan data. Dengan demikian, pelanggan disarankan untuk tidak menjalankan perangkat lunak dalam lingkungan virtual. Beberapa masih melakukannya, dan dalam semua kasus yang saya sadari, mereka mengalami satu atau kedua masalah.
Jadi, meskipun jarang, ada beberapa kasus di mana perangkat lunak tidak berkinerja seperti yang Anda harapkan di VMware.
Meskipun saya menyadari itu tidak secara langsung membantu masalah Anda, itu menunjukkan bahwa VMWare tidak selalu merupakan sistem yang sempurna.
Catatan Kaki: dalam hal ini vendor dapat bekerja dengan VMware untuk menemukan resolusi (beberapa perbaikan kode, beberapa perubahan konfigurasi VMWare), dan mereka sekarang memiliki beberapa (sangat spesifik) panduan tentang cara menjalankan perangkat lunak pada VMWare.
sumber
Dengan ESX v5 dan batas Monster VM (32vCPU 1TB RAM), jumlah aplikasi yang mengalami masalah dengan VM menyusut. Sebagian besar yang pernah saya alami adalah: - mengandalkan waktu untuk linier (proses waktu nyata atau aplikasi yang perlu memiliki waktu linier ... ini biasanya dapat diubah) - aplikasi yang menyebabkan banyak gangguan perangkat keras atau pengalihan konteks
Dalam kebanyakan kasus, Anda harus dapat meminta perwakilan vmware Anda untuk berbicara dengan mereka. Saya percaya vmware masih memiliki tim orang yang berdedikasi untuk membuat hal-hal berfungsi (mereka memiliki laboratorium pendukung hanya untuk ini di awal-awal).
Adapun solusi, saya punya masalah serupa dengan VM memiliki penggunaan CPU yang tinggi (tetapi tuan rumah memiliki banyak sumber daya CPU gratis). Kami memperbaiki masalah dengan bermigrasi ke server dengan CPU Nehalem dan mengubah tingkat kompatibilitas CPU di EVC (jika Anda memiliki cluster dengan DRS / HA)
sumber
Saya telah melihat masalah yang sama dengan VMware ESX + Debian 6 + OpenLDAP 2.4.x (apa pun versi tepat OpenLDAP adalah apt-gettable ...).
Di bawah operasi sehari-hari berfungsi dengan baik, tetapi hal-hal seperti mengimpor file LDIF besar dengan 400.000 atau lebih entri sangat lambat (50-100x lebih lambat daripada dengan server fisik). Juga dengan durasi panjang, pembandingan volume tinggi, semuanya berjalan lancar dengan beberapa waktu respons milidetik, tetapi kadang-kadang ada puncak aneh mulai dari 500 hingga 25.000 (!) Milidetik.
Dengan server fisik saya tidak dapat mereproduksi masalah ini. Dan ya, saya menghabiskan sekitar tiga minggu mencoba untuk mengisolasi masalah, menyetel semua jenis parameter dari parameter sistem operasi ke nilai slapd ke nilai BerkeleyDB ... tidak ada yang membantu.
sumber
Jira
danConfluence
tidak direkomendasikan untuk berjalan di lingkungan VM (ware). Harus ada pola untuk pengecualian ini, saya hanya belum tahu apa itu. Instalasi OpenLDAP saya tidak terlalu intensif I / O (tulis 3 MB / s dan tidak terlalu banyak IOPS di puncak selama benchmark), mungkin menggunakan CPU 20-40%, dan sekitar 150 MB RAM. Seharusnya tidak terlalu sulit untuk ditangani. Mungkin ada hubungannya dengan threading, tetapi konteks laporan vmstat beralih dll menjadi pada tingkat normal.tsc=pit
parameter gaya selama boot, dan setidaknya OpenLDAP SANGAT sensitif terhadap akurasi jam sistem. Mungkin saya harus mengunci semua aplikasi yang bermasalah dan melihat apakah mereka semua banyak menggunakangettimeofday()
atau lebih.