Lange Wartezeit beim hinzufügen und entfernen von Adblock Listen

Christian_Sch · December 3, 2023, 3:47pm

Ich betreibe aktuell einen Raspberry Pi 3+ mit Pihole 6 Beta.

Soweit so gut.

Mir ist nur aufgefallen das es ewig dauert 60 Minuten und mehr wenn ich viele Listen hinzufüge oder entferne.

Aktuell entferne ich 38 Listen ja es sind wirklich 38 Stück und der Pi ist in der Zeit nicht erreichbar oder Pihole reagiert auf irgendeine Eingabe.

Hier ein Screenshot von TOP.

So extrem war dieses Verhalten auf dem Pihole 5 nicht auch wenn ich dort lange warten musste aber mit Version 6 ist es noch länger geworden. Kann man das Beschleunigen oder wurde etwas geändert in Version 6?

yubiuser · December 3, 2023, 3:52pm

Das sollte so nicht sein.

Bitte generieren ein Debug log und poste das Token hier.

Christian_Sch · December 3, 2023, 3:55pm

Wie soll ich ein Debug Log erstellen wenn der Pi kaum reagiert?

Kann ich das auch im ssh erstellen? Dann geht es noch irgendwie

Danke schonmal

FAQ // Google hilft
pihole -d

Christian_Sch · December 3, 2023, 4:09pm

PiHole Debug.txt (74.5 KB)

Hoffe das hilft.

Bitte ignorieren das der Pihole das Internet nicht erreicht wie gesagt solange er die Files/Listen löscht kommt er kaum raus.

yubiuser · December 3, 2023, 9:36pm

Ich kann erstmal im Log nichts finden, dass auf einen wirklichen "Fehler" hindeutet. Allerdings hast du eine Menge Listen, die insg. >35 Millionen (!) Domains enthalten. Das zu verarbeiten dauert einfach recht lange.

An welcher Stelle hängt es denn genau? Ist es das reine hinzufgen/entfernen der Adlisten (via Web interface) oder anschließend der gravity lauf? Wenn letzteres, schau dir mal an, welcher Teil von pihole -g so lange braucht: das herunterladen und prozessieren jeder einzelnen Liste? Oder am Ende der Teil mit "Building Tree"?

Christian_Sch · December 4, 2023, 9:22am

Das er lange für die Verarbeitung braucht ist ja noch ok bei einem Update.

Hier geht es aber wirklich um das Entfernen der Listen.

Habe wie gesagt viele Listen entfernt und er hat jede einzelne Liste scheinbar einzeln vererbeitet statt sie alle gleichzeitig aus der Gesamtliste zu streichen. Sprich ich habe hin und wieder in der GUI gesehen das er Liste xy entfernt hat. Aber im Hintergrund die nächste gemacht hat. Wäre es hier nicht besser alle Listen gleichzeitig aus der Hauptliste zu entfernen? (Schneller).

Also dieser Punkt ist das Problem: "Ist es das reine hinzufgen/entfernen der Adlisten (via Web interface)"

milo · December 4, 2023, 11:38am

Hallo schliesse mich hier mal an....mit pihole -g braucht mein raspberry pi zero aktuell 8,6h mit pihole 5 hat es 1,5h gebraucht....entfernen von listen geht bei mir ueberhaupt nicht...

yubiuser · December 4, 2023, 8:27pm

Das sollte definitiv nicht so sein. Wenn du nicht gleichzeitig 38 Listen entfernst, sondern nur 1, geht das dann auch recht langsam? Was zeigt dir unterdessen die Entwicklerconsole an (F12 im Browser). Gibts da irgendwelche Fehler?

yubiuser · December 4, 2023, 8:35pm

Ja, alle Listen werden nacheinander gelöscht. Hintergrund ist, dass die API immer nur eine Liste verarbeitet und daher das Array Stück für Stück abgearbeitet wird.

Ich hab jetzt mal 20 Dummy Listen hinzugefügt und dann per Multi-Select gelöscht - das dauert auf meinem NanoPI (viel schwächer als Pi 3B+) nur wenige Sekunden.

Kannst du das ganze Mal bitte wiederholen und statt top htop nehmen? Da kann man mit F2 > Display option nämlich "Tree view" und "Show custom thread names" anzeigen. Dann sehen wir, welcher Teil von FTL hier so hängt.

yubiuser · December 4, 2023, 8:36pm

Das klingt, als ob es zwei Probleme sind. Denn pihole -g wird gar nicht aufgeführt, wenn man im web interface eine Liste löscht. An welcher Stelle hängt es denn bei pihole -g genau? Wie viele Domains hast du auf deinen Listen?

milo · December 4, 2023, 9:30pm

@yubiuser Aktuell habe ich 18739513 domains auf den Listen. ess haengt bei "built tree..."

das ist mein Skript

#!/bin/bash

rm zeit.txt 2>&1 > update.txt
rm update.txt 2>&1 > update.txt

before=$(date +%s)
pihole -g 2>&1 > update.txt
after=$(date +%s)

echo "elapsed time:" $((after - $before)) "seconds" > zeit.txt

das ist die ausgabe unter pihole v6

elapsed time: 31157 seconds

Hardware pi zero wh
OS: diet pi

ich habe gerade einen Lauf mit pihole v5 gestartet und update die info morgen hier

DL6ER · December 4, 2023, 10:38pm

Der Unterschied ist hier:

github.com

pi-hole/FTL/blob/37e838821529d9b4b12a9781ca5cbac7eb8f9ebc/src/database/gravity-db.c#L1890-L1893


      
          		// This is actually a three-step deletion to satisfy foreign-key constraints
          		querystr[0] = "DELETE FROM gravity WHERE adlist_id = (SELECT id FROM adlist WHERE address = :argument);";
          		querystr[1] = "DELETE FROM antigravity WHERE adlist_id = (SELECT id FROM adlist WHERE address = :argument);";
          		querystr[2] = "DELETE FROM adlist WHERE address = :argument;";

Wenn eine Liste gelöscht wird, dann haben wir in Pi-hole v5 eventuell weiterhin tausende von Listeneinträgen (d.h. Domains), die auf eine nicht-(mehr)-existente Liste verweisen. Diese Datenbankbeziehung ist also "zerbrochen". Dies wird in v6.0 verhindert - hat aber auch den Nachteil, dass die Baumstruktur dafür aktualisiert werden muss.

Hmm, guter Rat ist hier teuer. Ich nehme an die Lösung wird lauten die foreign key Beziehungen zu entfernen, konkret:

Erstens

Die Referenzierungen (REFERENCES adlist (id)) bei:

github.com

pi-hole/pi-hole/blob/e3643499010a1e788ceee3725c46fc100ac55dc9/advanced/Templates/gravity.db.sql#L50-L60


      
          CREATE TABLE gravity
          (
          	domain TEXT NOT NULL,
          	adlist_id INTEGER NOT NULL REFERENCES adlist (id)
          );
          
          CREATE TABLE antigravity
          (
          	domain TEXT NOT NULL,
          	adlist_id INTEGER NOT NULL REFERENCES adlist (id)
          );

entfernen.

Zweitens

Oben die beiden DELETE FROM (anti)gravity Schritt aus FTL entfernen. Damit muss dann der Baum dieser elendig großen Tabellen nicht aktualisiert werden.

Drittens

Damit leben, dass Domains von einer gelöschten Liste weiterhin zu Seitenblockierungen führen können bis der nächste manuelle Lauf von pihole -g abgeschlossen ist.

Das sollte den Zustand bei v5.0 wiederherstellen - unsauberer aber deutlich schneller.
@yubiuser Deine Meinung?

milo · December 5, 2023, 5:43am

Das Ergebnis mit pihole v5

elapsed time: 7827 seconds

Pihole v5 war Faktor 4 schneller

Christian_Sch · December 5, 2023, 10:57am

Wenn ich die Tage dazu komme gerne

Bezüglich eures Woraround das erst nach einem Manuellen Update die Liste erneuert wird bin ich aber auch kein Fan. Ich sehe mich und andere schon jammern warum Seite xy geblockt wird

milo · December 5, 2023, 4:09pm

Soll ich das Thema splitten?

DL6ER · December 7, 2023, 9:16pm

Ich habe hier einen möglichen Lösungsvorschlag erarbeitet:

github.com/pi-hole/FTL

Implement special POST :batchDelete callbacks

pi-hole:development-v6 ← pi-hole:new/batchDelete

opened 05:58PM - 07 Dec 23 UTC

DL6ER

+762 -160

# What does this implement/fix? This PR implements new special `POST :batchDe…lete` callbacks for `/api/groups`, `/api/domains`, `/api/clients`, and `/api/lists`. While not being immediately obvious, this is actually acceptable in the REST-world, see e.g., [Custom methods | Cloud APIs | Google Cloud](https://cloud.google.com/apis/design/custom_methods) for a similar implementation. While batch-deletion could indeed by very simple in the sense of ``` sql DELETE FROM adlist WHERE id IN (:some_list); ``` this is unfortunately not possible with SQLite3 as the `IN ()` operator lacks support for binding variables. So I ended up implementing the following workaround that uses parameter binding to eliminate any possibility of SQL injections: 1. Start a transaction 1. Create a `TEMPORARY` table (lives only in memory) called `deltable` 2. Iterate through the user input and `INSERT` each row into this table (values are bound to the table) 3. Then run SQL like ``` sql DELETE FROM gravity WHERE adlist_id = (SELECT id FROM adlist WHERE address IN (SELECT item FROM deltable)); DELETE FROM antigravity WHERE adlist_id = (SELECT id FROM adlist WHERE address IN (SELECT item FROM deltable)); DELETE FROM adlist WHERE address IN (SELECT item FROM deltable); ``` 4. Delete the temporary table 5. Commit the transaction If anything fails, we `ROLLBACK` to undo anything. Surely this SQL will not win a beauty contest due to the involved subqueries but they are so fast and their results are so small that I couldn't be bothered to use `JOIN` instead. Addendum: It is actually more tricky for domains as they are identified in addition by a `type`, so their temporary database is `(item, type)` and the SQL looks like: ``` sql DELETE FROM domainlist WHERE domain IN (SELECT item FROM deltable WHERE type = 0) AND type = 0; DELETE FROM domainlist WHERE domain IN (SELECT item FROM deltable WHERE type = 1) AND type = 1; DELETE FROM domainlist WHERE domain IN (SELECT item FROM deltable WHERE type = 2) AND type = 2; DELETE FROM domainlist WHERE domain IN (SELECT item FROM deltable WHERE type = 3) AND type = 3; ``` This PR should still work fine with `web` on branch `development-v6` which does not use `:batchDelete`. However, to really get the speed benefits, you'll really need to switch `web` to the accompanying branch (it has the same name). This ensures that your deletions - regardless how many things you delete - will all be done at once. ---- **Related issue or feature (if applicable):** N/A **Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A --- **By submitting this pull request, I confirm the following:** 1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against. 2. I have commented my proposed changes within the code. 3. I am willing to help maintain this change if there are issues with it later. 4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1) 5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)) ## Checklist: - [x] The code change is tested and works locally. - [x] I based my code and PRs against the repositories `developmental` branch. - [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions - [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship - [x] I have read the above and my PR is ready for review.

Bitte testet das bei Euch mit

pihole checkout ftl new/batchDelete
pihole checkout web new/batchDelete

und dann noch einmal Listen löschen. Wenn schon nicht unbedingt "schnell, sollte es doch zumindest schneller gehen als zuvor.

Es ist die schnellstmögliche Lösung ohne das oben angesprochene Problem:

milo · December 11, 2023, 3:38pm

getting this error during checkout

sqlite3: Error: unknown option: -ni
Use -help for a list of options

DL6ER · December 11, 2023, 8:40pm

Please run pihole -up, your version of FTL is outdated. It is difficult to keep all the many branches we have currently open due to review jam up-to-date.

milo · December 11, 2023, 9:42pm

Ich habe folgende Befehle verwendet

pihole checkout ftl new/batchDelete
pihole checkout web new/batchDelete

DL6ER · December 12, 2023, 6:28pm

Geht es denn nach einem pihole -up ?