Dobrá, tak popořadě:

1) Provedl jsem test, abych si udělal představu o náročnosti datového přenosu nad nějakými reálnými daty.

Vzal jsem tu svoji cca 15MB databázi, smazal cache, restartoval unbound, abych promazal i jeho cache, vypnul forwardování, abych eliminoval cache providera po cestě. Poté jsem pustil příkaz, který celou cache majordoma znovu sestaví. Celou cache jsem nechal budovat se spuštěným tcpdumpem. Posbíraná data jsem profiltroval na udp a dns. Rád bych upozornil, že si v domácí síti provozuji autoritativní DNS servery, takže jsem tímto filtrem zachytil víc dat než vygeneroval samotný majordomo. Tento filtr celkem zachytil 21MB dat.

Tak a teď trocha kupeckých počtů. Vaše databáze má cca 75MB, tj. 5x víc než můj testovací vzorek. Tzn. že přenos, který vygeneruje majordomo na vašem routeru, by měl být kolem 105MB. I kdyby to byl dvojnásobek, je to 200MB. Což jsou naprosto jiná čísla.

2) Jak majordomo funguje. Někde tady na fóru jsem psal poměrně rozsáhlý technický přehled, jak je to řešené. Můžete se pro zajímavost podívat, ale to co je důležité na tomto místě: Jednou za hodinu z majordoma vypadne soubor, který představuje poslední hodinu nasbíraných dat. Těsně po tom se spustí proces, který na pozadí začne stavět cache, aby uživatel mohl přijít do luci a nečekat dlouhé vteřiny na zobrazení stránky. Jednou za 3 dny (někdy ve 3 v noci pokud se nepletu) se tato cache celá smaže a znovu začne budovat - aby se "občerstvila". To je v podstatě to, co jsem simuloval v předchozím testu.

Co to znamená: Jednou za 3 dny tam budete mít opravdu velký nárůst UDP trafficu. Ale nepřipadá mi úplně reálné, aby docházelo k tomu, že majordomo generuje nějaký nepřetržitý traffic. To by v podstatě znamenalo, že vaše síť generuje tolik dat, že to doplňování cache jednou za hodinu by muselo běžet celou tu hodinu. Moje 15MB databáze za ty cca 2 měsíce (v součtu) se obnovovala nějakých 40 minut. Podle vámi dodaných dat si nemyslím, že takový traffic generujete.

3) Co s tím. Rozhodně mohu slíbit, že se budu věnovat předělání té cache. Bezesporu to je místo, kde je nutné provést nějaké optimalizace a mám pár nápadů jak na to. Nedovedu odhadnout jak dlouho to bude trvat a do jaké aktualizace se výsledné úpravy dostanou.

Chtěl bych na vysvětlenou uvést, že při programování majordoma se dělalo několik odhadů na velikost dat a náročnost nějakých operací, ale jak říkám - odhadů. Skutečný provoz se pohybuje někde jinde, ale to je vidět až teď. Nyní už nějakou reálnou představu máme a je možné se pustit do optimalizací.

Pokud je pro vás generovaný přenos opravdu problém, doporučuji pokusit se zmenšit tu DB: Tj. zmenšit počet hodinových souborů, pohrát si s tím nastavením ohledně maxima uchovávaného v souborech. V krajním případě resolvování vypnout. Ale určitě se tady nemůžeme hádat o každý přenesený kilobajt. Každý nástroj, který něco dělá se musí na systémových prostředcích odrazit. Pokud o nástroj zájem máte, musíte s tím počítat, pokud to bolí, nelze nástroj provozovat. Platí to o všem a majordomo není výjimkou.

Chtěl bych všem poděkovat, že upozornili na problém, situace se bude řešit.

Budu tady trochu konkrétnější než kolega - pokud chcete posílat nějaké větší množství obrázků, vkládejte pouze odkaz. Nejen, že většina z nich má malou vypovídající hodnotu (jejich obsah se dá popsat slovy - my si to poté můžeme ověřit v našich statistikách), ale zároveň zbytečně nafukují stránku. Server, který na sdílení obrázků používáte, navíc konfiguroval nějaký inteligent, protože posílá hlavičku Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 - jinými slovy říká prohlížeči, že obrázky nemá cachovat a má si je vždy stáhnout. A v kombinaci s tím, že je ten server nechutně pomalý, každý obrázek se načítá několik sekund, a prohlížeče mají limit počtu připojení na jednoho hostitele, se opravdu v této diskuzi nedalo rozumně pracovat. Všechny Vaše příspěvky jsem proto upravil.

A teď k tomu, jak ulovit, co se u Vás děje (stejně tak u dalších uživatelů se stejným problémem):

- pokud ho ještě nemáte, nainstalujte tcpdump
- zapněte resolving v Majordomovi a počkejte nějakou chvíli, dokud se nezačnou dít ty divné věci (mělo by být vidět např. ve statistkách v LuCI)
- odpojte všechna zařízení a Wi-Fi, kromě počítače, přes který se připojíte na SSH (i z toho důvodu, abyste nezachytával provoz, který pro Vás může být nějak soukromý)
- spusťte tcpdump -i eth2 -w /tmp/dump.pcap & (to & na konci je důležité) a nechte nějakou dobu běžet - když mezitím odpojíte PC, ze kterého se na router připojujete, bude to jen dobře (opět kvůli možným citlivým datům)
- čas od času zkontrolujte (10 minut, půl hodiny, ...) jak je soubor velký (ls -lh /tmp/dump.pcap) - pokud bude velikost odpovídat růstu řádově jednotek MB za minutu, stačí, když nasbíráte nějakých pár desítek MB (jinými slovy - velikost by měla zhruba odpovídat trafficu, který vidíte ve statistikách, když se dějí ty divné věci)
- až budete mít dost dat, zabijte tcpdump, jednoduše třeba pomocí killall tcpdump - nebo si dohledejte v seznamu procesů jeho PID a zabijte ho přes kill PID
- napište, co jste pochytal - vzhledem k většímu objemu dat bychom pak museli vymyslet nějaký způsob zaslání, protože by to nejspíš mailem nešlo, ale jistě něco vymyslíme

Obrázky ze statistik v tomto případě už nemá smysl zasílat, ale výše uvedené by nám opravdu pomohlo, protože se nám přes veškeré snažení nedaří problém reprodukovat.

Tak jsem v předchozím příspěvku trochu kecal, problém zjevně byl, jenom jsem si ho nevšiml. Začátek evidentně souvisí s instalací Majordoma:

http://i.imgur.com/oyYiyFJ.png
http://i.imgur.com/SR8f63M.png

Začátek 49. týdne vypadá relativně v pořádku zřejmě jen proto, že jsem dělal několik restartů (z jiných důvodů).