uiDivStats Web browsing completely impacted nightly apparently by uiDivStats record trimming?

[crezam]

I have noticed while I browse the web, every night from all my devices there is timeouts after midnight for about 6 or 7 mins. From the logs appears uiDivStats trimming happens during this time.

1. Is this supposed to be such an intensive process that consumption of router resources impacts web routing?
2. Could this be a problem with my current DB? Im thinking of resetting it
3. Wouldnt mind if this happened while I sleep (say 4 am). Is there a setting to change time?

Aug 11 00:01:00 RT-AX86U-43C8 uiDivStats: Trimming records entries from database...
Aug 11 00:01:51 RT-AX86U-43C8 hostapd: eth7: STA 7a:fb:78:36:29:87 IEEE 802.11: associated
Aug 11 00:01:55 RT-AX86U-43C8 hostapd: eth7: STA 7a:fb:78:36:29:87 IEEE 802.11: disassociated
Aug 11 00:01:55 RT-AX86U-43C8 hostapd: eth7: STA 7a:fb:78:36:29:87 IEEE 802.11: disassociated
Aug 11 00:02:42 RT-AX86U-43C8 hostapd: eth7: STA f4:f5:d8:b3:39:90 IEEE 802.11: disassociated
Aug 11 00:06:01 RT-AX86U-43C8 hostapd: eth7: STA f4:f5:d8:b3:39:90 IEEE 802.11: associated
Aug 11 00:06:01 RT-AX86U-43C8 hostapd: eth7: STA f4:f5:d8:b3:39:90 RADIUS: starting accounting session 099299A9B01BEEAF
Aug 11 00:06:01 RT-AX86U-43C8 hostapd: eth7: STA f4:f5:d8:b3:39:90 WPA: pairwise key handshake completed (RSN)
Aug 11 00:07:49 RT-AX86U-43C8 hostapd: eth7: STA ee:25:0f:9c:9f:5e IEEE 802.11: associated
Aug 11 00:07:49 RT-AX86U-43C8 hostapd: eth7: STA ee:25:0f:9c:9f:5e RADIUS: starting accounting session AA717D7555D71031
Aug 11 00:07:49 RT-AX86U-43C8 hostapd: eth7: STA ee:25:0f:9c:9f:5e WPA: pairwise key handshake completed (RSN)
Aug 11 00:07:51 RT-AX86U-43C8 hostapd: eth7: STA ee:25:0f:9c:9f:5e IEEE 802.11: disassociated
Aug 11 00:07:51 RT-AX86U-43C8 hostapd: eth7: STA ee:25:0f:9c:9f:5e IEEE 802.11: disassociated
Aug 11 00:08:14 RT-AX86U-43C8 uiDivStats: Record trimming complete

 

[bjark]

I have the same issue, router is mostly unresponsive and network is down every night for around one hour (!) starting at midnight. Started Oct 5 based on connmon data. I ran uidivstats trimdb now and had the same result, one hour of extreme instability/downtime.

The dnsqueries.db file is 2.8GB, oldest record seems to be from Sep 03 2024 00:01:01.

My uidivstats settings are:
5000 queries will be shown
30 days data will be kept
all query types will be logged
tmp being used to cache query records

System:
ASUSWRT-Merlin GT-AX6000 3004.388.8_2
SQLite version 3.41.2
/mnt/128GB_SSD Size 116.9G Used 6.3G (6%)
Diversion 5.3
uiDivStats 4.0.1

I guess I could just delete dnsqueries.db for a temporary solution, but if I can help out with fixing some coding bug or find some underlying error in my setup that would be nice.

 

[bjark]

I just noted that there is a brand new v4.0.2 version of uiDivStats, now updated to that version and retrying trimdb.

 

[bjark]

Sad to report there was no improvement after updating to v4.0.2.

 

[dave14305]

Sad to report there was no improvement after updating to v4.0.2.

I believe many people came to the conclusion that the uiDivStats logging DB worked best with an attached SSD drive instead of a measly USB stick. The slow write times of a cheap stick can create a lot of “waiting for disk I/O” on the router.

 

[bjark]

I believe many people came to the conclusion that the uiDivStats logging DB worked best with an attached SSD drive instead of a measly USB stick. The slow write times of a cheap stick can create a lot of “waiting for disk I/O” on the router.

I've been using a fast SSD all this time. Or am I possibly missing something in my setup that makes me not use it for uiDivStats?