Meine bash scripting Fähigkeiten sind leider noch ausbaubar, daher habe ich das noch nicht so hinbekommen wie ich gerne möchte.
Ich habe bisher meine OSM Daten je nach Bedarf mit den täglichen Updates oder mit den hourly Updates aktualisiert. Da ich zum mergen mittlerweile auf osmconvert umgestiegen bin von osmosis und dadurch eine enorme Zeitersparnis habe, bin ich mal testweise auf minutly Updates umgestiegen. Macht man das regelmässig per Cronjob ist das auch angenehm schnell.
Ich hätte das ganze aber gerne noch etwas flexibler. Wenn man den Rechner nicht 24/7 an hat und dann mal 12 Stunden oder nach dem Urlaub gleich Tage oder Wochen nachholen muss, dauert das mit den minutly Updates zu lange weil viel zu viele kleine Dateien erst mal übertragen werden müssen.
Daher meine Frage: Hat da mal schon jemand an einem automatisierten flexiblen Update Script gearbeitet, das je nach dem Zeitpunkt des letzten Updates erst die Daily diffs, danach die Hourly diffs und schließlich für den Rest die minutly diffs runterlädt und man evt sogar noch eine Option haben könnte nach mehr als X Wochen gar keine Updates sondern gleich eine komplette europe.osm oder ein planet.osm runterzuladen ?
Ja das ist ja klar, damit wird das ja auch gemacht …
Nur man muss eben einstellen ob man minutly oder hourly diffs möchte.
Ich möchte ja ein flexibles Script. Also z.B mein letztes Update war vor 8 Tagen. Also sollte das Script erst mal die letzten Daily Diffs runterladen, dann für den Rest erst mal die Hourly Diffs und zum Schluss die Minutly Diffs für die letzte Stunde.
resultat: cron startet den Job alle 2 Minuten. Dieser besorgt sich maximal die Daten einer Stunde/3600 Sekunden (der ältesten, die ihm gerade fehlt) und arbeitet diese in ca 20 Minuten ab.
Nach durchschnittlich 1 Minute macht der nächste Job weiter. Somit kommt man im Laufe der Zeit immer mehr an die aktuelle Zeit ran. Sind nicht genug Daten da, weil man schon fast Realtime ist, bekommt er halt das, was gerade da ist. Im Extremfall die Daten der letzten 1-2 Minuten. Dann ist man quasi Realtime dran. Was will man mehr.
Ist der alte Job noch aktiv, “merkt” das der neue Job und verabschiedet sich einfach mit “still running”.
Das sieht in meinem Log dann so aus:
[2011-07-02 06:35:22] 10730 osmosis done RC=0
[2011-07-02 06:35:50] 10730 lag is 2 hour(s) and 8 minute(s)
[2011-07-02 06:36:01] 11855 starting osmosis
[2011-07-02 06:38:04] 11954 pid 11855 still running
[2011-07-02 06:40:03] 12012 pid 11855 still running
[2011-07-02 06:42:03] 12836 pid 11855 still running
[2011-07-02 06:44:04] 12887 pid 11855 still running
[2011-07-02 06:45:39] 11855 osmosis done RC=0
[2011-07-02 06:45:45] 11855 lag is 1 hour(s) and 19 minute(s)
[2011-07-02 06:46:01] 13738 starting osmosis
[2011-07-02 06:48:02] 13797 pid 13738 still running
[2011-07-02 06:50:03] 13842 pid 13738 still running
[2011-07-02 06:52:03] 14726 pid 13738 still running
[2011-07-02 06:54:04] 14769 pid 13738 still running
[2011-07-02 06:56:03] 15300 pid 13738 still running
[2011-07-02 06:58:03] 15642 pid 13738 still running
[2011-07-02 07:00:04] 15688 pid 13738 still running
[2011-07-02 07:02:04] 15918 pid 13738 still running
[2011-07-02 07:03:42] 13738 osmosis done RC=0
[2011-07-02 07:04:03] 15982 pid 13738 still running
[2011-07-02 07:04:10] 13738 lag is 36 minute(s) and 59 second(s)
[2011-07-02 07:06:03] 16779 starting osmosis
[2011-07-02 07:08:04] 16892 pid 16779 still running
[2011-07-02 07:10:02] 16947 pid 16779 still running
[2011-07-02 07:12:03] 17775 pid 16779 still running
[2011-07-02 07:14:03] 17830 pid 16779 still running
[2011-07-02 07:16:02] 18570 pid 16779 still running
[2011-07-02 07:18:04] 18710 pid 16779 still running
[2011-07-02 07:18:56] 16779 osmosis done RC=0
[2011-07-02 07:19:11] 16779 lag is 13 minute(s) and 0 second(s)
[2011-07-02 07:20:01] 18784 starting osmosis
[2011-07-02 07:22:02] 19621 pid 18784 still running
[2011-07-02 07:23:22] 18784 osmosis done RC=0
[2011-07-02 07:23:27] 18784 lag is 3 minute(s) and 0 second(s)
[2011-07-02 07:24:02] 19696 starting osmosis
[2011-07-02 07:24:53] 19696 osmosis done RC=0
da kann man schön sehen, wie er sich langsam vorarbeitet.
Gruss
Walter
p.s. der script:
cd /home/walter/OSM/projekte/db/hstore/diffs
date
PIDFILE=`basename $0`.pid
RUNLOG=`basename $0`.log
OSMOSIS=osmosis
m_info()
{
echo "[`date +"%Y-%m-%d %H:%M:%S"`] $$ $1"
echo "[`date +"%Y-%m-%d %H:%M:%S"`] $$ $1" >> "$RUNLOG"
}
getlock()
{
if [ -s $PIDFILE ]; then
if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; then
return 1 #false
fi
fi
echo $$ >"$PIDFILE"
return 0 #true
}
freelock()
{
rm "$PIDFILE"
}
if ! getlock; then
m_info "pid `cat $PIDFILE` still running"
exit 3
fi
m_info "starting osmosis"
$OSMOSIS $1 $2 $3 $4 \
--read-replication-interval \
--simc \
--lpc interval=60 \
--write-pgsql-change host="wno-server" database="osm" user="xxxx"
RC=$?
m_info "osmosis done RC=$RC"
m_info "lag is `osmosis --read-replication-lag humanReadable=yes workingDirectory=.`"
freelock
Hmm hörst sich interessant an, also dann werden da also mehrere Tasks parallel gestartet ?
Nehmen wir an mein Rechner war 5 Tage aus und ich schalte ihn wieder an:
Dann starten eine Menge osmosis tasks die alle kleine minutly diffs runterladen und die parallel verarbeiten.
Wie lange dürfte das dann etwa dauern wenn man 20 Minuten für eine Stunde rechnet und noch einberechnet dass da auch noch viele Tasks parallel ablaufen ?
alleine für 1 Tag (24) Stunden wäre das ne Menge an Rechenzeit …
Wäre doch einfacher und ökonomischer wenn man für 1 Tag ein einziges Diff runterladen müsste.
Für die letzten 5 Tage dann also 4 komplette daily diffs, ein paar hourly diffs für den aktuellen Tag und nur für die die letzte Stunde die minutly diffs
das wären dann im Maximalfall 4 x daily + 23 x hourly + 59x minutly = 86 Dateien
nur mit minutly diffs wären das 4 x 24 x 60 + 23 x 60 + 59 = 7199 Dateien die verarbeitet werden müssen
Ich denke sowohl für den OSM Server als auch für meinen Rechner wären 86 Dateien ökonomischer zu verarbeiten.
Aaaber: Wenn man den Rechner nun länger nicht angeschaltet hat, dann dauert es wohl sehr lange (bei dir 8 Stunden) bis die Diffs eines einzigen Tages eingespielt sind. Mit daily-Diffs und hourly-Diffs geht das aber sehr viel schneller. Nur muß man nachher, wenn man relativ aktuell ist manuell auf minutly-Diffs umstellen. Und genau das ist misterboos Problem.
Eine Task macht den Job (die Daten der ältesten Stunde importieren) und die anderen loggen sich sofort wieder aus.
Osmosis lädt die ca 20 Diff-Files einer Stunde, macht da ein Summen-Diff raus und verarbeitet dieses Datenpaket in einem Rutsch. Das macht ca 24 Vorgänge pro Tag, solange ganze Stunden nachgearbeitet werden. Ein Daily Diff ist natürlich kleiner als die Summe von 24 * 1H Diffs aber dafür absolut wartungsfrei.
Rechner anschalten und die Daten kommen.
In so einem Extremfall (Lag von mehreren Tagen) tut das schon weh. Schreib am besten den Script um und alle sind happy - ich wäre es auch.
Meine Methode hat sich über ein Jahr bewährt, da ich in der Regel nur nachts den Rechner aus habe. Nachts werden weniger Mods gemacht und da braucht eine Datenstunde schon mal 5 Minuten Verarbeitungszeit am nächsten Tag.
Gruss
Walter
p.s. Ich mache übrigens keine Hacks oder Tricks mit osmosis; ich benutze nur Funktionen, die der Autor genau dafür vorgesehen hat.
Man muss das halt nur mal “gefressen” haben. Leider ist die Beschreibung von configuration.txt etwas schwach.
osmosis lädt alle fehlenden Daten runter, packt die in ein lokales Diff-File und verarbeitet das dann.
Wenn er damit fertig ist, nochmal starten (cron!) und er holt sich die Daten, die während der Verarbeitung des ersten Schwungs hochgeladen wurden. u.s.w.
ist das gleiche wie mein Verfahren, nur mit grösseren Zeitfenstern und grösseren Datenmengen - das selbe in grün. Ein Script für alles - Wochen bis Minuten.
Klar geht dein Verfahren, so mache ich das ja auch im Moment. Nur ich hatte ja erklärt, dass man damit dann für 5 Tage gut über 7000 kleine minutly Dateien runterladen muss und diese ja auch verarbeitet werden müssen.
Das sind 7000 Abfragen an den OSM Server und 7000 Dateien die osmosis mergen und verarbeiten muss.
Mit meiner Überlegung wären es max knapp 80 Dateien, was wohl deutlich schneller verarbeitet wäre.
dann mach mal aus dem “wäre” ein “sind” indem du es ausprobierst.
1 Tag als daily und als viele minutely. Natürlich mit dem gleichen Zeitfenster indem du in state.txt die Startzeit zurückdrehst. (auch vor der ersten Messung!)
Anschliessend kannst du die Ergebniss posten und dir überlegen, ob das den Aufwand wert war.
Es wird wohl etwas schneller sein aber mir geht das schon so schnell genug
Gute Idee Also nehme ich mal zum Testen 3 Tage. 3 daily diffs runterladen + mergen mit osmconvert geht ja schnell … hat etwa 5 Minuten gedauert.
Jetzt mal sehen wie lange das mit osmosis und ca 4300 minutly diffs für den Zeitraum von 3 Tagen dauert. Ich melde mich wenn es fertig ist. Mann muss aber kein Hellseher sein, dass das downloaden von 4300 kleinen Dateien Dateien und das mergen dieser vielen Dateien wohl ein vielfaches länger dauern wird.
Update: Osmosis hat 45Minuten gebraucht. 5 statt 45 Minuten ist für mich schon ein deutlicher Unterschied.
Einen Ansatz wie man das ganze ökonomischer machen könnte, habe ich in der Mailingliste von 2008 gefunden:
Das ganze müsste man noch anpassen da das Format der diffs damals wohl noch anders war. Zusammen mit osmconvert, das sowieso wesentlich schneller arbeitet als osmosis sollte man so schnell und effektiv die changefiles auch von mehreren Tagen bekommen können ohne auf die aktuellsten Updates per minutly diffs verzichten zu müssen.
