fff-dhcp: increase dns cachesize from 150 to 8k #28

Closed
jkimmel wants to merge 1 commits from jkimmel/firmware:dnsmasq-cache into master
Owner

The default cachesize for dnsmasq is 150 entries, which results in a
poor cache hit rate.

Increasing the cachesize to 8192 entries will increase the RAM usage by
approximately 700kB (about 100 Bytes per entry). The size was chosen
empirically. Higher values don't seem to increase cache hit rate a lot.

Signed-off-by: Johannes Kimmel fff@bareminimum.eu

The default cachesize for dnsmasq is 150 entries, which results in a poor cache hit rate. Increasing the cachesize to 8192 entries will increase the RAM usage by approximately 700kB (about 100 Bytes per entry). The size was chosen empirically. Higher values don't seem to increase cache hit rate a lot. Signed-off-by: Johannes Kimmel <fff@bareminimum.eu>
Owner

Reviewed-by: Fabian Bläse <fabian@blaese.de>

`Reviewed-by: Fabian Bläse <fabian@blaese.de>`
fbl approved these changes 2021-01-05 02:07:12 +01:00
Owner

Scheint ja eine abgekartete Sache zu sein.

Ich gehe davon aus, ihr seid euch bewusst, dass das die 64MB Geräte mit ath10k wahrscheinlich damit nicht klarkommen. (Allerdings weiß ich auch nicht, ob die vorher überhaupt mit layer-3 benutzbar waren.)

Scheint ja eine abgekartete Sache zu sein. Ich gehe davon aus, ihr seid euch bewusst, dass das die 64MB Geräte mit ath10k wahrscheinlich damit nicht klarkommen. (Allerdings weiß ich auch nicht, ob die vorher überhaupt mit layer-3 benutzbar waren.)
Owner

PKG_RELEASE bump fehlt.

PKG_RELEASE bump fehlt.
adschm added the
layer3
packages/fff
labels 2021-01-05 02:11:09 +01:00
Author
Owner

@adschm Ja die sache mit den ath10k Geräten kam auf, das müsste man eventuell einmal vorher testen.

Versionsbump kommt gleich... Ich kanns mir nicht merken :D

@adschm Ja die sache mit den ath10k Geräten kam auf, das müsste man eventuell einmal vorher testen. Versionsbump kommt gleich... Ich kanns mir nicht merken :D
Owner

Ja die sache mit den ath10k Geräten kam auf, das müsste man eventuell einmal vorher testen.

Bei mir läuft halt sowas wie der C60 schon mit node-firmware unter hoher Last nicht mehr stabil. Ggf. erledigt sich das Problem dadurch, weil die eh nicht gehen.

Habt ihr mal 64 MB Geräte ohne ath10k angekuckt? Was macht denn so ein TL-WR1043N(D)?

> Ja die sache mit den ath10k Geräten kam auf, das müsste man eventuell einmal vorher testen. Bei mir läuft halt sowas wie der C60 schon mit node-firmware unter hoher Last nicht mehr stabil. Ggf. erledigt sich das Problem dadurch, weil die eh nicht gehen. Habt ihr mal 64 MB Geräte ohne ath10k angekuckt? Was macht denn so ein TL-WR1043N(D)?
jkimmel force-pushed dnsmasq-cache from b2a23bc9cf to 7591c72b44 2021-01-05 02:19:12 +01:00 Compare
Owner

The size was chosen empirically. Higher values don't seem to increase cache hit rate a lot.

Hier stellt sich mir als Wissenschaftler die Frage, ob es klug/notwendig ist, sich auf das Optimum eines Parameters zu setzen.

Ggf. kann man mit geringerem cache immer noch eine Verbesserung bei geringeren Kosten erreichen? Oder anders gefragt: Der Speicherbedarf skaliert ja scheinbar linear, wie skaliert denn die cache hit rate? Kann man da ggf. ne Messreihe mit in die Commit-Message einbauen? Gemessen habt ihr ja scheinbar was ...

> The size was chosen empirically. Higher values don't seem to increase cache hit rate a lot. Hier stellt sich mir als Wissenschaftler die Frage, ob es klug/notwendig ist, sich auf das Optimum eines Parameters zu setzen. Ggf. kann man mit geringerem cache immer noch eine Verbesserung bei geringeren Kosten erreichen? Oder anders gefragt: Der Speicherbedarf skaliert ja scheinbar linear, wie skaliert denn die cache hit rate? Kann man da ggf. ne Messreihe mit in die Commit-Message einbauen? Gemessen habt ihr ja scheinbar was ...
Author
Owner

Also gemessen hab ich das vor 1-2 Jahren mal, als ich zuhause umgebaut habe. Ist natürlich ein Wert, der von meiner Nutzung maßgeblich beeinflusst ist.

8k reicht bei mir, dass sich der Cache gerade so innerhalb von ca. 24h füllt, das habe ich auch gerade noch einmal geprüft. Also alles, was cachebar ist, hat auch Platz. Deswegen habe ich persönlich kaum einen Vorteil in einem größeren Cache gesehen, das kann natürlich bei größeren Netzen und vielen verschiedenen Nutertypen etwas anders aussehen.

Weil ich keine platzprobleme beim Arbeitsspeicher habe, habe ich natürlich jetzt nicht mehrere Tage Statistiken zu anderen Cachegrößen geführt.

Die Messung ist aber wahnsinnig abhängig von der Nutzung. Bei viel Anfragen, können natürlich auch mehr aus dem Cache beantwortet werden, bevor die TTL ausläuft. Die erste Anfrage ist immer ein Miss, also ist bei wenig Verkehr die Cache Hit Rate auch immer bescheiden.

Also ich hab so meine Zweifel, dass ich alleine da bessere Zahlen liefern kann.

Also gemessen hab ich das vor 1-2 Jahren mal, als ich zuhause umgebaut habe. Ist natürlich ein Wert, der von meiner Nutzung maßgeblich beeinflusst ist. 8k reicht bei mir, dass sich der Cache gerade so innerhalb von ca. 24h füllt, das habe ich auch gerade noch einmal geprüft. Also alles, was cachebar ist, hat auch Platz. Deswegen habe ich persönlich kaum einen Vorteil in einem größeren Cache gesehen, das kann natürlich bei größeren Netzen und vielen verschiedenen Nutertypen etwas anders aussehen. Weil ich keine platzprobleme beim Arbeitsspeicher habe, habe ich natürlich jetzt nicht mehrere Tage Statistiken zu anderen Cachegrößen geführt. Die Messung ist aber wahnsinnig abhängig von der Nutzung. Bei viel Anfragen, können natürlich auch mehr aus dem Cache beantwortet werden, bevor die TTL ausläuft. Die erste Anfrage ist immer ein Miss, also ist bei wenig Verkehr die Cache Hit Rate auch immer bescheiden. Also ich hab so meine Zweifel, dass ich alleine da bessere Zahlen liefern kann.
jkimmel force-pushed dnsmasq-cache from 7591c72b44 to 6060a5b869 2021-01-28 10:25:36 +01:00 Compare
Author
Owner

rebased.

rebased.
Owner

Also mir ist das zuviel RAM für eine default-Einstellung. Ich würde hier überlegen, ob man das nicht einfach als Option in /etc/config/gateway aufnimmt. Man kann als default dann ja einen Kompromiss machen und 500 oder 1000 Einträge vorgeben (per Example-Config), und dann kann jeder nach Bedarf, Wunsch und Gerät weiter anpassen.

Also mir ist das zuviel RAM für eine default-Einstellung. Ich würde hier überlegen, ob man das nicht einfach als Option in /etc/config/gateway aufnimmt. Man kann als default dann ja einen Kompromiss machen und 500 oder 1000 Einträge vorgeben (per Example-Config), und dann kann jeder nach Bedarf, Wunsch und Gerät weiter anpassen.
Author
Owner

Wollen wir hier wirklich herumeiern? Kann das vielleicht einfach jemand mit einem betreffenden Geraet testen, ob der Verbrauch wirklich ein Problem wird? Weil wenn nicht, sehe ich keinen Grund das nicht so hoch zu schrauben.

Wollen wir hier wirklich herumeiern? Kann das vielleicht einfach jemand mit einem betreffenden Geraet testen, ob der Verbrauch wirklich ein Problem wird? Weil wenn nicht, sehe ich keinen Grund das nicht so hoch zu schrauben.
Owner

Naja, ich sehe das eher umgekehrt, bei begrenztem RAM gibt es eigentlich wenig Grund, nur für das Caching eines einzelnen Dienstes so viel RAM zu verbraten.

Naja, ich sehe das eher umgekehrt, bei begrenztem RAM gibt es eigentlich wenig Grund, nur für das Caching eines einzelnen Dienstes so viel RAM zu verbraten.
Author
Owner

Hab gerade folgendes in der Manpage entdeckt:

The cache statistics are also available in the DNS as answers to
queries of class CHAOS and type TXT in domain bind. The domain names
are cachesize.bind, insertions.bind, evictions.bind, misses.bind,
hits.bind, auth.bind and servers.bind. An example command to query
this, using the dig utility would be
 
dig +short chaos txt cachesize.bind

Man kann auch mehrere auf einmal abrufen:

dig +short chaos txt cachesize.bind insertions.bind misses.bind hits.bind

In meinem privaten Netz bekomm ich nach 8h folgende Zahlen:

"8192"
"5439"
"189188"
"475417"

Weil noch nix aus dem Cache verworfen wurde ist die Hitrate ziemlich gut (und steigt grade lustig weiter)

In Freifunknetz kann ich nicht sagen, wie lange da schon der dnsmasq laeuft, aber vermutlich schon 1-2 Wochen. Dort habe ich folgende Zahlen:

"8192"
"460666"
"180308"
"38567"

Das Netz wird nur unregelmaeßig benutzt. Schwer zu sagen, ob ein groesserer Cache etwas bringt. Die kleine Hitrate koennte daher kommen, dass bei wenig Nutzung die Eintraege veralten, bevor sie etwas nutzen.

Ich werde das jetzt mal einfach etwas loggen, vielleicht kommt man so an nuetzlichere Werte.

Vielleicht auch hat auch noch jemand lust, etwas Statistik zu sammeln?

Hab gerade folgendes in der Manpage entdeckt: ``` The cache statistics are also available in the DNS as answers to queries of class CHAOS and type TXT in domain bind. The domain names are cachesize.bind, insertions.bind, evictions.bind, misses.bind, hits.bind, auth.bind and servers.bind. An example command to query this, using the dig utility would be dig +short chaos txt cachesize.bind ``` Man kann auch mehrere auf einmal abrufen: `dig +short chaos txt cachesize.bind insertions.bind misses.bind hits.bind` In meinem privaten Netz bekomm ich nach 8h folgende Zahlen: ``` "8192" "5439" "189188" "475417" ``` Weil noch nix aus dem Cache verworfen wurde ist die Hitrate ziemlich gut (und steigt grade lustig weiter) In Freifunknetz kann ich nicht sagen, wie lange da schon der `dnsmasq` laeuft, aber vermutlich schon 1-2 Wochen. Dort habe ich folgende Zahlen: ``` "8192" "460666" "180308" "38567" ``` Das Netz wird nur unregelmaeßig benutzt. Schwer zu sagen, ob ein groesserer Cache etwas bringt. Die kleine Hitrate koennte daher kommen, dass bei wenig Nutzung die Eintraege veralten, bevor sie etwas nutzen. Ich werde das jetzt mal einfach etwas loggen, vielleicht kommt man so an nuetzlichere Werte. Vielleicht auch hat auch noch jemand lust, etwas Statistik zu sammeln?
jkimmel force-pushed dnsmasq-cache from 6060a5b869 to 4b977c0572 2021-11-05 15:15:57 +01:00 Compare
Owner

Um diesen alten Patch mal wieder auszugraben: Könnte 1k ein guter Kompromiss sein? 150 Einträge sind schon ziemlich wenig für einen DNS cache.

Alternativ könnte man dies auch in Abhängigkeit der Speichergröße setzen.

Um diesen alten Patch mal wieder auszugraben: Könnte 1k ein guter Kompromiss sein? 150 Einträge sind schon ziemlich wenig für einen DNS cache. Alternativ könnte man dies auch in Abhängigkeit der Speichergröße setzen.
Author
Owner

Ist Speichergröße ein gutes Maß? Waren vom RAM Mangel nicht eher Geräte betroffen, die wegen dem Wifi Treiber nichts übrig haben, statt der absoluten Größe des Speichers?

Irgend ein größerer Wert wäre definitiv schon mal besser als nichts zu tun. Allerdings dann am liebsten mit zusätzlicher Configoption - bin es langsam satt auf Geräten mit 200MB freien RAM das zeug ständig wieder manuell einstellen zu müssen.

Ist Speichergröße ein gutes Maß? Waren vom RAM Mangel nicht eher Geräte betroffen, die wegen dem Wifi Treiber nichts übrig haben, statt der absoluten Größe des Speichers? Irgend ein größerer Wert wäre definitiv schon mal besser als nichts zu tun. Allerdings dann am liebsten mit zusätzlicher Configoption - bin es langsam satt auf Geräten mit 200MB freien RAM das zeug ständig wieder manuell einstellen zu müssen.
Owner

Joa, eigentlich müsste man insbesondere ath10k noch als zusätzlichen Modifikator einbauen. Aber wenn wir z.B. nach 64MB und 128MB unterscheiden, dann ist 1MB hin oder her für die 8k Einträge, die du gern gehabt hättest, bei 128MB wahrscheinlich recht egal.

Joa, eigentlich müsste man insbesondere ath10k noch als zusätzlichen Modifikator einbauen. Aber wenn wir z.B. nach 64MB und 128MB unterscheiden, dann ist 1MB hin oder her für die 8k Einträge, die du gern gehabt hättest, bei 128MB wahrscheinlich recht egal.
jkimmel force-pushed dnsmasq-cache from 4b977c0572 to dea577c647 2021-12-31 12:42:22 +01:00 Compare
Author
Owner

Ja, ich denke du hast recht. Die problematischen Geräte haben scheinbar alle 64MB RAM. Insofern ziehen wir dort einfach die Grenze. Alles was wirklich mehr als 64MB hat, kann locker die 8k Einträge stemmen. Darunter kann man etwas vorsichtiger sein. Ich habe für den Fall 1024 gewählt.

@adschm Ist das für dich auch in Ordnung?

Ja, ich denke du hast recht. Die problematischen Geräte haben scheinbar alle 64MB RAM. Insofern ziehen wir dort einfach die Grenze. Alles was wirklich mehr als 64MB hat, kann locker die 8k Einträge stemmen. Darunter kann man etwas vorsichtiger sein. Ich habe für den Fall 1024 gewählt. @adschm Ist das für dich auch in Ordnung?
jkimmel force-pushed dnsmasq-cache from d1370a8229 to dea577c647 2022-01-03 11:49:36 +01:00 Compare
jkimmel force-pushed dnsmasq-cache from dea577c647 to 8e3db2b314 2022-01-03 11:50:31 +01:00 Compare
Owner

Ja, ich denke du hast recht. Die problematischen Geräte haben scheinbar alle 64MB RAM. Insofern ziehen wir dort einfach die Grenze. Alles was wirklich mehr als 64MB hat, kann locker die 8k Einträge stemmen. Darunter kann man etwas vorsichtiger sein. Ich habe für den Fall 1024 gewählt.

@adschm Ist das für dich auch in Ordnung?

Ich habe dazu keine Meinung mehr.

> Ja, ich denke du hast recht. Die problematischen Geräte haben scheinbar alle 64MB RAM. Insofern ziehen wir dort einfach die Grenze. Alles was wirklich mehr als 64MB hat, kann locker die 8k Einträge stemmen. Darunter kann man etwas vorsichtiger sein. Ich habe für den Fall 1024 gewählt. > > @adschm Ist das für dich auch in Ordnung? Ich habe dazu keine Meinung mehr.
fbl added this to the 20220405-beta milestone 2022-03-03 15:44:29 +01:00
Owner

Auf meinen staging tree applied, danke.

Auf meinen staging tree applied, danke.
fbl closed this pull request 2022-03-05 19:32:53 +01:00

Pull request closed

Sign in to join this conversation.
No description provided.