70 odpovědí na toto téma

[Kreten8]

Jo a zkoušel jsem i povolit debug a žádý soubor debug.log se nevytvoří

[Kreten8]

Tak po třičtvrtě hodiny mírný posun, ukazuje 282 vyexportovaných keší

Přiložené miniatury

• 
• 
• 

[Kreten8]

a už se objevilo i něco v logu:

2024-10-25 11.30.48.577 WMClipboardUpdate
2024-10-25 11.30.48.585 Format=13
2024-10-25 11.30.48.585 Format=16
2024-10-25 11.30.48.593 Format=1
2024-10-25 11.30.48.593 Format=7
2024-10-25 11.30.48.609 cf_unicodetext found!
2024-10-25 11.30.48.619 content=debug.log
2024-10-25 11.42.20.345 WMClipboardUpdate
2024-10-25 11.42.20.361 Format=2
2024-10-25 11.42.20.364 Format=8
2024-10-25 11.42.20.372 Format=17
2024-10-25 11.42.20.377 content=
2024-10-25 11.44.48.122 WMClipboardUpdate
2024-10-25 11.44.48.123 Format=2
2024-10-25 11.44.48.131 Format=8
2024-10-25 11.44.48.136 Format=17
2024-10-25 11.44.48.152 content=
2024-10-25 11.44.48.152 WMClipboardUpdate
2024-10-25 11.44.48.152 Format=2
2024-10-25 11.44.48.152 Format=8
2024-10-25 11.44.48.168 Format=17
2024-10-25 11.44.48.184 content=

 

[Kreten8]

tak po hodině a půl jsem na stavu 452

Přiložené miniatury

• 

[Kreten8]

a proč jediný co se debuguje je akorát schránka a není tak žádný log o zpracovaných keších, aby se dalo zjistit proč to jde tak pomalu

[HaLuMa]

Protože debug log slouží pro moje debugování, nikoliv pro tvoje. Opravdu není možné logovat všechno.

Tady zjevně dochází k nějaké velké neefektivitě při exportu, patrně v souvislosti s tvojí databází, protože takovouhle pomalost jinde nepozoruji. Nemáš tam něčeho hoooodně moc, třeba logů u keší? Musí to být něco, co se volá mnohokrát pro každou keš. Pro jistotu, bavíme se určitě o originálním neupraveném exportovacím skriptu?

[vkvkvk]

tak po hodině a půl jsem na stavu 452

Zkusil bych se mrknout na Správce úloh (taskmgr). Jestli tam něco neutíká za roh (procesor, disk). Potom ještě do "Sledování prostředků " Disk, délka fronty. (Chtěl jsem přihodit obrázek, ale nemohu.) Ta pokud přeleze přes 1, tak disk nestíhá a systém skoro vytuhne. Jinak vše funguje bez problémů?

[Kreten8]

Export byl hotov ve 13:52, podle času toho gpx souboru a má 2.2 GB, je to originál skript bez jakýchkoliv úprav a doteď to fungovalo normálně, dělám to skoro každý týden, abych si do mobilu nahrál aktuální kešky a určitě minulý týden jsem s tím žádný problém neměl a nechce se mi veřit, že by za týden se tam něco výrazně změnilo (logů u kešek tak bude hodně). To co píše vkvkvkv tak jsem postnul k předchozímu postu a není tam vidět že by něco bylo nějak přetížené. A paralelně s tím mi běžel jiný GeoGet, ve kterém mám ještě větší databázi co se týče počtu kešek, jen logů je tam méně a tam pracoval bez problémů a já na tom PC taky pracoval bez problémů v jiných aplikacích a žádné zpomalení jsem nepozoroval..

Tento příspěvek byl upraven od Kreten8: 25 říjen 2024 - 16:08

[Arne1]

Podle mne jediná možnost -  postupným výběrem za použití metody půlení intervalu najít keš která btbne. Mně se jednou do dvou keší nevím jak dostal jakýsi veliký binární nesmysl, všechno zdánlivě chodilo, jen zhavaroval opravný skript Obnovení pomocných informací.

MOžná bych ještě zkusil nějaké jednodušší exporty,  protože GPX v2 o keši exportuje úplně všechny informace.

Tento příspěvek byl upraven od Arne1: 25 říjen 2024 - 17:58

[Kreten8]

Tak jsem zjistil, že hned první keš trvá jeden a půl minuty, než se vyexportuje, takže pokud mám v db víc podobných keší, tak pak se to asi nasčítá a celý ten export pak trvá těch několik hodin. Zkusil jsem si vytvořit prázdnou db, do které jsem tuto keš naimportoval (čož trvalo nějaký zlomek sekundy) a pak následně vyexportovat, tak i z té "prázdné" db ten export trval stejně dlouho. Takže na http://geoget.kreteni.eu/a.gpx je ke stažení a Halumo můžeš se podívat, proč to trvá tak dlouho a jestli by tam nešlo něco zoptimalizovat, aby se to nexportovalo tak dlouho.

[gord]

Logy od roku 2002 ... to neni malo a to bude urcite ten duvod.

Tento příspěvek byl upraven od gord: 26 říjen 2024 - 14:56