Administrace komentářů

Rekl bych, ze hodne bude zalezet na typu zateze, t.j. jake aplikace tam pobezi.

Pres 1 rok jsem provozoval Xen (openSUSE 10.2) v nasledujici konfiguraci: terminalovy server v domene 0 (kvuli rychlejsi odezve grafiky) a dva lamp servery ve virtualnich strojich. Masina mela 2 dvoujadrove CPU, 8 GiB pameti a SATA disky. Pri beznem provozu to fungovalo OK, ale problemy nastavaly ve dvou pripadech: (1) kdyz ve virtualni masine bezely procesy s intenzivnim zapisem na disk, pak terminalovy server (v domene 0) mel tak velke latence, ze uzivatele provozujici interaktivni procesy nadavali. (2) Nejaky proces (v nasem pripade uzivatelsky skript v matlabu) alokoval velke mnozstvi pameti a terminalovy server zacal swapovat (presneji "pageovat"). Krome velmi pomale odezvy se dely veci, ktere jsem nikdy na normalni swapujici masine nevidel (procesy v podivnem stavu, ...). Vetsinou jsem radsi rebootoval. Tipoval jsem to na chyby v (xen-) jadre. Soucasne verze uz tim mozna netrpi - nevim.

V kazdem pripade jsem nyni kvuli vykonu a stabilite presel na konfiguraci, kdy terminalovy server bezi pod normalnim jadrem (openSUSE 10.3). Na separatnim stroji (se dvema 1 GHz PIII) mi bezi 2 lamp servery ve virtualnich masinach pod Xenem (take openSUSE 10.3). Tahle konfigurace mi zatim vyhovuje, protoze interaktivni odezva u webovych aplikaci neni kriticka a ta stara masina to vykonnostne bez problemu zvlada.

Byt vami, tak bych se soustredil hlavne na ty latence pri interaktivnim pouzivani, kdyz probihaji nejake I/O operace (No, pokud by se spustil Beagle vsem 20 uzivatelum najednou, tak by to neutahlo ani klasicke jadro.) Mozna by stalo za to se mrknout na nabidku VMware. Xen je prima pro webove servery, ale u terminalovych serveru bych byl kvuli latencim opatrny.