irgendwie komme ich mir langsam schon ein wenig doof vor.(ja ist etwas provokativ geschrieben).
Vielleicht sehe ich echt den Wald vor lauter Bäumen nicht.
Ich versuche folgendes einzutragen:
Nach den Beschreibungen die ich gefunden habe, musste es aber so weit richtig sein.
Die einzige Möglichkeit die ich gefunden habe ist die Daten manuell in die cron.job Tabelle einzutragen. Das ist mir aber zu umständlich und dann bleibe ich lieber bei dem Linux cron.
Wo liegt mein Fehler?
Das ist jetzt keine Antwort auf das Problem mit pg_cron.
Aber diese und Deine andere Frage lassen vermuten, dass Du ein Problem mit autovacuum hast.
Der übliche Weg, Probleme mit autovacuum zu lösen ist, dieses aggressiver zu konfigurieren. Also so, dass es früher ausgelöst wird und dann auch mehr Arbeit verrichten darf. Regelmässig ein VACUUM manuell auszuführen ist eher eine Krücke als eine vernünftige Lösung.
Das erreicht man hauptsächlich dadurch, dass autovacuum_vacuum_threshold und autovacuum_vacuum_scale_factor verkleinert werden, so dass Autovacuum früher anspringt. Dazu sollte man autovacuum_vacuum_cost_limit erhöhen, damit bei jedem Lauf mehr Arbeit verrichtet werden kann. Wenn Dein Server viele CPUs hat, kannst Du auch noch autovacuum_max_workers erhöhen (dann muss aber cost_limit noch stärker erhöht werden).
Hmm das weiß ich nicht. Bin mir dessen nicht wirklich bewusst.
Ich hatte ein Problem mit meiner Anwendung für die Verwaltung meiner Bilder. Damit Tagsüber mir autovacuum mir die Performance nicht runterzieht, habe ich es explizit deaktiviert.
So wollte ich die vacuum komplett auslagern, in Zeiten wo sonst nichts gemacht wird. Dazu habe ich mir normale Linux cron Jobs eingerichtet. Dabei habe ich mich gewundert, dass Statistiken nicht aktualisiert werden (habe dabei leider nur auf vacuum geschaut und wenn ich vacuum full laufen lasse, werden eben diese Statistiken nicht aktualisiert)
Dann bin ich beim Suchen auf pg_cron gestoßen und dachte mir - vielleicht wird damit “schöner/ besser/ bunter”. Sieht nicht so aus, Wenn ich nichts übersehen habe, sind es mir zu viele Stellen wo das nicht das machen kann was ich brauche oder wie ich es mir vorstelle.
Es mag aber an dem von mir eingesetzten Debian und PG14 liegen.
Es ist nicht möglich mit select cron.schedule… Datenbank für die etwas passieren soll einzutragen. Vielleicht geht das erst mit PG15 und pg_cron15
Man muss also die Sachen in die Tabelle cron.job eintragen. Das Problem hier - Die Sachen arbeiten mit UTZ und nicht mit localtime. So lange wir hier “hin und her” springen mit der Zeit, musste ich auch die Jobs selbst korrigieren damit es mit anderen Sachen nicht kollidieren.
Zumindest so lange ich keine Lösung finde wie ich in der cron.job Tabelle so etwas wie ‘15 1 3 * *’ at localtime eintragen kann, werde ich bei Linux cron bleiben.
Wie gesagt: die bessere Option ist, autovacuum so zu konfigurieren, dass es viel “früher” und öfter zum Zuge kommt und damit letztendlich weniger zu tun hat. Die Angst das autovacuum die Datenbank “runterzieht” ist unbegründet.
In den meisten Fällen ist das aber sowieso nur notwendig wenn man eine Anwendung hat, die ohne Pause tausende von Transaktionen in der Minute durchführt.
Hast Du denn wirklich ein Problem mit dem autovacuum Daemon? Wenn ja, was genau war/ist das Problem?
Vielleicht war es gestern doch zu spät: Aus dem GitHub:
[tippe oder füge den Code hier ein](https://github.com/citusdata/pg_cron)
SELECT cron.schedule_in_database('weekly-vacuum', '0 4 * * 0', 'VACUUM', 'some_other_database');
Gestern ging das nicht. Vermutlich habe ich mich vertippt oder in anderer DB es versucht oder…
Es bleibt das Problem mit der Timezone
Nein, ich habe es deaktiviert auf Empfehlung des Entwicklers der Anwendung deaktiviert.
Ich denke und schaue mir Dein Vorschlag auf jedem Fall an und werde probieren ob es in der Tat irgendwelche Nachteile für mich bringt.
Ein Szenario wo es sicherlich ungünstig wäre habe ich schon aus meinem allerersten Post hier im Forum… Die Anwendung hat zumindest im Moment noch ein BUG und zwar selten aber es kommt X mal im Jahr vor, dass sie der Meinung ist - alle Daten von der Platte neu einlesen zu müssen. Und das wären nicht nur Tausende sondern Millionen von Transaktionen die eben ohne Pause laufen.
(Hier wäre die Frage - kann man ggf. autovacuum deaktivieren ohne den Server Stoppen/ Starten zu müssen? Also für den Fall, dass so eine Situation kommt, dass ich eben autovacuum daemon deaktivieren kann und später wieder aktivieren)
Das halte ich für eine sehr zweifelhafte Empfehlung. Das war vielleicht vor 20 Jahren mit Postgres notwendig, aber heute sicherlich nicht mehr.
Nach einem Bulk-Load großer Datenmengen macht es durchaus Sinn ein vacuum analyze laufen zu lassen (wenn sehr viel via DELETE gelöscht wurde, dann vielleicht, möglicherweise, unter Umständen sogar vacuumn full analyze)
Der Scale Factor ist zu hoch für meinen Geschmack. Das bedeutet, dass autovacuum erst einsetzt wenn 40% der Datensätze geändert wurden. 0.1 oder 0.05 ist meiner Meinung nach ein besserer Wert.
Ja vielleicht/ vermutlich hast Du recht. Ich habe den Wert erst mal auf Standard also 0.2 verändert.
Warum ich nicht sofort auf 0.1 oder 0.05 gegangen bin? - Unsicherheit was das ganze mir auf Dauer ausrichtet. Nach dem ich autovacuum wieder aktiviert habe, hat es sofort losgelegt und bei den 2 großen Datenbanken etwas über 80GB ist es eben noch am machen. Warum ist mir nicht so ganz klar. (habe vermutlich falsche Vorstellung von dem wie es funktioniert. Bin nun mal kein DBA Profi)
Das habe ich mir auch gedacht und auf 2GB gesetzt.
(Auch wenn ich doch bei Linux PG vermutlich bleiben werde, habe ich PG14 auf gleich ausgetasteter Windows 2019 VM am laufen. Hier verweigerte PG die Änderung mit der Meldung - ist ein Fehler in der Konfig. Also maintaince_work_mem mit 1GB geht mit 2GB will er nicht akzeptieren)
Das ist schon klar. Deswegen bin ich Euch sehr Dankbar für die viele Vorschläge und Rückmeldungen.
Ich habe gestern so ein BLOG Eintrag gelesen Ajay’s PostgreSQL Blog
Und hier irritiert mich ein wenig diese Passage
The choice between autovacuum and manual vacuum depends on the specific requirements of the database and the resources available. Autovacuum is generally considered to be the best option for most scenarios, as it can be configured to run at times when the load on the database is low, and it can be fine-tuned to minimize the impact on performance. However, manual vacuum can be useful for specific scenarios, such as reclaiming space from large tables or for debugging and troubleshooting purposes.
Was mich irritiert - wie stellt man ggf. ein, dass autovacuum dann anspringt wenn gerade wenig/ nichts zu tun ist?
Die Verwendung von FULL im VACUUM ist auch grenzwertig. VACUUM FULL kopiert die komplette Tabelle, leert gerade mal die “toten” Elemente und blockiert während der Zeit die ganze Tabelle.
An sich hätte es mich nicht weiter gestört, weil ich es immer für die Zeiten eingestellt hätte, wo ich eh nichts mehr mache.
Für den Moment bin ich aber auf den Vorschlag eingegangen und schaue wie gut/ schlecht es mit dem autovacuum funktionieren wird.