fff-dhcp: increase dns cachesize from 150 to 8k #28
No reviewers
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#28
Loading…
Reference in New Issue
No description provided.
Delete Branch "jkimmel/firmware:dnsmasq-cache"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Reviewed-by: Fabian Bläse <fabian@blaese.de>
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.)
PKG_RELEASE bump fehlt.
@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
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)?
b2a23bc9cf
to7591c72b44
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 ...
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.
7591c72b44
to6060a5b869
rebased.
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.
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.
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.
Hab gerade folgendes in der Manpage entdeckt:
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:
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: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?
6060a5b869
to4b977c0572
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.
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.
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.
4b977c0572
todea577c647
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?
d1370a8229
todea577c647
dea577c647
to8e3db2b314
Ich habe dazu keine Meinung mehr.
Auf meinen staging tree applied, danke.
Pull request closed