Bir VM'de uygulama “desteklenmiyor” mu?


10

Küçük bir şirketten bazı yazılımlar aldık, Windows 32 bit video içerik iş akışı yöneticisi, onlar tarafından bazı özelleştirmeler yapıldı.

Bu kodu W2K3EE-32-bit üzerinde bir VMWare ESXi 4.1u2 VM'de çalıştırmak için bir yılı aşkın bir süredir çalışıyoruz (çalıştırmayı destekledikleri şey budur).

Sonra bir ay kadar önce kodlarını güncellediler ve vCPU'lardan birinin periyodik olarak% 100 oranında sabitlemeye başladığını görmeye başladık, ikinci vCPU oldukça boş,% 5-7 diyelim - bu yüzden kodun kötü işlediğini ve onlarla ilgili olarak o.

Şimdi bize kodlarının bir sanal makinede çalışmadığını, bu gereksinimi 18 aydır bildiğini ve V2P yapmamızı istediklerini söylediler. Bu sorunu sadece VM'lerin içinde koştuklarında gördüklerini söylüyorlar. Üst düzey programcılarıyla birkaç saat içinde görüşmek üzere bir görüşme yaptım.

Neyse ki, bunu yapabileceğimiz birkaç fizik var, biraz zaman alıcı ama yapılabilir.

Ancak sorum şu ki, bu VM doğrudan herhangi bir donanıma dokunmuyorsa, çok modern bir ana bilgisayarda bulunuyor ve aslında çok düşük gereksinimleri var (2 x vCPU, 4GB, 20GB önyükleme vdisk, 100GB veri vdisk, tek vNIC ve başka hiçbir şey) eğer varsa, bir sanal makinede çalıştırmayla ilgili sorun olabilir mi?

Açıkçası bunu onlarla birlikte takip ediyorum ama başkalarının düzenli bir uygulama bulup bulamadığını merak ettim, bir şekilde bir VM'de yanlış davranıyor, ancak fiziksel olarak değil.


Her iki vCPU da aynı CPU'dan mı geliyor? Her gerçek çekirdeğin doğrudan bir vCPU ile eşleşmesi ayarlanmış mı? İşlemcilerinizde hiper iş parçacığı etkinleştirme gibi komik bir şey yapıyor musunuz? Bunlar, sizin uçlarında ele alabileceğiniz bazı yavaşlamalara neden olabilecek her şeyi ele almaya yardımcı olacak bazı sorulardır. Muhtemelen kıdemli bir programcı ile konuştuktan sonra ya bir sanal makinede çalıştırılmasından kaynaklanan sorunların nasıl ele alınacağını daha iyi bir fikriniz olacak ya da sadece yanlış mı yaptıklarını kesin olarak bileceksiniz. Kod java ile yazılmış olabilir.
Wilshire

ESXi'nin işlem planlaması açısından kendi işini yapmasına izin veriyorum ve> 55xx serisi Xeons hiper iş parçacığı 'komik' olarak kabul edilmiyor, çalışıyor ve çok kullanışlı - oh ve kodun .NET 3.5'i bu arada.
Chopper3

Görünüşe göre MySQL Kümesi'nin sanallaştırılmış bir ortamda 'resmen' çalışmadığını da biliyorum. Nedeni? Dunno! : P
Ben Ashton

Yanıtlar:


3

Bu satıcı veya yazılım paketi için konuşamasam da, sattıkları yazılım parçalarından birinin VMware üzerinde çalışırken çok özel bilinen sorunları olduğu büyük (çok uluslu) bir satıcı için çalıştım.

Bu durumda, bir sorun yazılımın kilitlenmesine ve diğeri veri bozulmasına neden olabilir. Bu nedenle, müşterilere yazılımı sanal bir ortamda çalıştırmamaları tavsiye edildi. Bazıları hala yaptı ve farkında olduğum tüm durumlarda, sorunlardan birine veya her ikisine de rastladılar.

Bu nedenle, nadir de olsa, yazılımın VMware'de beklediğiniz gibi çalışmadığı durumlar olabilir.

Sorununuzun doğrudan yardımcı olmadığını fark etsem de, VMWare'in her zaman mükemmel bir sistem olmadığını gösteriyor.

Dipnot: bu durumda satıcı, çözünürlükleri (bazı kod düzeltmeleri, bazı VMWare yapılandırma değişiklikleri) bulmak için VMware ile çalışabildi ve artık yazılımı VMWare'de nasıl çalıştıracağına dair (çok spesifik) rehberliğe sahipler.


Tam olarak üzüldüğüm ama duyduğum için minnettarım - yanıtında Janne'den bahsettiğim gibi, VM'lerde doğru çalışan şeylere o kadar alıştık ki, bu kadar garip bir durum kümesi bulmak beni dürüst olmak için biraz şaşkın bıraktı , bu yüzden sizden duymak bu konuda yalnız değilim en azından rahatlatıcı. Henüz yazılım satıcısından olumlu bir şey duymadım ama problemi araştırdıklarını biliyorum, ne yazık ki bir ay için bir düzeltme düşünemiyorum. Tekrar teşekkürler.
Chopper3

3

ESX v5 ve Monster VM sınırı (32vCPU 1 TB RAM) ile VM ile ilgili sorun yaşayan uygulamaların sayısı azalıyor. Tecrübelerimin çoğu ya: - doğrusal olmak için zamana güvenmek (gerçek zamanlı süreçler veya doğrusal zamana sahip olması gereken uygulamalar ... bu genellikle değiştirilebilir) - çok fazla donanım kesintisine veya bağlam geçişine neden olan uygulamalar

Çoğu durumda, vmware temsilcinizden bu adamlarla konuşmasını isteyebilirsiniz. Ben vmware hala işler işe adanmış bir grup insan olduğuna inanıyorum (ilk günlerinde sadece bunun için bir destek laboratuvarı vardı).

Bir çözüme gelince, yüksek CPU kullanımı olan VM ile benzer bir sorun yaşadım (ancak ana bilgisayar bol miktarda CPU kaynağına sahip değil). Nehalem CPU'lu bir sunucuya geçip EVC'deki CPU uyumluluk düzeyini değiştirerek (DRS / HA ile bir kümeniz varsa) sorunu çözdük


Yanıtınız için teşekkür ederim - bu gerçekten siyah beyaz bir soru olmadığında çok naziksiniz. Örnekleriniz çok faydalı, geri dönüp özellikle bağlam değiştirmeyi inceleyeceğim. Oh ve tüm sunucularımız EVC'nin eşit olarak ayarlandığı CPU ile tamamen aynı CPU'larda (X5690), ama tekrar teşekkürler.
Chopper3

2

VMware ESX + Debian 6 + OpenLDAP 2.4.x ile aynı sorunu gördüm (OpenLDAP'ın tam sürümü ne olursa olsun ...).

Günlük operasyonlar altında sorunsuz çalışır, ancak 400 000 kadar giriş içeren büyük bir LDIF dosyasını içe aktarmak gibi şeyler çok yavaştır (fiziksel sunuculardan 50-100x daha yavaş). Ayrıca uzun süreli, yüksek hacimli kıyaslama ile her şey birkaç milisaniye tepki süresiyle sorunsuz bir şekilde ilerliyor, ancak bazen 500 ila 25 000 (!) Milisaniye arasında değişen garip zirveler var.

Fiziksel sunucularla bu sorunları yeniden oluşturamıyorum. Ve evet, yaklaşık üç hafta geçirdim, sorunu izole etmeye çalışarak, her türlü parametreyi işletim sistemi parametrelerinden tokatlanmış değerlere BerkeleyDB değerlerine ayarladım ... hiçbir şey yardımcı olmadı.


Deneyimlerinizi paylaştığınız için çok teşekkür ederim, tüm bunları biraz garip bulamadığımı söyleyemem - Deneyimler sanallaştırma geekiyim ve bunu yapan bir uygulama bulmak için çalışan şeylere çok alışkınım inançlarımı bir şekilde salladı, bu yüzden izole bir konumda olmadığımı duymak güzel. Teşekkür ederim.
Chopper3

1
Başka iki örnek: Atlassian hem söylüyor Jirave Confluencebir VM (eşya) ortamda çalışacak şekilde tavsiye edilmez. Bu istisnalar için bir model olmalı, henüz ne olabileceğini henüz çözemedim. OpenLDAP kurulumum çok G / Ç yoğun değil (3 MB / s yazma ve karşılaştırma sırasında piklerde çok fazla IOPS değil), belki% 20-40 CPU ve yaklaşık 150 MB RAM kullanıyor. Taşınması çok zor olmamalıdır. Belki diş açma ile ilgili bir şey vardır, ancak vmstat bağlam anahtarlarının vb normal seviyede olduğunu bildirir.
Janne Pikkarainen

Şu anki teorim bunun bunun OS zaman tutma ile bir ilgisi olduğudur. VMware geçmişte her türlü garip saat sorununa sahipti ve şimdi bile bazen tsc=pitönyükleme sırasında bazı şık parametreleri geçmeniz gerekiyor ve en azından OpenLDAP sistem saatinin doğruluğuna ÇOK duyarlı. Belki de tüm sorunlu uygulamaları zorlamalıyım ve hepsinin yoğun bir şekilde kullanılıp kullanılmadığını görmeliyim gettimeofday().
Janne Pikkarainen

Tekrar teşekkür ederim, VM'de zaman konusunda haklısınız, doğası gereği her yerde bu yüzden bunu anlıyorum ama yardımcı olamıyorum ama bu bir sorun olsa bile çok hızlı bir sorun olacağını düşünüyorum satıcılarımız kodlarını tespit etmek için, aslında zamana duyarlı bir uygulama olmadığını, sadece video içeriğini yakalar ve işler, hmmm. Tekrar teşekkürler.
Chopper3
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.