That being the case, take a row count before pruning and again after pruning.
select count(*) from <table name>
The row count SHOULD drop after pruning. The space used by the deleted rows will be
filled by new rows as they are stored... That's what "the book" says anyway.
On 3/8/19 8:49 PM, Dan Craciun wrote:
Actually, I haven't configured anything, just started ntopng with the -F
option and it created the tables.
They are innodb.
ls -lh
total 117G
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p0.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p1.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p2.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p3.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p4.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p5.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p6.ibd
-rw-r----- 1 mysql mysql 2.8G Mar 9 06:30 aggrflowsv4#P#p7.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p0.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p1.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p2.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p3.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p4.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p5.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p6.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 aggrflowsv6#P#p7.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p0.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p1.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p2.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p3.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p4.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p5.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p6.ibd
-rw-r----- 1 mysql mysql 12G Mar 9 06:35 flowsv4#P#p7.ibd
-rw-r----- 1 mysql mysql 176K Mar 2 22:54 flowsv6#P#p0.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p1.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p2.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p3.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p4.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p5.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p6.ibd
-rw-r----- 1 mysql mysql 176K Jan 15 15:45 flowsv6#P#p7.ibd
Best regards,
Dan
On 09-Mar-19 03:48, Bruce Ferrell wrote:
On 3/8/19 11:50 AM, Dan Craciun wrote:
Hi,
I've setup ntopng to dump flow data in a MySQL db, with 30 days
retention.
It's been over 45 days and the data is still there.
Furthermore, even if I manually delete the old data, the space occupied
is not freed. It grows at a rate of 3GB/day.
What is the correct procedure of reusing free space when using MySQL
storage?
Best regards,
Dan Craciun
What you're describing suggests the mysql DB was configured with
myisam tables spaces for the storage. It's a pretty common default.
Have a look at the optimize command and perhaps look at converting the
table space to innodb with file-per-table. To reconfigure for
innodb-file-per-table, the db has to be restarted and this should be
done before converting the tables to innodb. Once to make this change,
the myisam to innodb conversion can be done live.
You might also want to look up mysqltuner. It's a perl script that
can do some crude analysis of your mysql instances performance. It's
actually fairly useful.
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
