uiDivStats uiDivStats - WebUI for Diversion statistics

[gattaca]

^^^ On the LAN tab! Yeap, you got me too. I updated, saw the "db exists errors too" and then it went poof gone from the "Tools" tab... Looks good though, data is showing up. I am wondering though, the pixelserv stats are no longer displayed here? Thanks!

 

[Jack Yaz]

I have the exact same issue. I have the RT-5300 router, BTW.

I did not know what was taking up so much CPU. To a point that ssh into the router would take almost 1 minute, and even browsing the net was sluggish. I did a Hard reset and started over.

I installed diversion. Rebooted, Installed uiDivStats. As soon as I enabled it, my router would be sluggish again. The moment I uninstalled uiDivStats I was able to use my router as expected.

For now, I cannot install uiDivStats till it is more stable. I am thinking it has something to do with the sqlite3 that gets installed. I am not sure if all routers can handle a "db" on it.

thanks

Did you try toggling to a queries only?

 

[Jack Yaz]

Did you try toggling to a queries only?

Also you should test the write speeds to your USB

 

[Jack Yaz]

I did.. There was no difference.

Try running your USB through iozone (https://www.snbforums.com/threads/entware-which-usb-stick-performs-well.48188/)

 

[Jack Yaz]

I'm getting anywhere between 51 -59 MB/s

For writing? Huh, weird. If you run atop what do you see for DSK usage? How many clients do you have on your network?

How much activity do you see if you run

tail -F /opt/var/log/dnsmasq.log

 

[Jack Yaz]

I have about 30+ clients connected, and there is quite a bit of activity in dnsmasq.log.

Let me reboot my router again and re-install uiDivStats and get all the data.

If I find time I'll try and get the tmpfs caching branch in a testable state. The idea in that branch is that queries get stored in tmpfs (memory) and written to the database every 5-10 minutes - thus reducing how much writing to usb is done

 

[Jack Yaz]

so this is what I have with atop for DSK:

DSK | sda | busy 97% | read 1 | write 26 871 | KiB/w 42 | MB15s 0.4 | MBw0s 0.1 | avi0 | avio 359 ms

Looks like your disk is choking when being written to. Can you post the full output from iozone so I can compare to my own please?

Best to stop taildns while testing:

/opt/etc/init.d/S90taildns stop

 

[Jack Yaz]

Here is the output:

 Run began: Mon Jun 15 18:16:23 2020
        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 20480 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: /jffs/bin/iozone -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
           20480       4      420      421    22094    23844     4820      341
           20480      16     1313      834    46999    48285    15954     1660
           20480     512     4596    48676    95658    97644    87813    48324
           20480    1024     4832    47854    95146    95986    91736    48831
           20480   16384     5109    49470   101673   104801   104483    50384
iozone test complete.

If anything your drive is a lot better than mine!

    Run began: Mon Jun 15 19:01:26 2020

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 20480 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                   
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
           20480       4      601      796     2522     4740     3619      342                                                               
           20480      16     1267     1838    12683    12776    10284     1483                                                               
           20480     512     3396     1460    27080    27271    26988     3862                                                               
           20480    1024     2997    12091    24741    26382    26248     3914                                                               
           20480   16384     5812     1976    27002    24840    26263     4186                                                               

iozone test complete.

 

[Jack Yaz]

At least I have that going for me

Is there a way to run a check on my drive from the router?

Not sure what else it could be..I'm just grasping at straws right now.

BTW, I've stopped taildns for the moment.

With taildns stopped I assume you aren't seeing the CPU usage?

 

[CriticJay]

Hey Jack,

Here is what I am thinking regarding the performance issues people are seeing with v2.0 of the script:

with v2.0+ it's very dependent on USB performance. Many of us were using USB 2.0 sticks of varying performance levels, and v2.0 of the script is revealing those inadequate USB sticks - and for whatever reason, those sticks were good enough to handle basic Entware / Diversion / Skynet but they are not sufficient for uiDivStats.

My previous USB stick was usb 2.0 and was 12 years old (lol). When I first tried v2.0 with it, atop reported 100% busy DSK almost all the time and colored it red a lot. The Network Map CPU usage graph showed both cores of my router alternately spiking to 100%. Later when i tested that stick on my PC I found it had really bad write speeds, so it was probably dying or something ... I threw it out

I found another USB stick, it's also USB 2.0, but slightly newer. On my PC I confirmed that write speeds appeared to be appropriate for the USB 2.0 spec.
Now when I used the v2.0 script, the DSK line in atop shows no more than 15-30% busy, occasionally peaks to 40% briefly. No more red coloring. Network map's CPU usage graph? It does show both cores as active but they don't spike all the way to 100% ... maybe they hit 50% occasionally. Usually they bounce between 5% and 30%. So it looks like the CPU is busy but it's able to handle it. If I wanted to I could just leave it like this ...

But I'm curious what would happen if I uninstalled uiDivStats entirely, even though I have a better USB stick now. So when I did that, atop DSK busy went down to 0-4% and Network Map CPU usage graph stays between 0% and 9%!! And that's with the following scripts/features running: FreshJR Adaptive QoS, Skynet (but NO AiProtection), and Diversion Standard with pixelserv-TLS.

Congratulations if you got to the end of my story. Moral of the story: uiDivStats is an absolutely AWESOME script but it seems to be a bit heavy on USB 2.0 sticks. Should we be using USB 3.0 sticks instead? Alternately, I am very interested to see if your "tmpfs" solution can help in situations like this.

Thanks!

 

[Jack Yaz]

@CriticJay and @TheMorpN would you mind trying my latest branch?
Edit line 19 of /jffs/scripts/uiDivStats to read

readonly SCRIPT_BRANCH="cachetotmp"

then run option uf.

This branch will instead store DNS queries in /tmp/cache-uiDivStats-SQL.tmp and then write them to the USB db at 4,9,14,19,24,29,34,39,44,49,54,59 past the hour.

The query log in the WebUI won't update correctly at the moment since it wont have the cached data available, but it's WIP.

 

[Jack Yaz]

After a few hours, my cpu and disk usage started to peg at 100% and router started to be sluggish.

After I switched to the cachetotmp branch, it helped, but there are still quite a few jumps in cpu and the cpu never goes below 15%

In the end, I uninstalled it. Will wait to see how things progress before I reinstall. Thanks again for everything.

Hm. There should be no DSK usage other than every 5mins in cachetotmp

 

[AntonK]

Shouldn't uiDivstats be pulled from the Available Scripts listing under ASUSWRT-Merlin Terminal Menu until the script is stabilized?

 

[dave14305]

Shouldn't uiDivstats be pulled from the Available Scripts listing under ASUSWRT-Merlin Terminal Menu until the script is stabilized?

No, the script isn’t “unstable.” The script works fine, but some people’s DNS usage causes it to overwhelm the USB stick. Uninstall is always an option.

 

[AntonK]

Ok. Thanks. But as a non-techie end-user, my experience was that the latest version immediately pegged my router's CPU usage to 95%+, and an uninstall of the script failed to get rid of the LAN-Diversion and uiDivstats tabs, even after multiple reboots. I had to zero out my USB stick and rebuild my router to get back to baseline.

I don't know what "people's DNS usage" means, but I've got 1 iPhone, 1 Echo, and 1 Desktop on my network. I can't imagine I'm stressing the router's or the script's DNS handling.

 

[doczenith1]

I think I am having some of the issues that others have reported. I have been loosely following the thread so I apologize in advance if my question has been previously answered.

A few days ago I upgraded uiDivStats to 2.0.0. Today I noticed that the stats tab was not showing up in the LAN section. I ran amtm and then j5. I noticed that the script started doing stuff and I noticed something about database generation or something like that. In the system log on the router I see:
Jun 16 18:32:25 uiDivStats: New version of taildns.tar.gz downloaded
Jun 16 18:32:25 uiDivStats: Starting first run of stat generation...

This was 4 hours ago. I am also noticing that cores 1 and 2 are bouncing back and forth between 100%. Looks like a single threaded operation is at 100% and switching between cores.

I am using an older 8GB USB 2.0 flash drive with a 2 GB swap file. I'm pretty sure I formatted it ext4 with journaling via amtm a few years ago. It has ran trouble free since.

Do I just wait until if finishes? Is it in a loop? I saw something about switching an option between A/AAAA that might help. Can I do that while it's in the middle of the stat generation?

Edit: I see that the A/AAAA thing is new with 2.1.0 and I'm on 2.0.0.

 

[Jack Yaz]

I don't think anyone can control DNS usage. I don't think I "browse" more than the average person. I am also using a USB 3.0 stick which does not show any errors on it.

With the caching mode you didn't provide any helpful information for me to track dowm the issue. I sent an infinitely looping dns query from a client to test and couldn't stress the CPU with the cache so I don't know why you're seeing increased cpu with the cache. I need the output from atop to check if dsk is still your limiting factor, or something else. Checking htop/top if uiDivStats is using CPU or something else is needed.

 

[Jack Yaz]

No, the script isn’t “unstable.” The script works fine, but some people’s DNS usage causes it to overwhelm the USB stick. Uninstall is always an option.

Thanks Dave. I guess I was lucky with who I chose in the first round of testing and then those that opted in to the open call for testing that noone had issues....

 

[Jack Yaz]

Ok. Thanks. But as a non-techie end-user, my experience was that the latest version immediately pegged my router's CPU usage to 95%+, and an uninstall of the script failed to get rid of the LAN-Diversion and uiDivstats tabs, even after multiple reboots. I had to zero out my USB stick and rebuild my router to get back to baseline.

I don't know what "people's DNS usage" means, but I've got 1 iPhone, 1 Echo, and 1 Desktop on my network. I can't imagine I'm stressing the router's or the script's DNS handling.

Diversion tab is nothing to do with uiDivStats' tab.

 

[Jack Yaz]

I think I am having some of the issues that others have reported. I have been loosely following the thread so I apologize in advance if my question has been previously answered.

A few days ago I upgraded uiDivStats to 2.0.0. Today I noticed that the stats tab was not showing up in the LAN section. I ran amtm and then j5. I noticed that the script started doing stuff and I noticed something about database generation or something like that. In the system log on the router I see:
Jun 16 18:32:25 uiDivStats: New version of taildns.tar.gz downloaded
Jun 16 18:32:25 uiDivStats: Starting first run of stat generation...

This was 4 hours ago. I am also noticing that cores 1 and 2 are bouncing back and forth between 100%. Looks like a single threaded operation is at 100% and switching between cores.

I am using an older 8GB USB 2.0 flash drive with a 2 GB swap file. I'm pretty sure I formatted it ext4 with journaling via amtm a few years ago. It has ran trouble free since.

Do I just wait until if finishes? Is it in a loop? I saw something about switching an option between A/AAAA that might help. Can I do that while it's in the middle of the stat generation?

Edit: I see that the A/AAAA thing is new with 2.1.0 and I'm on 2.0.0.

Probably best to uninstall, delete the database and install fresh on 2.1.0

rm /opt/share/uiDivStats/dnsqueries.db