How long is the data about old WU's retained?

[ETA_2025]

How long is the data about old WU's, including those credited, dumped, failed, pause(d) or rejected retained?

I've got 26 days worth of data, which is how long 8.4.9 has been installed on my various machines.

Will it be purged at some stage, or will I need to do that manually if so desired?

[daiko]

I'm seeing 167 days worth of work under my Units tab, less than 6MB of log files.
So that would be about 12MB/year for this CPU WUs-only machine. So I’m not too concerned personally, but if you’re doing GPU work, I could see this eventually becoming a problem?

[muziqaz]

The limit is hard set to 500 entries per machine. I tried negotiating for more, no luck, since after 500 entries in the db file performance degrades considerably, I am told.
This is about the v8 Work Units section

[ETA_2025]

The limit is hard set to 500 entries per machine.

Thanks muziqaz

[rbpeake]

Is there a way to delete the data on old work units before 500? Does it affect processing time?

Thanks.

[muziqaz]

Is there a way to delete the data on old work units before 500? Does it affect processing time?

Thanks.

No, and no

[whocrazy]

When FAH isn't running, you can try running a vacuum operation on the client.db file. sqlite3 client.db vacuum.

[muziqaz]

When FAH isn't running, you can try running a vacuum operation on the client.db file. sqlite3 client.db vacuum.

Let's not suggest these type of operations, please

[arisu]

When FAH isn't running, you can try running a vacuum operation on the client.db file. sqlite3 client.db vacuum.

Let's not suggest these type of operations, please

What would go wrong with a vacuum operation? Unless I am mistaken about sqlite3, the only time a vacuum operation can go wrong is if the database is already seriously corrupted (it would just make it worse although that could be said for any write operation).

[muziqaz]

Let's not suggest outside actions to the files run by fahclient. Period.

[arisu]

It's a regular sqlite3 database, whether or not recommending doing things is a good idea in general, vacuum should be a safe operation.

Is your recommendation just a matter of leaving things alone because some people may not understand which operations are safe and which are not? Since it can grow pretty large, I might add a ticket to the tracker to add the auto_vacuum pragma to the database.

[calxalot]

There is already a ticket suggesting vacuum
It is old. Someone should probably offer a PR.
I think it would be a one line fix to add the pragma auto.

https://github.com/FoldingAtHome/fah-cl ... issues/123

[calxalot]

https://github.com/FoldingAtHome/fah-cl ... nt/App.cpp

I think in App::run()

[muziqaz]

It's a regular sqlite3 database, whether or not recommending doing things is a good idea in general, vacuum should be a safe operation.

Is your recommendation just a matter of leaving things alone because some people may not understand which operations are safe and which are not? Since it can grow pretty large, I might add a ticket to the tracker to add the auto_vacuum pragma to the database.

The reason I'm saying that is that regular people use this forum, not fah Devs, with some exceptions. So you might know what you are doing, but there might be some people who think that your suggestion is a solution, and use it, and break things, however unlikely the breakdown might be. And then we have to listen and troubleshoot those people's problems.
Any low level suggestions should be done in GitHub. Dev resides there and you will get most attention to your suggestions.
The deletion of dumped, crashed WUs have been already suggested in GitHub few times. Latest one might have even been mine.