Kibarca nasıl? Yazılım satıcısına ne hakkında konuştuklarını bilmediklerini söyleme

Teknik bir soru değil, yine de geçerli bir soru. Senaryo:

2 x 8 çekirdekli Xeon E5-2667 CPU'ya ve ESXi 5.5 çalıştıran 256 GB RAM'e sahip HP ProLiant DL380 Gen 8. Belirli bir satıcının sistemi için sekiz VM. Test için dört VM, üretim için dört VM. Her ortamdaki dört sunucu, örneğin web sunucusu, ana uygulama sunucusu, OLAP DB sunucusu ve SQL DB sunucusu gibi farklı işlevler gerçekleştirir.

CPU, test ortamının üretimi etkilemesini önleyecek şekilde yapılandırılmış. SAN.

Performansla ilgili bazı sorularımız oldu ve satıcı, üretim sistemine daha fazla bellek ve vCPU vermemiz gerektiği konusunda ısrar ediyor. Ancak, vCenter'dan mevcut tahsislere dokunulmadığını açıkça görebiliyoruz, örneğin: ana uygulama sunucusundaki CPU kullanımının aylık görünümü,% 30'a varan oranlarda% 8 civarında seyrediyor. Sivri uçlu tekme yedekleme yazılımı ile çakışma eğilimindedir.

RAM'deki benzer bir hikaye - sunucular arasında en yüksek kullanım rakamı ~% 35'tir.

Bu nedenle, İşlem İzleyicisi'ni (Microsoft SysInternals) ve Wireshark'ı kullanarak bir miktar kazı yapıyoruz ve satıcıya önerimiz, ilk durumda bazı TNS ayarlamalarını yapmaları. Ancak, bu nokta dışında.

Sorum şu: Onlara gönderdiğimiz VMware istatistiklerinin daha fazla RAM / vCPU'nun yardım etmeyecek kadar kanıt olduğunu nasıl kabul etmelerini sağlarız?

--- GÜNCELLEME 12/07/2014 ---

İlginç bir hafta BT yönetimimiz, VM tahsislerinde değişiklik yapmamız gerektiğini söyledi ve şimdi işletme kullanıcılarından bir süre daha bekliyoruz. Garip bir şekilde, iş kullanıcıları, uygulamanın belirli yönlerinin yavaş çalıştığını söyleyen kullanıcılardır (neye kıyasla, bilmiyorum), ancak sistemi ne zaman yıkabileceğimizi "bize bildirir" , homurdanma!).

Bir yana, sistemin "yavaş" yönü görünüşte HTTP (S) elemanı değil, yani: çoğu kullanıcı tarafından kullanılan "ince uygulama" dır . Ana finans kuruluşları tarafından kullanılan, “yavaş” olan “şişman müşteri” kurulumları gibi gözüküyor. Bu, şu anda araştırmalarımızda müşteri ve müşteri-sunucu etkileşimini göz önüne aldığımız anlamına geliyor.

Sorunun ilk amacı, "dürtmek" rotasından aşağı inmek ya da sadece değişikliği yapmak için yardım aramaktı ve şimdi değişikliği yapıyoruz, longneck'in cevabını kullanarak kapatıyorum .

Girişiniz için hepinize teşekkür ederim; Her zamanki gibi serverfault bir forumdan çok daha fazlasıydı - bir psikoloğun koltuğu gibi bir şey :-)

İstedikleri ayarlamaları yapmanızı öneririm. Ardından, onlara fark yaratmadığını göstermek için performansı kıyaslayın. Bunu yapmak için LESS hafızası ve vCPU ile kıyaslama yapmak için bile gidebilirsiniz.

Ayrıca, "Yazılımı, tahmini çalışmalarla değil, gerçek çözümlerle desteklemeniz için size para ödüyoruz."

Size güvende olmanız şartıyla, verdikleri sistem özellikleri dahilindedir.

Ardından, daha fazla RAM veya CPU gerektirmekle ilgili iddialarını yedekleyebilmeleri gerekir. Sistemindeki uzmanlar olarak, insanları bunu hesaba katmak için tutuyorum.

Onlara ayrıntılarını sor.

• Sistemdeki hangi bilgiler daha fazla RAM gerektiğini gösterir ve bunu nasıl yorumladınız?

• Sistemdeki hangi bilgiler daha fazla CPU gerektiğini gösterir ve bunu nasıl yorumladınız?

• Sahip olduğum veriler - ilk bakışta - bana söylediklerinizle çelişiyor. Bana bunu neden yanlış yorumladığımı açıklayabilir misiniz?

• Bu [açık veri dizisi] ile [açık yorumlama] demek için yorum yapıyorum. Sorunumla ilgili doğru yorumladığımı doğrulayabilir misiniz?

Geçmişte destek ile uğraşırken aynı soruları sordum. Bazen haklıydım ve dikkatlerini problemime doğru şekilde odaklamıyorlardı. Ancak diğer zamanlarda hatalıydım ve verileri yanlış yorumluyordum veya analizimde önemli olan diğer verileri içeremiyordum.

Her durumda, bu iki durum da benim için net bir yarardı , ya daha önce bilmediğim yeni bir şey öğrendim - ya da iyi bir temel neden bulmak için sorunum hakkında daha fazla düşünmek için destek ekiplerine sahibim.

Eğer destek ekibi size argümanlarının mantıklı bir şekilde genişlemesini sağlayamıyorsa, tatmin olabileceğiniz bir temelde (kendinden ödün vermek için açık bir zihne sahip olmanız gerekir, verinin yorumunu yanlış kabul etmek kabul edilebilir) onların tepkisi çok mevcut olmalı. En kötü senaryoda bile, sorunu sorunun giderilmesinde temel olarak kullanabilirsiniz.

Önemli olan sistem tahsisiniz için en iyi uygulamaları, özellikle de SQL sunucunuz için RAM ve CPU rezervasyonlarını kullandığınızı kanıtlayabilmektir.

Bütün bunlar söylenmenin en kolay yolu, en azından geçici olarak istenen düzeltmeleri yapmak. Başka bir şey yoksa, satıcıları ayakları üzerinde sürükleyerek alma eğilimindedir. Hattın diğer ucundaki bir teknolojiyi tatmin etmek için böyle bir çılgınca bir şey yapmam için gereken süreyi, yazılımın gerçekten davranmamasını sayarak sayamıyorum.

Bu özel durum için (VMware ve uygulama geliştiricilere sahip olduğunuzda veya kaynak tahsisini anlamayan üçüncü bir tarafa sahipseniz ), gerçek kısıtlamaları belirlemek için vCenter Operations Manager'dan (vCops - gerekirse bir demo indirin ) bir haftalık ölçütler kullanıyorum uygulamanın VM'lerinin darboğazları ve boyutlandırma gereksinimleri.

Bazen, VM rezervasyonlarını değiştirerek veya çekişme senaryolarını ele almak için öncelikleri değiştirerek daha inatçı tüketicileri tatmin edebildim; " Eğer RAM | CPU sıkı ise, VM'iniz öncelik kazanacaktır! ". Yazılım üreticilerinin vSphere kümelerimdeki gereksinimlerini gerçek bir analiz yapmadan dikte etmelerine izin verdiğimde kötü şeyler meydana geldi .

Ancak genel olarak, sayılar ve veriler kazanılmalı.

Tomcat uygulamasının geliştiricisine VM boyutlandırmasını doğrulamak için kullandığım bir şeye örnek:

Dev : VM'nin MOAR işlemci ihtiyacı var!

Ben : Bellek, en büyük kısıtınızdır ve işte performansınıza göre zamana karşı bir ısı haritası ... Saat 18: 00'de Çarşamba günleri en stresli dönemlerdir. Oh, işte son 6 haftalık üretim ölçütlerine dayalı bir boyutlandırma önerisi ...

Desteğe çalışırdım - ve sorduklarınızın bir kısmı oldukça mantıklı geliyor (ve muhtemelen): ama sadece istedikleri "performans geliştirme" yi yapmadan önce kendinize sormanız gereken birkaç soru var.

• Çalıştırdığınız en azından zaten satıcının belirtilen minimum sistem gereksinimleri?
• en azından asgari sysreq kullanıyorsanız, zaten "önerilen" sistem ayarlarında mısınız?

Satıcılar 100 üzerinden 99 kez (deneyimlerime göre - hem destek tarafında hem de müşteri / saha tarafında) sistemler belgelerinin gerektirdiği şekilde eşleşene kadar performansla ilgili sorunlarla bile ilgilenmeyeceklerdir. Belki 1 CPU ve 512M RAM ile zamanın% 99,5'inde çalışan bir sistemdir - ancak sistem gereksinimleri 4 CPU ve 4G RAM diyorsa ve sadece 2 CPU ve 1G RAM'iniz varsa daha fazla kaynak talep edilmesini isteyin ^* .

Laboratuvarda / geliştirmede buldukları bir şey nedeniyle sistem kaynaklarını arttırmanızı istemeleri muhtemeldir; burada belirli bir eşiği geçerseniz bir sorun sihirli olarak kaybolur; eğer durum buysa, evet, sonunda potansiyel olarak fakir bir hata ayıklama örneğidir, ancak ortaya çıkan her olası hata / sorunu ortadan kaldırmak için zamanları olmadığını - bazılarının üzerinde çalışılması gerektiğini unutmayın. burada durum bu, sadece onunla gidin.

Ayrıca, gördüğünüz konuların "kendi" yazılımlarının bir parçası olmadığı, başka bir kaynaktan (satıcı, OSS kütüphanesi, vb.) Dayandıkları bir bileşen bile olmadığı kadar önemsiz bir şans da var. Birkaç yıl önce bir müşteride takas büyüklüğü, BEA WebLogic ve Sun JRE ile ilgili bu kesin durumla karşılaştım .

tl; dr:

Kısacası, destek ekibiyle birlikte çalışın, bir çözüm bulana kadar gerektiği kadar yükselin - ancak bazı öneri / hata ayıklama adımlarını / düzeltmelerini yaparken duvardan veya anlamsız sesler geldiğinde şaşırmayın.

^{* _{Eğer bu ilave kaynaklara gerçekten "ihtiyaç duymazsa", gelecekteki sürümler için bir doktora hatası / RFE dosyalayabilecek bir yerdesiniz - ancak bu yolun olmadığını gösterene kadar bu rotayı zorlamayın elimizdeki sorun}
^ _{a e-Kitap Bu konuda yardımcı bulabileceğin şeyler yazdım: Hata Ayıklama ve Destek Yazılım Sistemleri}}

Ya bileti yükseltmek isteyin ya da farklı bir temsilci isteyin. Hangi destek sağlayıcısına bağlı olacağına bağlı olarak, mevcut destek düzeyinin sorunu yeterince karşılamadığını düşünüyorsanız Eğer tırmanmayacaklarsa, farklı bir temsilci istemek yardımcı olabilir çünkü bunun için çok daha az “gerekçe” gerektirmektedir, çünkü ihtiyaç duyulan tek şey mevcut olandan memnun olmak değildir.

Büyük bir satıcı ise, sadece bileti kapatmak ve aynı konuda yeni bir tane açmak, farklı bir temsilciye yönlendirilebileceğinden işe yarayabilir, ancak kötü bir form olduğu için buna karşı tavsiyede bulunabilirim.

Ayrıca, dayanağınıza dayanabilir ve daha fazla RAM / vCPU'nun nasıl yardım edeceğine dair bir gerekçe sorabilirsiniz veya yardım etmeyeceğini ispatlamak için daha fazla RAM / vCPU verebilirsiniz.

İki kuruşumu atacağım. Bu yaklaşımda oldukça başarılı olduk - çok daha iyi sonuçlar ve herkes için daha az hayal kırıklığı. Suçlama oyunundan çok daha fazla çaba gerektiriyor ve kör bir şekilde kaynak ekliyor, ancak altta yatan sorunu bulma şansı da daha yüksek.

Satıcı destek sözleşmeleriyle desteklenen şirket içi uygulamalarımızla ciddi sorunlarımız olduğunda ve satıcılar atlatmalı karışma danslarına başlar (bu da her zaman daha fazla CPU veya RAM için veriye dayalı olmayan talepleri içermekte). şu 3 şeyi yap:

1. Önemsizliği sisteme düşürme eşdeğeri değerine yükseltin - genellikle balklanırlar, ancak teknik olarak “çalışıyor olsalar” bile etkili bir şekilde kullanılamaz olduğunu açıkladığınızda geri çekilirler. Bunu çözmek için ciddi bir sorun olarak kabul edin. Buralarda, tüm paydaşlardan durum güncellemeleri almak için günlük olarak toplanan bir kaplan takımı olarak söz ediyoruz. Genellikle satıcı sizden malzeme değiştirmenizi isteyecektir. Prod bir sistemse, bu sorunludur, ancak onların yardım etmesini istiyorsanız, problemi izole etmelerine yardımcı olma sorumluluğunu kabul etmeniz gerekecektir, bu nedenle testleri gerçekleştirebileceğiniz bir geliştirme / hazırlık ortamına sahip olmanız gerekir.

2. Satıcıya, ortamınızı çoğaltmasını istediklerini, böylece sorunu laboratuvarlarında izole edebilmelerini söyleyin. Gerekirse bazı bulut ortamlarında bile eşyaları barındırabilirler. Bu ideal olsa da, çevrenizle tam olarak eşleşmesi gerekmez. Mesele şu ki, SATICI'nın sorununuzu çoğaltmaya aktif olarak çalışmasını istediğinizden emin olun, böylece onların tahminde bulunup bulunmadığını kendi sisteminizde test edebilirler. Yaptıklarından emin olmak için bu çoğaltılmış ortamın şemalarını, özelliklerini vb. İsteyin.

3. Onlara (elbette NDA kapsamında) gerçek veri setinizi verin, böylece tahmin etmek yerine gerçek olarak çalıştırabilecek / yeniden oynayabilecekler. Bizim durumumuzda, satıcı tarafından sağlanan uygulama sorunlarımızın çoğu (hem geçici hem de kronik) çoğu zaman birlikte verilen satıcı tarafından sağlanan veritabanlarıyla ilgili sorunlara yol açmaktadır. Bunu yaptığımızın sayısını sayamıyorum ve nihayet sorunu gerçek verilerde beklenmeyen bir şeye indirdiler - 2 yıl önce bir uygulamanın düzgün bir şekilde dönüşmediği uygulama yükseltmelerinden garip eserler; GC ayarlarında bir sorun ortaya çıkaran eski kayıtlar; Verilerimiz, satıcı kodunda bazı transmog rutinini kırdığı için doğru çalışmaz, sorgular tam anlamıyla işe yaramaz.

Bunu son birkaç yıl içinde birkaç satıcıyla yaptık ve başlangıçta bizim yolumuza çok dirençli davranıyorlar. Ancak, çalıştıktan sonra, tedarikçilerimizle yaptığımız üç aylık incelemelerde her zaman olumlu bir vurgu olarak ortaya çıkıyor. Ve bu satıcılarla olan teknik ilişkimizi güçlendirmeye yardımcı olur. Belirsiz problemler istemiyorlar. Ürünlerini geliştirmek için analiz edebilecekleri belirli problemler istiyorlar.

Öneri yardımcı olur umarım. Bunun tek bedene yakışan bir yaklaşım olmadığını biliyorum, ama eğer sallandırabilirseniz bence buna değer bulursunuz.

Asıl soru, burada kimin sorumlu olduğunu? Gerçekçi bir satıcıya gerçekçi bir şekilde geçemezseniz, o zaman güçleri vardır ve gerçekten yapabileceğiniz tek şey ne söylerlerse işe yarayacağını ummaktır. Mutlu bir durum değil! Aksi takdirde, başka bir temsilciye sormanızı öneririm (diğerlerinin dediği gibi), ancak hizmetten memnun olmadığınızı ve işi yapamıyorlarsa başka yerlere bakacağınızı açıkça belirtin.

İşe yaramayacaklarından eminseniz, yalnızca "önerdikleri ayarlamaları yapmayın", çünkü uzun vadede sizi incitecek olan ilişkiniz için bir kalıp oluşturur. Size bir hizmet vermeleri için onlara para ödüyorsunuz ve eylemlerinizi evimi boyamak için kiraladığım birinden daha fazla dikte edememeli, ne renk olacağını belirler.

Kulağa çok sert gelebilir, çünkü bu kulağa oldukça kritik bir konu değil gibi geliyor, ama gerçek şu ki, eğer sizi küçük bir şeyle uğraşıyorlarsa, muhtemelen aynı şeyi büyük bir şey için yapacaklar ve istediğiniz son şey çizgiden altı ay sonra korkunç bir tür charlie foxtrot ile karşılaşmak ve satıcıyla aynı problemi yaşamak.

Şimdi sorunu çözmek için attığınız adımların, son başvuru tarihinden iki gün sonra ve her şey bozulduğunda eşit derecede iyi çalışacağından emin olun ...

Satıcı tarafından bir görünüm yayınlayacağım.

Yazılımın performansının birkaç saatte bir düşmesine ya da tam anlamıyla berbat bir hıza düşmesi ve ardından birkaç saat sonra geri gelmesi durumunda bu tekrarlayan sorunu yaşadık.

Sistemdeki bulitin profili, sistem CPU'sunun (veya muhtemelen belleğin) hızının, beklenen 2GHZ'den ziyade 100MHZ gibi bir şey olduğu kadar iğrenç derecede yavaş olduğunu belirtti. VM tarafından sağlanan CPU’nun iki katına çıkarılması semptomu değiştirmedi ve israf ettiğimizi düşünüyorlardı.

Daha hızlı bir CPU alamadıkları için (daha fazla CPU yardımcı olmayacaktı), daha sonra TEST ve PROD VM'lerini değiştirmeyi denedik. Sorun daha sonra ertesi gün TEST'te ortaya çıktı. Sonra müşterilerden birini bağımsız (sunucusuz) bir örneğe terfi ettirmeyi denedik. Sunucu boğulurken bu iş istasyonunda sorun yok.

VM sunucusundan hiçbir performans sorunu olmadığını belirten raporlar hazırladılar ve bunun bir uygulama sorunu olduğunu iddia etmeye tekrar çalıştılar.

Sonunda ben [bir mühendis] (özel bir destek rolü olanlardan sıfır destek aldım) özellikle fiziksel bir kutu istedi. Müşteri kanlı cinayeti çığlık attı ama başka bir potansiyel çözümü olmayan hiç kimse bunu yapmadı. Ne biliyorsun, sorun sihirli bir şekilde ortadan kayboldu.

Sorunun ne olduğunu asla bulamadık. Tüm kıyaslama programları normaldi ancak uygulama profilcisi bize bilgi işlem kaynaklarının yeterli olmadığını söylüyordu. Şu anda profilleyicide aradığımız belirli bir imza var. Bunu görürsek, daha ileriye gitmeden önce sorunun VM etkileşimi olduğunu biliyoruz, ancak o zamanlar henüz bilinmiyordu.

Kesinlikle onunla dolu olduğumu sandılar. Ben değildim Seçeneklerin dışındaydım.

EDIT, yıllar sonra güncelleme:

VM'lerde çalışmak isteyen ve gittikçe daha fazla sayıda müşteriyle ve sorunu ne pahasına olursa olsun çözmeye çalışmak isteyen yönetim sayesinde, iyi VM donanımımız var. 512 MB RAM'e sahip iki tek çekirdekli VM'de kullanıcı alanında çalışan (ve ayrıcalık gerektirmeyen) özel bir VM yazma programı oluşturabildim, yalnızca 4 çekirdekli VM'den 1/3 bellek performansını 1/3 drene edebildi. VM sunucusunda kullanılan 16 bilgisayardan toplam çekirdeği ve ram'ının çoğu hala ücretsiz. Program alarm vermedi ve VM ana bilgisayarında veya konukların hiçbirinde normalden hiçbir şey göstermedi, bellek erişimi yavaştı.

Artık müşterilerimize VM'lerde bir sorun olduğunu bildiğimizi söyleyebiliriz ve bu bizim yazılımımız değil. VM uyumlu yazılımlar için zaman zaman müşteri isteklerini hala alıyoruz. Neden yönetimin, desteklerin aynı ana bilgisayardaki diğer tüm VM'leri yavaşlatan bir yazılım geliştirebileceğimizi söylemesine izin vermediğini merak ediyorum.

Korkutucu olan şey, ilgili teknik kilitsiz senkronizasyon içeren iyi bilinen bir programlama tekniğinin basit bir dönüşümüdür. Yüzlerce yazılım satıcısı bu VM süzgecini yazılımlarında kullanabilir ve bilmez. Sıcakca tartışılan bir atomik talimat kilidi almak nadir olmalı ancak imkansız olmamalıdır. Tüm bunların eğlenceli yanı, ACROSS VM'lerine itirazda bulunmak için kilit almaktı.

Şimdiye kadar bahsedilenlere çok farklı bir yaklaşım önerebilirim. Satıcı ile tartışmadan önce, neden bildirilen soruna daha yakından bakmadığınızı ve bunun size ne ifade ettiğini görün.

Rapor edilen asıl sorun nedir ve kullanıcıların beklentileri nelerdir. Bir kullanıcı "çok uzun süren" bir şey söylüyorsa, onlara tam olarak ne olduğunu (böylece yeniden üretebilirsiniz), ne kadar sürmesi gerektiğini ve neden bu kadar uzun sürmesi gerektiğini düşündüklerini sorun. Beklentileri makul ise, yapmaya çalıştıkları şeyin gerçek performansını ve sistem etkisini ölçün. Sisteminizin bir ay içinde% 30'luk bir artış göstermesi, kullanıcı sorgusunu denediğinde% 100'den fazla çalışmadığı anlamına gelmez. Eğer satıcınıza cpu ve hafızanın sorunlu görev tarafından zorlanmadığını gösterebilirseniz, satıcınızdan size maliyeti yüksek olan önerileri doğrulamasını isteyebilirsiniz.