Tisztelt kozosseg!
Egy olyan problemaba utkoztem bele amit nem birok megoldani sem a google, sem a meglevo telefonszamaim segitsegevel.
egy mssql2008 server nem hajtja ki a processorokat amik a rendszer rendelkezesere allnak... amikor feladatot kap csak szuttyognek a procik alig 1-2%os terheltsegen.
informaciok:
intel blade server, Xeon 5520-as procibol 2.
vmware ESXi telepitve (kesobb szeretnem upgradelni ESXre, ha lesz keret licencekre).
ESXi-re telepitve win2k3 enterprise 32 bit-es verzio.
telepitve mssql server 2008 enterprise.
az oprenszer latja a 8 magot amit kapott (eroforras allokacio biztositva a szamara, maxon).
mas alkalmazasokkal ki lehet hajtani a procikat, akar 100%ra is. ilyenkor latszik a vmware performance monitoran is a terheltseg. csak az mssql nem bir mit kezdeni a helyzettel.
sql serveren probaltam elhagyni az automatikus cpu affinityket es kezzel odaadni mindent. ugyanaz a helyzet. volt olyan feladat amit 15 percig csinalt a 8 magon, de csak 10 percig 1 magon, amikor annyit kapott. ha mar 2 magot kapott megint 15 perc volt a futasi ido.
amikor dolgozta fel a feladatokat (amik 15 percig tartottak az eromuvon, az 9 perc korul volt egy notebooknak, igaz ott a cpu dolgozott is rendesen :) ), az mssqlben levo monitor szerint osszesen 1% cput, 0% swapot es 0.4% I/Ot hasznalt.
mivel az oprendszeren kiterhelhetoek a cpuk, ezert raktam ide az SQL reszbe es nem virtualizacioba vagy windows temakorbe...
egyszeruen nem tudom elkepzelni mi lehet a nyugje. valakinek valami otlet?
udv
lipiqe
- 1956 megtekintés
Hozzászólások
biztos, hogy ez az MS SQL Server verzió?
Nem lehet, hogy licensz korlátosat próbálsz (free / express /whatever edition)? Az védi így magát.
- A hozzászóláshoz be kell jelentkezni
evallal is ugyanez.
- A hozzászóláshoz be kell jelentkezni
A nyolc magból úgy látom, hogy ez egy 4-es ESXi valamint nem olvastál előtte doksikat a VM-ek több magon való skálázhatóságáról.
Nyolc mag felesleges neki, szerintem (ha mindenképpen VMware-n akarod futtatni), kevesebb magot adj neki és nézz utána milyen finomhangolások segítenek ESX alatt az MSSQL-nek. Előbb próbáld meg a VM-en hyperthreadinget letiltani a VM-en (HT Sharing: None), ez 3.5 alatt néhány DB-nél segített. Az affinityt ne piszkáld.
Még valami: miért akarod lecserélni az i-t simára?
- A hozzászóláshoz be kell jelentkezni
A hyperthreading kikapcsolasa nagyon jo ottletnek tunik. Mi sem kapcsoljuk be (sem virtual sem fizikai gepeken).
Nehany link:
http://sqlblog.com/blogs/kevin_kline/archive/2007/08/18/the-perils-of-h…
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
http://news.cnet.com/Does-hyperthreading-hurt-server-performance/2100-1…
http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm
http://serverfault.com/questions/33515/current-wisdom-on-sql-server-and…
- A hozzászóláshoz be kell jelentkezni
az uj xeonokon a HT sokkal jobb, allitolag
- A hozzászóláshoz be kell jelentkezni
Kérdés az, hogy a guest számára is átlátszik-e, hogy melyik vCPU melyikkel közös? Ilyen Nehalem-es szörnyetegekkel nem volt még dolgom, azért kérdezem.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
me'g nekem se. ha lesz, szolok, es megnezzuk:)
- A hozzászóláshoz be kell jelentkezni
+1 Az i-t szerintem tök felesleges a "nagy" ESX-re cserélni. A service console-on paracssori machinálásokat ki lehet váltani remote VI API-val.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Neztem kevesebb maggal mint irtam... ha 1nel tobb volt mar tobb ideig szuttyogott vele...
hosszutavon a hibaturest szerettem volna vmwarekkel biztositeni. de igy mar eselyes, h kihagyom.
- A hozzászóláshoz be kell jelentkezni
Hibatűrésre csak úgy alkalmas egy ESX cluster, ha:
- vSphere 4 és Fault tolerance, állandó megoldásnak nem jó
- VMware HA cluster, azon belül alkalmazás cluter szétszórva a különböző hostokon és DRS rulenak, hogy ezek a VMek ne fussanak ugyanazon a hoston. Ha itt még meg tudod oldani, hogy VMek teljesen különböző tárolón vannak, akkor elég jó rendelkezésre állást érhetsz el.
Ezenkívül még van sok lehetőség biztosan. Nem olcsó, nem olcsó...
- A hozzászóláshoz be kell jelentkezni
azt tudom, h nem olcso... mar igy sem keves penz van vasakban.
de ugy latom vmware licenszbe mar nem lesz egy arva figying sem...
marad a regi jo gombolyu agyugolyo.
- A hozzászóláshoz be kell jelentkezni
nem licencelt VMware hogy támogat smp-t? Eval módban megy ez?
- A hozzászóláshoz be kell jelentkezni
Az eval csak időben korlátos nem funkcionalitásban. A free ESXi pedig teljes értékű egy darab fizikai gép erőforrásainak virtualizálására.
- A hozzászóláshoz be kell jelentkezni
Ok, eval módban sosem használtam.
- A hozzászóláshoz be kell jelentkezni
"- vSphere 4 és Fault tolerance, állandó megoldásnak nem jó"
Csak kérdezem, hogy ez miért nem jó?
- A hozzászóláshoz be kell jelentkezni
Szerintem nagy overheadje van, valamint megszorításokkal alkalmazható.
Állandó megoldásra szerintem os vagy alkalmazás szinten jobb megoldani.
- A hozzászóláshoz be kell jelentkezni
HT letiltasa sem segitett semmit :(
szitu ugyanaz
- A hozzászóláshoz be kell jelentkezni
:( pedig, ebben biztam kicsit.
- A hozzászóláshoz be kell jelentkezni
Nezd meg, hogy mit mutat az Activity Monitor
- "Resource Waits" tab, rendezd "Recent Wait Type" szerint csokkenobe
- "Processes" tab, mit mutat a "Wait Type" es a "Wait Resource"
Csak tipp, hogy lassuk varakozik-e valamire, vagy mas problema van.
Ha esetleg kozben megtalaltad a problemat, engem is nagyon erdekelne, mert most keszulunk mi is telepiteni hasonlo konfiguraciokat.
- A hozzászóláshoz be kell jelentkezni
Wait cat. wait time rec.wait time
logging 811 810
CPU 16 16
Buffer I/O 1 0
a tobbi minden nulla.
processes tab:
a wait resources oszlop teljesen ures.
- A hozzászóláshoz be kell jelentkezni
A "logging" magas (szerintem), ami azt mutatja, hogy a log kiirasa lehet lassu.
Ha a masik gepeden (nem virtual, laptop azt hiszem) ez az ertek alacsonyabb, akkor erdemes megnezned azt a disc alrendszert, ahova a log file-t tetted, ill. hogy mi van meg ott (pl.: pagefile veletlenul oda lett rakva).
Esetleg megprobalhatod attenni a log file-t mashova. Legyorsabb teszt a fenti eset kizarasara.
Vagy:
Hogy van beallitva a log file novekedes?
Ha a process sok adatot modosit, ami logot general es a log novekedes kicsi, akkor lassithat. Bar nem hiszem, hogy ez lenne a gond.
- A hozzászóláshoz be kell jelentkezni
Valami IO para lesz ebből. Én nemrég NFS-ről másolásnál jártam így. Guest ESX3.5-ön, felmountolva egy NFS export, amiről lokális diskre kellene másolni. A lokális disk vmdk-ban, alatta fizikai vinyó volt, lokálisan az ESX alatt, szóval semmi iSCSI és hasonlók. 3 órán át szüttyögött a másolással, közben CPU terhelés sehol, se az NFS szerveren se a kliensen. Natívan futtatott esetben (ugyanaz az OS, ugyanaz a NFS szerver, csak közvetlenül vasra rakva) 11 perc alatt végzett. Mivel az ESX-en futtatott példány volt a tesztrendszer, és a natív az elés, ezért nem álltam neki debuggolni, hogy mi volt a gond, illetve mi lehet rosszul beállítva, örültem, hogy az éles ilyen gyors lett.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
ez alatt egy vtrak storage van. SAS-el. eselyes, h azzal lenne gond?
de I/O terhelesre semmit nem ir a nyomorultja... ha meg filemuveletekkel es terhelessel jatszom, igen szepen teljesit a storage.
- A hozzászóláshoz be kell jelentkezni
Bár a SAS diszk elsőre jónak tűnik, jobb mintha SATA-t írtál volna, de ami file műveletekkel és szintetikus terheléssel jól muzsikál nem feltétlenül ad jó teljesítményt valós alkalmazás alatt pl. adatbázis.
Cache mennyi van a storageban? Csatlakoztatás?
- A hozzászóláshoz be kell jelentkezni
Unortodox ötlet: exportáld ki a VM-et és egy workstation alatt indítsd el. Változik így valami? Ha nem, akkor be lehet vetni Workstation-ben lévő rendszerhívás trace-elési funkciót (még nem próbáltam én sem, annyit tudok, hogy van, alapvetően pont ilyen profiling jellegű feladatokra való). Vagy ha nem akarsz ennyire ágyúval verébre, akkor a Windows Sysinternals csomagot kellene megnézni, abban vannak elég jó OS szintű process debugger toolok. Process explorerrel legalább annyit mindenképpen látni fogsz, hogy amikor éppen nem dolgozik az MSSQL worker threadje, akkor mégis mit csinál, mire várakozik.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Előfordulhat, meg kell nézni a cpu wait és ready értékeket is.
Bár a legegyszerűbb magyarázat, hogy belefutottunk a "minél többet" hibába és esetleg maradni kéne az egy cpu-nál (egy pont ilyen fizikai vason hogy fut le a teszt, ezt is meg kellene nézni, mielőtt ítéletet mondanánk, mert nem igazán kellene fizikai vas sebességét várni virtualizált környezetben, cserébe sok egyéb jóságért).
VMware tools telepítve van? Fut még más is azon a vason?
- A hozzászóláshoz be kell jelentkezni
nalam igen, tools telepitve. nem, nem fut mas a vason.
amikor egy cput adok neki, akkor gyorsabb ugyan a tobbi cpu-s megoldasnal, de azert meg igy is csak egy laptop szintjet eri el... azert ara miatt tobbet varnak :D
- A hozzászóláshoz be kell jelentkezni
Nézd, a virtualizáció nem megoldás mindenhova. Szerintem itt valami configurációs probléma lehet, mi elég sok MSSQL-t futtatunk 3.5 alatt, probléma nélkül.
Nem feltétlenül egy laptop szintjét éri el, próbáld meg egy kicsit összetettebb tesztekkel, lehet, hogy később fullad be a dolog ESX-en.
tipp: ESXi 3-ashoz nem kell semmi licencet venni(csak igényelni ingyen, lehet még az smp is megy), és ebből kettő valamint clustering az sql alatt és viszonylag jól állsz.
- A hozzászóláshoz be kell jelentkezni
A VMware perfomance doksik szerint eléggé közel vannak a natív teljesítményhez, és az ESX szerverek limitjei is (iops, hálózati áteresztő képesség, stb...) is elég magasak. Tehát a legtöbb helyre mehet simán.
A kérdező figyelmébe pedig ezt ajánlom.
http://www.vmware.com/files/pdf/perf_vsphere_sql_scalability.pdf
- A hozzászóláshoz be kell jelentkezni
Hát igen, nagyjából igaz is a legtöbb esetben. Itt szerintem valami konfigurációs probléma lehet inkább.
De akár(ez nem derül ki) régi/bugos firmware is lehet ludas valamelyik HW-ben. Kedvenc IBM szervereimen volt olyan, hogy RSA adapter USB kezelése vágta hanyatt a teljesítményt, egy bugos firmware miatt (vagy driver volt rossz már nem emlékszem, javítva lett gyorsan).
Lehetnek a limitek magasak, ha egyszer "elfogy" az I/O akár egy switchen(net|FC) vagy a diszkrendszeren. Aztán megy a nyavalygás, hogy lassú a VM|szar a virtualizáció. Közben csak tervezési hiányosságok vannak.
Egy érdekesség:
Egyszer egy rossz FC kábel miatt egy hoston olyan válaszidők voltak(mind a konzol reakció ideje, mind a VM-ek hálózati teljesítménye is), hogy nem hittük el. El telt egy kis idő mire kiderült, hogy egy kábel volt rossz.
Mindenesetre a topicindító helyében én még próbálkoznék a témával...
- A hozzászóláshoz be kell jelentkezni
Mindenképpen pl. VMware tudásbázis MSSQL témában
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…
Google. mssql poor performance on esxi
Két dolgot láttam vagy IO mert nem volt írási cache, másik esetben pedig a VM-ek memória kiosztásával volt a gond. 4GB volt a gépben és túl sokat osztott ki, mert van azért még memory overhead is.
Elképzelhető még valami fura hw/sw/beállítás konstelláció aminek ez köszönhető.
- A hozzászóláshoz be kell jelentkezni
orommel probalkoznek vele en is...
de idot nem kaptam. storage beallitasokat meg atkukkolom, ha ott nem talalok vmi megoldast, akkor a hetvegen megy a vasra direkt. nincs lehetosegem tovabb jatszani vele :(
Storage amugy egy vtrak promise, ami SAS kabellel van osszekotve egy intel modular server-el.
- A hozzászóláshoz be kell jelentkezni
Azert a fenti ket linket nezd meg nem tul hosszuak es a beallitasokat gyorsan tudod ellenorizni!
A storagerol cache ugyben tudsz valamit, esetleg egy rajz hogyan epul fel.
- A hozzászóláshoz be kell jelentkezni
Valaki latott mar ilyen storage eszkozt amit a topicindito hasznal. Esetleg lehet itt a problema, hogy nem birja? Cache?
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
vmware + parallel io = constant sucking
Szóval ne csodálkozz, mondhatni megérdemled, ha elhitted a vmware marketing bullshitet.
- A hozzászóláshoz be kell jelentkezni
Kifejtenéd?
- A hozzászóláshoz be kell jelentkezni
Mit fejtsek ki? Hogy a vmware úgy sz@r, ha IO intenzív rendszerben akarod használni -és főleg ha mindezt SMP guest-en próbálod-, ahogy van?
És közben a 3, 3.5 alatt végig azt mantrázta az összes marketingköcsög, meg vmw evangelista, hogy milyen jó, mert nem is rossz az IO teljesítmény, és amúgy is a vmware váltja meg a világot, valamint még a globális felmelegedést is megállítják, és a hajad is a fejedre nő vissza tőle, nem a hátadra...
Aztán kijöttek a 4-essel, és az volt a fő marketing kulcsszó, hogy -idézem- "Óriásit javult az IO áteresztőképesség, jelenleg már a natív IO 80%-át bírjuk nyújtani a guest-ek számára". Magyarán beismerték, hogy előtte lehazudták a csillagokat az égről, plusz a mostani amúgy elég gyatra állapotot megpróbálják "huge improvement"-ként beállítani, hogy ők mekkora jó fejek.
Tapasztalatból mondom, bármilyen SMP-s adatbázis terhelés esetén a vmware kb a natív teljesítmény 30-40 %-át tudja hozni. Ezek szerint a 4-es már talán akár 50-60-at is, kit érdekel. Ez a technológia baromira nem erre való, csak van egy rohadt jó marketinggépezetük, aki tud olyan baromságokat kitalálni, amit aztán nagyon sok marha vesz be.
- A hozzászóláshoz be kell jelentkezni
És még ő sz*pta be a marketing dumát?
- A hozzászóláshoz be kell jelentkezni
Nem mindegyik tech manager ért is ahhoz, amit csinál, simán belemennek az ilyenekbe, csak mert az XY cég salesei jól nyomják a dumát. Oszt te szopod a meleg fagyit, nem egy ilyet láttunk már...
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Jaja, előfordul ilyen. De az azért erős túlzás amit a kolléga ír.
Nem vagyok VMware evangelista, nem mindenhol megoldás a virtualizáció. De van, ahol el tudják fogadni az esetleges néhány százalék teljesítmény csökkenést(ami nem 30-40%), jó néhány egyéb hasznos dolog bevezetéséhez. Persze ott rendes design, resource és I/O tervezés is megoldható.
- A hozzászóláshoz be kell jelentkezni
Persze ott rendes design, resource és I/O tervezés is megoldható.
Hoppá, és itt ugrik a majom a vízbe, ugyanis ahol van rendes design, resource és IO tervezés, ott van rendes alkalmazás, és architektúra tervezés is. És ott ugye nem szükséges vmware azon problémák megoldására, amik a rossz alkalmazás és architektúratervezés, vagy azok komplett hiánya miatt csak vmware szerű tapaszokkal oldhatóak meg.
- A hozzászóláshoz be kell jelentkezni
Stop. Az alkalmazas/architekturatervezesi hianyossagokra a VMware megoldasai miota tapaszok? Ezt kifejtened?
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Sajnos de. Szerintem az egész virtualizációs témának egy elég nagy hajtóereje az, hogy a szar, rosszul megírt, rosszul karbantartott alkalmazásokat kicsit kevésbé szarrá lehet tenni azzal, hogy homokozóba zárjuk őket és körberakjuk mindenféle külső mankóval. Egymással nem kompatilis, egymást egy OS felett meg nem tűrő, vagy éppencsak különböző OS-t igénylő alkalmazások mégis együtt futtathatóak egy gépen. Security szempontból gyengén izolált dolgokat valamivel jobban izolálttá lehet tenni. Aztán snapshot kezelés pl egy-két "atomstabil" enterprise cucc alá elégé alap, majdhogynen napi szinten használt feature... Consolidated backup - azoknak akik vagy nem szeretnek OS és/vagy alakalmazás szintű backupolást csinálni, vagy eleve nincs ilyen funkcionalitás az alkalmazásban. Példa: egy működő DB-ről file szinten készült backup mennyire is lesz konzisztens? Semennyire!. A lockstep-es fault-tolerance pedig egy rakás kellemetlen kompromisszum ellenére egy keresett feature, mert sok az olyan alkalmazás, ami nem támogat hibatűrő clustert a saját szintjén, mégis jó lenne, ha valahogy hibatűrő lenne.
Sorolhatnám még sokáig, az egész virtualizáció szinte másról sem szól csak arról, hogy amit jó tervezéssel hatékonyan meg lehetett volna oldani az OS/alkalmazások szintjén, de nem oldottak meg (a szoftverek folyamatos fejlődését és véges fejlesztői erőforrásokat figyelembe véve ez még nem is biztos, hogy minden esetben a szemükre hányható), azt kívülről utólag kell rápótolni, kisebb-nagyobb kompromisszumok árán.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Nos igen, de ez azert messze nem a virtualizacio, mint technologia problemaja, hanem az emberi hulyesege. Mind a szoftverek kivalasztasanak/fejlesztesenak, mind a rendszerelemek megtervezesenek figyelembe kellene venni egy alap rendszertervet, ami altalaban nem szokott elkeszulni, hanem csak emberek adhoc modon dobaljak egymasra a teglakat, hatha igy is kijon valami piros csereptetos szogletes terbeli alakzat, amire ra lehet mondani, hogy haz.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Ugye te az egész IT-t csak bottal piszkálod, messziról?
Hoppá, és itt ugrik a majom a vízbe, ugyanis ahol van rendes design, resource és IO tervezés, ott van rendes alkalmazás, és architektúra tervezés is.
Hoppá, most lebukott az egész szakma. Egy ideális világban így kellene működnie. Hidd el vannak a földön ilyen helyek, ahol adnak az ilyenre.
És ott ugye nem szükséges vmware azon problémák megoldására, amik a rossz alkalmazás és architektúratervezés, vagy azok komplett hiánya miatt csak vmware szerű tapaszokkal oldhatóak meg.
De ott is lehet szükség VMware(de akár Hyper-V, XEN stb) megoldásokra. A VMware és az egész virtualizáció nem ilyen problémák megoldására való. Hanem új lehetőségeket teremt, amiket ki lehet használni. Nem gyógyír. És igen, az első mondatodban említett helyeken is lehet használni. Sőt, ott érdemes. Bár, ha ennyire ismered a hátrányait, biztos tisztában vagy az előnyeivel is (nem csak a VMwarenél).
- A hozzászóláshoz be kell jelentkezni
Ugye te az egész IT-t csak bottal piszkálod, messziról?
Hát, a környezetem inkább azt mondaná, hogy bottal, késsel, kukrival, miegyébbel, és leginkább nem piszkálom, hanem ütöm-vágom, ahol érem. És a lehető legközelebbről. Csak már nagyon elegem van a magyarországi "megoldásszállító" piacon dúló mérhetetlen dilettantizmusból, amit utána olyan eszközök alkalmazásával próbálnak palástolni, amik nem arra valók. Lásd e tekintetben akár a vmware-t is.
Hoppá, most lebukott az egész szakma. Egy ideális világban így kellene működnie. Hidd el vannak a földön ilyen helyek, ahol adnak az ilyenre.
Ja, vannak. Ezerből egy. Sajnos a világ, amiben jelenleg élünk, a felé halad, hogy "mindegy, csak valamennyire működjön valahogy ez is, az is, meg amaz is, vagy legalábbis elmondhassuk, hogy működik, még ha nem is". Ahelyett, hogy arra haladna, hogy "működjön ez megbízhatóan, biztonságosan, és lehetőleg költséghatékonyan, aztán majd erre épülve az, majd amaz".
Manapság a megoldásszállító nem dolgozhat jól, mert az a gazdasági érdeke ellen lenne, hiszen ki venne akkor oly drágán éveken át támogatást? Nem a projekt a nagy lóvé, hanem a támogatás, ezért minél komplikáltabb és "terheltebb" hibákkal egy komplex rendszer, a szállítónak annál jobb. Jelenleg a szándékos értetlenség és szakbarbárkodás korát éljük, ez van. Csak már rohadtul unom. És sajnálom azokat, akik utána a vacak marketing címszavak, meg a vendor ködösítések alapján várnak valamit egy terméktől, amit nem kaphatnak meg.
Nem mondom, hogy nincs szükség vmware-re egy szervezetben, és azt sem, hogy a vmware szar (legalábbis nem nagyon, vagy nem jobban, mint más hasonló megoldások). Csak azt mondom, hogy a honi szakma 90%-a valami olyasmit misztifikál bele ebbe az egészbe, amit nem kellene, és baromira nem a helyén kezeli a virtualizációs technológiákat.
És mikor mindezek után szembetalálkoznak azzal, hogy nem fenékig tejszínhab az élet, jön a sírás-rívás, hogy sok-sok pénz elverése után van egy halom ócskaságuk.
Amiért haragszom a vmware-re, az az, hogy ezt az egész "mindenre használjuk, mert mindenre jó, sőt, ha virtualizálsz a cégednél, még az asszony is 3 barátnőjével az ágyban vár otthon" szemléletet tudatosan erősíti, sulykolja az emberekbe, miközben ez baromság. Persze nekik meg ez a jól felfogott üzleti érdekük, de ettől még szabad őket utálni ezért.
Szerintem.
- A hozzászóláshoz be kell jelentkezni
Na, köszönöm, hogy képet kaptam a hazai helyzetről. Sejtettem, hogy ilyesmi állhat a dolog mögött.
Nálunk sem rózsás a helyzet, de rendes infrastruktúra van mögötte. Sokan nem értik, hogy sz*rból nem lehet várat építeni és verébre nem ágyúval kell vadászni.
- A hozzászóláshoz be kell jelentkezni
Sokan nem értik, hogy sz*rból nem lehet várat építeni
De lehet! Csak a szarból egyrészt önmagától nem épül fel az a vár, ahhoz elég komoly fejlesztési effortot kell még mindig beletenni. Ezt még nem kapod meg dobozos termékben egyik virtualizációs vendortól sem, talán soha nem is fogod, ezt kielégítően csak az alkalmazásfejlesztési szinten lehet megoldani. Másrészt pedig tudni kell, hogy ha szarból építed a várat, akkor ahhoz sokkal több alapanyag kell, és kicsit büdös is lesz a vár. Minél kevésbé akarod büdösre a várat, annál kisebb vár jön ki az alapanyagból.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Valóban lehet így is amennyiben a nem zavar a szag... :)
- A hozzászóláshoz be kell jelentkezni
Azert itthon az alkalmazasfejlesztesi szint is olyan, hogy "mindegy hogy, csak legyen mar szilardabb ez a trutyi, hogy legalabb az atadasig alljon a var".
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Na ez az, ami ezen a kicsi piacon nagyon sokmindenkiből hiányzik. Képtelenek különbséget tenni a célok között, és azt gondolják, az ágyú biztosan megöli a verebet is. Pedig nem... A bálnát, azt f@aszán, de a verebet el se találod vele.
Itt mindenki az aktuális buzzword-ben hisz, megrendíthetetlenül, és erre a hitre alapozva épít utána lég- vagy épp sz@rvárakat. De örömmel hallom, ha a világnak nem minden szegletében hasonló a helyzet.
- A hozzászóláshoz be kell jelentkezni
Hú ezt aztán jól kifejtetted... lol
- A hozzászóláshoz be kell jelentkezni
Végigolvastam a thread-et és valamit nem értek. Mi köze ennek a vitának ahhoz, hogy az MSSQL nem hajta meg a CPU-kat teljesen, míg más programok igen?
- A hozzászóláshoz be kell jelentkezni
Ez így van.
- A hozzászóláshoz be kell jelentkezni
Úgy érted, hogy mivel az MSSQL IO intenzív alkalmazás, rosszul teljesít VMware-en és a többi alkalmazás, mivel nem IO intenzív, jól teljesít? Akkor mire használjunk VMware-t? Webszerver, vagy más alkalmazás szerver is lehet IO intenzív, egy levelezőrendszer pláne. Komolyan érdekel, mire jó akkor a VMware? :)
- A hozzászóláshoz be kell jelentkezni
Lehetne, hogy uj topikot nyissatok, mondjuk "Mire jo a VMware?" cimmel!
- A hozzászóláshoz be kell jelentkezni
Jelenesetben ez a probléma(mármint ez az SQL nem úgy teljesít ahogy elvárta a kedves topicindító).
Sok mindenre jó a VMware... Kérlek ne kezdd el te is :)
- A hozzászóláshoz be kell jelentkezni
Szvsz. a fenti egy sarkos velemeny volt, mint mas is irta nem ennyire rossz a helyzet. Az igazsag valahol a ketto velemeny kozott.
- A hozzászóláshoz be kell jelentkezni
Egy webszerver vagy levelezoszerver nem ugyanolyan IO-forgalom mintaval rendelkezik, mint egy adatbazis szerver. Az adatbazisszerverekre jellemzo a random iras/olvasas, hatalmas fajlokon belul gorognek, es esetenkent a fajl kozepehez irnak hozza, ami ugye novelessel jar. Egy webszerver/levszerver viszonylag kis fajlokkal dolgozik, olvasaskor azokat vegig olvassa, iraskor legrosszabb esetben is a fajl vegehez fuz hozza tartalmat (Exchange adatbazis mintaval rendelkezik inkabb). Szoval nem, nincs igazad.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Értem. Az Exchange, amikor utoljára láttam egy 2003-asat, 2 fáljlban tárolta a leveleket. Mi van akkor, ha egy 1000 postafiókos adatbázisra be van állítva egy policy, hogy a 30 napnál régebbi leveleket ki kell emelni és akárhova máshova át kell pakolni? Van egy több 10GB-os fájlod, amiből mondjuk 200MB-ot kell 5-500kbyte-os levelek formájában kiszedni és egy másik fájlhoz hozzáfűzni.
- A hozzászóláshoz be kell jelentkezni
Jellemzően egy levelezőrendszerben ezeket a dolgokat 1 szál végzi. Tehát 1 CPU-n. Az adatbázisnál az a probléma, hogy nekilát az 1 baromi tábla teljes felolvasásának, 16 szálon, 8 processzoron, szekvenciálisan. De minden folyamat csak önmagában szekvenciális, egymásnak viszont nagyon szépen keresztbevernek. Ilyesfajta IO contention ritkán fordul elő egy levelezőrendszerben, és szinte egyfolytában az adatbázison. Ezért mondja a kolléga, hogy nagyon más terhelési mintát okoz egyik és másik.
Egyébként webszervernek nem olyan rossz, java alapú alkszervernek már határeset, sok múlik a szálkezelés megvalósításán, és az alkalmazás jellegén. Adatbázis esetén csak igen speciális, idealizált esetekben tudnám hatékonynak elképzelni, de aki annyi gondot áldoz az alkalmazása megtervezésére, az már nem biztos, hogy a pc virtualizációs klubban pólózik.
- A hozzászóláshoz be kell jelentkezni
Nem veletlenul irtam zarojelben azt, hogy az Exchange adatbazis jellegu mintaval rendelkezik inkabb, hanem azert, hogy utaljak ra: amit irok az nem teljesen igaz az Exchange-re. De egy Linuxos smtp szerverre igen.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Ez ugy, ahogy van, kolosszalis faszsag.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Én is örülök a jól kimunkált, érvekkel és tapasztalatokkal gazdagon alátámasztott hozzáértő véleményednek, köszönöm.
- A hozzászóláshoz be kell jelentkezni
esxi -hez nem értek, egyszer játszottam vele egy 8 magos gépen, de nem felelt meg, mindegy.
ugyhogy nem az esxi-vel kapcsolatos a hozzászólásom, hanem általánosságban mondom:
van pár ilyen ember mint te, hogy ideböfögsz egy sok soros fasszságot, aztán valaki, aki az adott témához jobban ért, csípőböl rámonjda, hogy fasszság, nyílván, mert ismeri az adott dolgot, és az. erre az ilyenek, mint te, folyton azt követelik, hogy mondja meg, hogy pontosan mi a fasszág.
elmondom: minden szó, amit leírtál, egy hatalmas fasszság bazmeg. és nem fogja senki soronként neked érvekkel, linkekkel megindokolni, hogy miértt, mert szarik a hülyeségeidre meg a lelkivilágodra is. olvass utánna magad, de inkább azelőtt, hogy beböfögsz valami baromságot.
- A hozzászóláshoz be kell jelentkezni
Ezt azért keményen benyaltad, maradjunk ennyiben.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg maradjunk annyiban, hogy itt állítás áll állítással szemben. Bizonyíték/indoklás/érvelés hiányában nem igazán lehet eldönteni, hogy ki nyalt be és mit.
Ha valaki lefikáz én is mondhatnám azt, hogy "kis hülye, te nem tudod, hogy én egy 50000 gépes infrastruktúrát menedzselek és ráadásul én fejlesztem azt amiről te beszélsz, TEHÁT NEKEM VAN IGAZAM".
Nem mondom.
Mellesleg nem is igaz, de ettől még lazán mondhatnám, viszonylag kevesen tudnák/vennék a fáradtságot leellenőrizni, hogy az az 50000 valójában inkább csak 50. Viszont talán már bannoltak volna innen, ha sokat mondogatnám, bár tény, hogy trey néha meglepően türelmes.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Ebben neked tökéletesen igazad is van, ezért nem kezdtem el bizonygatni a történetemet, mert egy ilyenre minek...
Mondjuk én azért érveltem, nyilván bizonyítani meg akkor tudok, ha idejössz, és megmutatom, mi a trágya.
Ha valaki ezzel szembe akar szállni, minimum érvel, és ha bizonyítani akar, idejön, és megmutatja, mit rontunk el. Megfizetnénk, hidd el.
Az, ami véleményem kialakult az adott dologról, azért alakult ki, mert sokat szívtam vele, miatta. Sok helyen.
Bárkitől szívesen venném a tapasztalataim cáfolatát vmware terén, hidd el, és én lennék a legboldogabb, ha sikerülne felülemelkedni ezeken a problémákon. Csak sajnos elég sokan próbáltak nem kevés pénzért fogást találni ezeken a gondokon, és valahogy mindegyik kísérlet kudarcba fulladt, igazán segíteni senki sem tudott.
A normálisabbja némi izzadás után javasolta, hogy ilyesfajta terhelést ne rakjunk oda (köszi nekik, magamtól is tudtam, de a managerek csak standardokban tudnak gondolkodni), a többi csak elsunnyogott.
Nem tudom, miért fáj egyeseknek az, ha azt mondom valamire, hogy az arra a bizonyos speciális feladatra nem optimális, amire épp próbálják használni...
Sok soros "ödaböfögésem" meg azért volt, mert valaki kérte, fejtsem ki a véleményem, így gondoltam megér pár szó magyarázatot, mi alapján gondolom azt amit, ahelyett, hogy csak egy sorban lefikáznám azt, amit esetleg egyébként csak annyira tartok.
Minderre idejönni arcoskodni, hogy én vagyok a gyengeelméjű, mert csak mondom a magamét, és ő mennyivel tutifrankóbb és kussoljak, na az kimeríti a prosztóság fogalmát.
- A hozzászóláshoz be kell jelentkezni
Szűz install 2008 volt, vagy esetleg valamilyen imageből lett hozva?
- A hozzászóláshoz be kell jelentkezni
szuz
- A hozzászóláshoz be kell jelentkezni