Fórum Root.cz
Hlavní témata => Software => Téma založeno: JanS 10. 02. 2016, 14:49:35
-
Zdravim,
existuje nejaka moznost, jak zmrazit a zakonzervovat nejaky bezici proces/skupinu procesu, a spustit jeho pokracovani pozdeji i treba po restartu systemu?
Background: v zasade jde o to, ze mam dualboot, pricemz v jednom systemu obcas bezi dlouhe vypocty (v radu dnu). Obcas je ale potreba se prepnout do druheho systemu. Hibernace je urcite reseni, ovsem ne vzdy se hibernace, resp. probuzeni z ni podari. To mi prijde jako problem systemu, nepodarilo se mi zjistit, co presne neprobuzeni zpusobuje. Vypocetni session obvykle bezi v tmuxu, aby byly pristupne i odjinud.
-
To nevím, ale co využívat nějakou virtualizaci?
Mít na pozadí hypervizora ve kterém se nepracuje a mít pak n virtuálních strojů tak, aby nezbytný restart jednoho nenarušil chod dalších?
-
Zdravim,
existuje nejaka moznost, jak zmrazit a zakonzervovat nejaky bezici proces/skupinu procesu, a spustit jeho pokracovani pozdeji i treba po restartu systemu?
Background: v zasade jde o to, ze mam dualboot, pricemz v jednom systemu obcas bezi dlouhe vypocty (v radu dnu). Obcas je ale potreba se prepnout do druheho systemu. Hibernace je urcite reseni, ovsem ne vzdy se hibernace, resp. probuzeni z ni podari. To mi prijde jako problem systemu, nepodarilo se mi zjistit, co presne neprobuzeni zpusobuje. Vypocetni session obvykle bezi v tmuxu, aby byly pristupne i odjinud.
Jake IO dela ten proces? Neni tam nic se siti, ze ne?
Mit ho v extra VM je OK?
-
Zdravim,
existuje nejaka moznost, jak zmrazit a zakonzervovat nejaky bezici proces/skupinu procesu, a spustit jeho pokracovani pozdeji i treba po restartu systemu?
Background: v zasade jde o to, ze mam dualboot, pricemz v jednom systemu obcas bezi dlouhe vypocty (v radu dnu). Obcas je ale potreba se prepnout do druheho systemu. Hibernace je urcite reseni, ovsem ne vzdy se hibernace, resp. probuzeni z ni podari. To mi prijde jako problem systemu, nepodarilo se mi zjistit, co presne neprobuzeni zpusobuje. Vypocetni session obvykle bezi v tmuxu, aby byly pristupne i odjinud.
Doporucil bych pouziti virtualizace. At uz formou aby nebylo treba rebootovat do jineho systemu, nebo varianta kdy se virtual kde se provadi vypocet pozasatavi provede se restart a pak se virtual zase obnovi.
Jinak ano je mozne ulozit kompletni stav aplikace(pamet,zasobnik, registry) (za urcitych podminek), a ten pak obnovit. Ale pokud je to slozitejsi aplikace vice vlaken, komunikace se siti atd, tak to za to nestoji
-
IO jsou jen na disk, zadna prace se siti. Ale vice vlaken to pouziva.
Do "rozlozeni systemu" nechci hrabat, protoze je PC pouzivany a v zasade jediny k dispozici. Na hodne efektivni moznost virtualizace s moznosti PCI atd. jsem narazil (tusim, ze bylo vlakno tady), ale to az do noveho budouciho stroje (a to je fazi snu :-)).
Poradli byste nejake v hodne reseni virtualizace do stavajiciho systemu (Debian 8 ) ve smyslu (Daniel Kozak): ...nebo varianta kdy se virtual kde se provadi vypocet pozasatavi provede se restart a pak se virtual zase obnovi.
, pricemz aby vypocet mohl pouzivat vsechny systemove prostredky, kdyz jsou k dispozici. (Vypocet bezi, ale deti obcas chteji koukat na pohadky :-)) Chci tim rict, abych nemusel natvrdo virtualu dedikovat 6 vlaken a zbytek si nechat pro ostatni provoz, ale aby se zatez rozprostrela, jak to system dela normalne.
Jeste me napada, procesor je i7-4770K a narazil jsem na neco, ze cosi v souvislosti s virtualizaci (asi to bylo neco v souvislosti s mym 2. odstavcem) nepodporuje, narozdil od napr. non-K verze...
Diky
-
Tak pokud mas stroj na simulace, na kterem si deti pousteji pohadky, delas neco spatne ;)
-
Kdysi neco takoveho udelal Martin Mares. Dokazalo to "uspat" proces s bezicim emacs-em a po rebootu ho opet obnovit.
-
tve cpu podporuje VT-x (primy pristup k CPU), ale nepodporuje VT-d (primy pristup k graficke, zvukove, sitove karte), pro potreby vypoctu v terminalu je VT-x to hlavni co potrebujes, protoze te vstupne/vystupni HW nezajima (pokud bys naopak chtel provozovat ve virtualu Windows s vykonem gragicke karty jako nativne nastartovane WIndows, pak prave potrebujes VT-d)
reseni osobne doporucuju QEMU/KVM naklikavatelne pres Virt-Manager, rozepsal sem se nedavno o tom u konkurence:
http://www.abclinuxu.cz/poradna/linux/show/413225#10
nebo pokud ses hooodne linej a tim ze stejne nemas VT-d, muzes zkusi VirtualBox, ale osobne bych ti to neradil a zkusil to vyse...
-
Nestaci nastavit virtualboxu nizku prioritu?
-
Tak pokud mas stroj na simulace, na kterem si deti pousteji pohadky, delas neco spatne ;)
To je dlouha historie :-) Ja si svoje pocitam v praci, ale zena ma obcas pocit, ze se u deti nudi :-)
tve cpu podporuje VT-x (primy pristup k CPU), ale nepodporuje VT-d (primy pristup k graficke, zvukove, sitove karte), pro potreby vypoctu v terminalu je VT-x to hlavni co potrebujes, protoze te vstupne/vystupni HW nezajima (pokud bys naopak chtel provozovat ve virtualu Windows s vykonem gragicke karty jako nativne nastartovane WIndows, pak prave potrebujes VT-d)
Jo, to bude ono, prave vyuziti toho VT-d je faze snu na novy stroj. Ale to je daleko.
reseni osobne doporucuju QEMU/KVM naklikavatelne pres Virt-Manager, rozepsal sem se nedavno o tom u konkurence:
http://www.abclinuxu.cz/poradna/linux/show/413225#10
nebo pokud ses hooodne linej a tim ze stejne nemas VT-d, muzes zkusi VirtualBox, ale osobne bych ti to neradil a zkusil to vyse...
Supr, diky za tip, mrknu na to
Nestaci nastavit virtualboxu nizku prioritu?
Netusim, nemam s virtualizaci zadne zkusenosti, jen vzdalene z doslechu. Proto se ptam :-) Z toho doslechu jsem prave ziskal dojem, ze VirtualBoxu se musi prostredky pridelit natvrdo, a neumi s nimi dynamicky pracovat
-
VMWare ma take nastavenie https://www.vmware.com/support/ws5/doc/ws_learning_prefs_priority.html
To uz by sa muselo prakticky overit, ci to video netrha. Ale vzdy sa to da uplne pauznut.
-
Kdysi neco takoveho udelal Martin Mares. Dokazalo to "uspat" proces s bezicim emacs-em a po rebootu ho opet obnovit.
Nemáš odkaz?
-
Osobne pouzivam k podobnym ucelum Berkely Labs Checkpoint Restart (BLCR; http://crd.lbl.gov/departments/computer-science/CLaSS/research/BLCR/). Potrebujete jaderny modul, knihovny a par utilit. Vzhledem k tomu, ze to pouzivam k automaticke migraci procesu po vypocetnim klastru, mam za sebou radove desetitisice (mozna statisice) uspesnych checkpoint-restart operaci. Z urcitych duvodu se v nasem klastru omezujeme na jednovlaknove ulohy, ale BLCR podporuje checkpoint i vicevlaknovych procesu. Na Debianu jsem to naposledy kompiloval na Wheezym a tusim, ze problemy nebyly (ve velkem to beham na CentOSu, ale i tam jsem kompiloval uz pomerne davno a sklerozu mam velkou, takze si na komplikace nevzpominam).
-
Ta třeba Squeak/Smalltalk má hibernaci zabudovanou by default. Někdo to občas používal právě na dlouhotrvající výpočty. Ale pravděpodobně výpočet do smalltalku nebudete chtít přepisovat, když to máte implementované jinde a když asi závisíte na knihovnách pro výpočty. Pak bude virtualizace univerzální řešení bez práce.
Používám kvm a virt-manager a virtuál bez problému pozastavím a kdykoli rozběhnu, restart pc nevadí.
Virtuál využívá výkon počítače jen podle toho, co ve virtuálu běží. Pokud tam neběží nic, tak virtuál žere jen paměť, ale žádný procesorový čas.
-
Osobne pouzivam k podobnym ucelum Berkely Labs Checkpoint Restart (BLCR; http://crd.lbl.gov/departments/computer-science/CLaSS/research/BLCR/). Potrebujete jaderny modul, knihovny a par utilit.
A to opravdu funguje i na už hotové binárky? Jak si to poradí s otevřenými resources?
-
neskusal som, ale mozno toto: http://criu.org/Main_Page
-
Kdysi neco takoveho udelal Martin Mares. Dokazalo to "uspat" proces s bezicim emacs-em a po rebootu ho opet obnovit.
Nemáš odkaz?
Bohuzel. Je to vic nez 15 let. A tehdy jsem byl jeste noob.
-
Hotove binarky musi byt dynamicky slinkovane. Pak se pustenim procesu skrze utilitu cr_run dale dynamicky prilinkuje libcr.so, ktera zajistuje, ze proces ma schopnst byt uspan/restartovan (nejaka systemova volani, jejichz podporu na druhe strane pridava prislusny jaderny modul). Tehoz lze docilit nastavenim promene prostredi LD_PRELOAD. K jiz bezicimu procesu to neprilinkujete. Resources - sitova spojeni by urcite byla problemem; zato standardni filedeskriptory jsou ulozene, tj. po probuzeni proces pise do souboru a na mista, kde skoncil ve chvili checkpointu. Byl-li soubor mezitim zmenen, pak jej bud zkrati, nebo naopak doplni nulami. K tomu muze dojit napriklad tehdy, kdyz udelate zalozni checkpoint, ale proces nechate bezet, tj. on dale pripisuje do souboru. Pak dojde k padu (at uz systemu, nebo procesu) a po oziveni ze zalozniho checpointu se proces vrati na prislusne misto (zpravidla to tedy znamena, ze se soubor zkrati). Chci-li proces uspat a pak ozivit, checkpointuji ho se signalem 9 (aby na nej nemohl nijak reagovat a proste skoncil). Poslat signal po checkpoitu nabizi prislusna utilita cr_checkpoint. Jeste poznamenam, ze ne vzdy lze checkpoint pouzit po upgradu jadra - je nutne, aby jadro, na kterem probehl checkpoint, bylo dostatecne podobne tomu, na kterem se jej pokusite ozivit. Podstatne je, aby se nemenily jaderne datove struktury procesu. Na CentOSu to byl s distribucnim jadrem problem cas od casu. Ted je klastr cely 'schovany', takze na vypocetnich uzlech neupgraduji jadro a tento problem neresim. Netroufam si odhadnout pravdepodobnost problemu s Debianimi jadry.
-
Zdravim,
tak jsem nainstaloval QEMU/KVM s Virt-managerem. Nejak ale nejsem schopny ten virtualni stroj uspat tak, aby uspany prezil restart hosta. Ja ve Virt-manageru na to jeste nejake jine cudlitko, nez "Pause"? Pauznuty stroj restart hosta sestreli.
Diky za rady
-
Pause je opravdu jen pauznuti, na ulozeni stavu je pod 'power menu' (sipka napravo od tlacitka UkonceniI
(napravo od Pausa)) polozka Ulozit, pripadne v menu "Virtualni stroj/Shut Down/Ulozit"...
-
Aha, to jsem videl. Ale to odmitl s tim, ze:
Error saving domain: Requested operation is not valid: domain has CPU feature: invtsc
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/engine.py", line 980, in cb
vm.save(path, meter=asyncjob.get_meter())
File "/usr/share/virt-manager/virtManager/domain.py", line 1407, in save
self._backend.managedSave(0)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1309, in managedSave
if ret == -1: raise libvirtError ('virDomainManagedSave() failed', dom=self)
libvirtError: Requested operation is not valid: domain has CPU feature: invtsc
-
Hotove binarky musi byt dynamicky slinkovane. Pak se pustenim procesu skrze utilitu cr_run dale dynamicky prilinkuje libcr.so, ktera zajistuje, ze proces ma schopnst byt uspan/restartovan (nejaka systemova volani, jejichz podporu na druhe strane pridava prislusny jaderny modul). ...
Díky za popis, může se to někdy hodit.
-
Aha, to jsem videl. Ale to odmitl s tim, ze:
Error saving domain: Requested operation is not valid: domain has CPU feature: invtsc
Máte dost aktuální libvirt a qemu-kvm? Na jakém procesoru a na jakém jádru (distribuci)?
-
Debian 8, aktualni balicky, procesor i7-4770K
Zda se, ze dela problem ta feafure "invtsc". Kdyz jsem jako procesor model dal "kvm64¨ tak save funguje. Lze nejak tu feature zakazat?