-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The HISTORY_RETENTION_COUNT parameter has no effect #5299
Comments
@airstring , there is a time limit interval imposed on the reaper, it will only run once every hour per this config: I'm wondering if this observation was in the timeframe of first hour after starting horizon, if so, the reaper would not have ran yet. Can you check the logs and/or db related to this horizon instance after it has been running at least one hour with this retention config and then recheck logs for lines with |
I'm sure I've been watching for a week now and there are no reaper keywords in the logs.
Of course, the block synchronization is normal.
|
I ran horizon 2.30.0 locally with similar reap config to replicate on testnet:
this was on an initially empty db, the first reaper cycle appeard 5 hrs after start:
can you grep the log for |
1.file /etc/default/stellar-horizon contents are as follows
2.Log as follows:
3.The active sql in the database is as follows:
|
can you confirm how |
vim /lib/systemd/system/stellar-horizon.service
vim /etc/default/stellar-horizon
@sreuland The /etc/default/stell-horizon file must be in effect, otherwise stell-horizon won't connect to the postgres database. Replenishment
One hour later, reap appeared in the log
But how do you solve this timeout problem? |
@airstring , first, can you confirm that the environment variables for the running horizon process is getting the latest from /etc/default/stellar-horizon, you can dump the initial env variables of the pid:
does it have the RETENTION settings? on the reap timeouts, the first approach could be to decrease the reap batch size, can you try if that doesn't work, an alternate approach for now would be to increase we may need to raise a bug ticket on the reap sql timeouts, ideally those shouldn't be happening. |
Hello @airstring , we have created a bug ticket to investigate the reaper performance issue similar as what you observed - #5320, if you don't mind, could you post your horizon system compute specs on #5320, such as:
thanks! |
@sreuland Thank you, you helped me solve the problem. Now reap is done automatically every hour. |
Hello @airstring @sreuland I'm getting the same issue on the latest Thanks. |
What version are you using?
root@ip-xxx:/data/xlm# bin/stellar-horizon version
2.30.0-17e1acc6ba990b62b3c364a30ad9d866e562c56e
go1.22.2
What did you do?
xlm's data was growing so fast that I wanted it to automatically prune history blocks.
I added two lines to the file /etc/default/stellar-horizon, as shown below:
What did you expect to see?
1.horizon's log file should have the reaper keyword
2.Disk space should not continue to grow
What did you see instead?
1.horizon's log files don't have the reaper keyword
2.Disk space continues to grow
The text was updated successfully, but these errors were encountered: