I'm sorry to have set this to critical but the maximum size that my host phpMyAdmin will import is 9 Mb, I don't know if it's the size itself or the uncompressed version and at the rate the browscap table has been growing, I'm worried that if something happened to my site and had to restore it, that's I'd be in a tight spot ...
My premise pretty much get to the problem, so I need to restrict how much the browscap table can grow up to or some SQL command that I can periodically run to trim old or unnecessary data (preferably backing it up first, so moving it into another table that I can export then delete). I would've given a look at it in case I'd figure something out but the data is stored in BLOB ...
I'd prefer not to disable browscap as I use it through Statistics Advanced to ignore crawler hits.
Thanks for your prompt help
Comments
Comment #1
Romejoe commentedSimilar problem here.... I did a fresh install of the latest version and got directly after activating a problem with max_packet_allowed.
After this my Admin menu did not appear as normal but 2 Errors on the module site (one top one bottom). This messed up my entire database yesterday but I was glad to have a backup dome 1/2 an hour before.
There must somthing be either incompatible with Admin menu or its some sort of bug.
I have to disable this module because of this.
Edit: To make sure: I did had this problem (max_packet_allowed) earlier when installing modules since my server has a low setting. But after reloading it each time it got away. with this module it messed up the database and after a fresh backup and activating it again the first time it started again, so I deactivated it.
Comment #2
dynv commented@Gork I had no problem with ... Does it limit the of
browscaptable?Comment #3
Romejoe commentedI found the max_packet_allowed is a problem of Admin menu. No idea if the messing up was caused by this as well since I remember I might have bben testing a new version of it as well and I got no interest in "trying it again". ;=)
Comment #4
Romejoe commentedHmmm tried again and took the risk to mess all up again.... Seems it was not caused by browsecap, sorry for the false alarm!
Comment #5
gregglesGlad to hear it's fixed.
Comment #7
dynv commentedGork issue might be fixed but not mine: browscap table is still much larger than others, the largest beside cache_menu, and I'd like to have an option to limit its size ; see OP for more detail.
Comment #8
gregglesMaybe try deleting all the contents of the table? You can then rebuild it by visit admin/settings/browscap and see if it grows to 9MB or not.
What database engine do you use? Mysql or Postresql?
Comment #9
dynv commentedI'm using MySQL 5.1.49-1.
After truncating browscap table then refreshing Browscap data (/admin/settings/browscap/refresh), it saved a Mb, down to 2.6 Mb. I wonder if leaving it alone for a while won't have it grow. :|
Comment #10
gregglesYeah, let's see what happens. Note that the table gets updated with values not found in the table already...so it will grow.
You said 9MB in the original post and now 2.6MB - that seems like a big difference...? Or was it 9MB for the whole database and only 2.6MB for this table.
Ultimately "it's a lot of data, it will take up a lot of space" and there's not much we can or should do about that as a module.
Comment #11
dynv commentedThe sizes I've mentioned were only for the table browscap.
If there's nothing that "can or should do about that as a module", I suppose I should create a DB script to be run periodically? I have no idea how to proceed for such thing, do you have a tip?
Comment #12
gregglesWhat makes this truly a problem you want to solve?
I guess you could do this query periodically:
delete from browscap where data not like '%s:7:"crawler";s:1:"1";%';
That query deletes all non-crawlers. If all you care about is identifying crawlers you should have the data you need.
Comment #13
dynv commentedI use a free host and if for whatever I get over any limit, it get parked for several days and people see ads for their services instead of my plain (boring) homepage ; also at the time of the OP, the table was 9Mb, that's why it was critical. O_O
I need the opposite data, so to only delete crawler data.