184 odpovědí na toto téma

[dr.vota]

Tak se taky přidám.

Bylo by asi dobře, kdyby se nespouštělo provedení zálohy databáze, pokud není na to na disku dost místa.

Přišel jsem na to spíš náhodou, jak se systém šíleně zpomaloval, zachránil jsem to na poslední chvíli...

Každopádně v okamžiku zálohování je na disku

1) celá aktivní databáze db3

2) stará záloha

3) nový BAK databáze

4) ale taky BAK-journal, narůstající až stejně velký jako ty ostatní 3 databáze

 

takže celkem=databáze x 4

[HaLuMa]

Po přenesení GeoGetu a jeho databází zbylo cca 3.6G volna. V této situaci jsem mu tam chtěl nahrát větší aktualizaci (cca 25000 keší, 450MB). A chyba je opět zde. Někde při importu mezi 16000-17000. Zkusil jsem ten GPX soubor zpět na svém počítači - samozřejmě bez problémů. Zkusil jsem odmazat jednu archivní databázi, takže přibylo cca 3/4 Giga - a hle, výskyt chyby se posunul na cca 22000. Takže podle mne chyba závisí na velikosti volného prostoru na systémovém disku.

 

No, neni asi zadne prekvapeni, ze transakcni prace s velkou databazi vyzaduje nejaky ten diskovy prostor navic. To proto, aby se v pripade nejakeho selhani mohla databaze zrekonstruovat do puvodniho stavu. Zkratka, misto na disku je take potreba. Tim se to zahadne padani dobre vysvetlilo. :-) Dik za info.

[Kreten8]

Jo a ještě mám jeden problém - jak výše píšu SQL dotazem v Combine si vybírám nejstarší kešky a tento dotaz trvá hodně dlouho a no když si mezitím chci spustit druhý GG s jiným datadirem, tak je stejně "vytuhlý" jako ten první, dokud ten první nezpracuje ten dotaz - proč se takto navzájem ovlivňují?

[HaLuMa]

Tak se taky přidám.

Bylo by asi dobře, kdyby se nespouštělo provedení zálohy databáze, pokud není na to na disku dost místa.

 

Dobra pripominka, ani jsem to neokecaval, a rovnou jsem to tam naprogramoval. 

[HaLuMa]

Jo a ještě mám jeden problém - jak výše píšu SQL dotazem v Combine si vybírám nejstarší kešky a tento dotaz trvá hodně dlouho a no když si mezitím chci spustit druhý GG s jiným datadirem, tak je stejně "vytuhlý" jako ten první, dokud ten první nezpracuje ten dotaz - proč se takto navzájem ovlivňují?

 

Pokud dotaz trva dlouho, je to nejpravdepodobneji tim, ze se ceka na disk. Spusteni GG je take spousta pozadavku na disk... na ktery se ceka, nebot je vytizeny jinou praci.

[Arne1]

No, neni asi zadne prekvapeni, ze transakcni prace s velkou databazi vyzaduje nejaky ten diskovy prostor navic. To proto, aby se v pripade nejakeho selhani mohla databaze zrekonstruovat do puvodniho stavu. Zkratka, misto na disku je take potreba. Tim se to zahadne padani dobre vysvetlilo. :-) Dik za info.

To beru. Ale připadá mi neadekvátní velikost databáze a ten volný prostor - nemluvě o tom, že ta chyba není rozumně ošetřená a není možno ji nějak eliminovat (nějaké nastavení dočasného pracovního prostoru jinam). Ty doby kdy jsme měli systémové disky s velkou kapacitou jsou na nějakou dobu pryč, teď je podstatné aby to bylo rychlé a kapacita se řeší jako druhotná záležitost). V daném případě po aktualizacích má databáze 1.2 G, takže bych čekal že přes 3GB volna stačí. No - nestačí.

[dr.vota]

Dobra pripominka, ani jsem to neokecaval, a rovnou jsem to tam naprogramoval. 

Díky. Doufám, žes přidal i nějakou slušnou rezervu.

A když už je ta verze rozdělaná, co opravit ten pokažený teploměr při aktualizaci >50 keší přes LIVE, aby to nepřelézalo 100 %? 

[Kreten8]

Pokud dotaz trva dlouho, je to nejpravdepodobneji tim, ze se ceka na disk. Spusteni GG je take spousta pozadavku na disk... na ktery se ceka, nebot je vytizeny jinou praci.

No ale jiné aplikace bez problémů fungují a neblokují se.

[tarmara]

A když už je ta verze rozdělaná, co opravit ten pokažený teploměr při aktualizaci >50 keší přes LIVE, aby to nepřelézalo 100 %? 

Přidávám se ke kolegovi....i když už jsem si zvykl na to, že aktualizace 5900 keší končí něco málo nad 11000%

[mpik]

Ještě by možná stálo za úvahu nějak ukázat, že kvůli malému prostoru se záloha neprovedla, třeba přeškrtnutou ikonou, nebo podobně. Už delší dobu mám na disku jen kolem 20 GB volna a dočasně může být i méně. Může se pak stát, že se zálohy databáze nebudou dělat a já to nebudu vědět. Ovšem jak disk nafouknout, nevím. Koupit větší, i s novým strojem, na to se už nějaký čas chystám.

Ještě doplním - možná už tam něco takového je a jen o tom nevím. Prozatím se mi zálohy dělají.

Tento příspěvek byl upraven od mpik: 17 leden 2017 - 22:30

[HaLuMa]

Ikonka na nepovedenou zalohu tam preci je. Neboj se, ze jsem ji nepouzil, za co mne mas?

[dejwy]

Přidávám se k prosbě kolegy Kreten8:

 

1/ Vymazání sořadnic FinalWP (tlačítko o něcoo výše vedle Prefixu)

2/ Souhlas, proč nefunguje CTRL-A netuším , asi jiný ovl. prvek

3/ Vypešení počítání "pracuji na X z Y" či ona zmiňovaná nesmyslná procenta. Pokud není znám předem celkový počet, aby mohly být zobrazeny % tak je raději nezobrazovat.

Tento příspěvek byl upraven od dejwy: 17 leden 2017 - 22:42

[HaLuMa]

No ale jiné aplikace bez problémů fungují a neblokují se.

 

A ty jine apliakce potrebuji take tak intenzivne pouzit stejny disk? Dost pochybuji...

Opravdu tam zadne naschvalove blokovatko nemam.

[HaLuMa]

To beru. Ale připadá mi neadekvátní velikost databáze a ten volný prostor - nemluvě o tom, že ta chyba není rozumně ošetřená a není možno ji nějak eliminovat (nějaké nastavení dočasného pracovního prostoru jinam). Ty doby kdy jsme měli systémové disky s velkou kapacitou jsou na nějakou dobu pryč, teď je podstatné aby to bylo rychlé a kapacita se řeší jako druhotná záležitost). V daném případě po aktualizacích má databáze 1.2 G, takže bych čekal že přes 3GB volna stačí. No - nestačí.

 

Jakeho docasneho prostoru? mel by vznikat jen ten rollbackovy journal, ktery z principu potrebuje byt u databaze. A jeho velikost je zavisla na velikosti menenych dat v transakci - tedy v jednom importu. No jo, import. Kdyz importujes treba nejake obludne velke PQ (ano, technicky lze mit PQ treba pul giga...), tak nezapomen, ze i to zabira misto. A potrebujes dalsi misto, kam se to PQ vybali ze ZIPu, atd.

 

Malo mista na systemovem disku je uplne obecny problem, Geoget neni zdaleka sam, kdo potrebuje nejake pracovni misto. Co treba samotny operacni system a vsechny jeho soucasti? Co jine apliakce? Co strankovani pameti? To vsechno potrebuje nejake volne misto na disku.

 

Ostatne, kdyz tahle zapolis s mistem, proc mas vubec datovy adresar na systemovem disku?

[HaLuMa]

A když už je ta verze rozdělaná, co opravit ten pokažený teploměr při aktualizaci >50 keší přes LIVE, aby to nepřelézalo 100 %? 

 

Pripada ti, ze jinak na GG vubec nic nedelam?

Hele, radeji mi rekni, jakou aktualizaci pres Live myslis? A s jakymi parametry? Full, lite, summary... ci jen stav?

[Arne1]

Ostatne, kdyz tahle zapolis s mistem, proc mas vubec datovy adresar na systemovem disku?

Systémový je SSD, takže rychlý. Na druhej stěhuju co není nutné. Ono zase dělat systém na HDD a SSD použít jako druhej by nebylo asi to pravé.

Ale teď mi došlo, že jsem použil přesnou formulaci (závisí to na prostoru na systémovém disku) ale už jsem to zapomněl okecat, že je tím myšlen opravdu systémový disk, tj C: a nikoliv disk kde je datadir. Protože jsem samozřejmě udělal i to, že jsem to ze systémového zkopíroval na druhej disk (SD kartu). A protože by se určitě nějaký rejpal ozval, že datadir je přece zahrabaný kdesi v útrobách profilu - tak opravdu není, je tam kde ho dám já !

Tento příspěvek byl upraven od Arne1: 18 leden 2017 - 0:14

[HaLuMa]

Arne, ted jsem se v tom ztratil. Jak to teda je? Datovy adresar se samotnou databazi mas na jinem disku, ale na systemovem disku musi i tak byt dostatek mista?

[HaLuMa]

Přidávám se k prosbě kolegy Kreten8:

 

2/ Souhlas, proč nefunguje CTRL-A netuším , asi jiný ovl. prvek

 

To proto, ze CTRL+A ve standardni obsluze klavesovych zkratek nejak vsude chybi. Musi se to vsude rucne dodelavat.

 

A protoze CTRL+A ne vzdy vsude funguje (I mimo Geoget!), tak nejak automaticky zkousim hmaty jako CTRL+HOME a pak CTRL+SHIFT+End... to mi funguje i tady.

 

Nicmene do tohoto okna jsem tedy CTRL+A dodelal.

[vkvkvk]

K záloze DB: Asi by stálo za úvahu umožnit výběr adresáře, kam se má DB zálohovat. Byly by to 2 mouchy jednou ranou:

- Zvýšení bezpečnosti. Kopie by mohly být na jiném fyzickém disku. (Kdy jste si naposled DB někam překopírovali? Já asi před rokem:(. )

- Úspora místa na rychlém disku

 

Nahrávání velkých GPX: Odhaduji, že celý import běží v jedné transakci. Je to nejrychlejší a buď se nahraje vše nebo nic. Kvůli velikosti žurnálu by možná pomohlo uzavírat transakce po menším počtu kešek. Ale stojí to za přidanou složitost programu?

[dr.vota]

Pripada ti, ze jinak na GG vubec nic nedelam?

Hele, radeji mi rekni, jakou aktualizaci pres Live myslis? A s jakymi parametry? Full, lite, summary... ci jen stav?

Nepřipadá.

Ale je to věc, která už je tam rozbitá hodně verzí zpátky, reklamoval jsem to už kdysi i tady a nechci to připomínat při každé další verzi znovu... je blbé, když v ikoně na liště skočí proužek hned na konec a pak tam je pořád a pořád dlouho stejně beze změny až do konce, takže nevidím žádný pokrok a jak dlouho se má čekat. 

 

Já to vidím pokaždé při full, ostatní moc nepoužívám, tak nevím.

 

Hledal jsem ten svůj první report, ale našel jsem pozdější, kde je to připomínáno v roce 2015:

http://www.geocachin...inový/?p=506610