-
-
Notifications
You must be signed in to change notification settings - Fork 112
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
Old deploys take up way heaps of space #899
Comments
When I go back to old releases then it's mostly for log files to see what happened two weeks ago. So we could think of storing them centrally with logrotate. Keeping node modules centrally has the advantage of a quicker installation process because we don't need to duplicate all of them. But pruning is a challenge. If we just prune according to the current deploy then we lose the backup of the old releases. Or are the installation packages cached independently? |
Good point about logs, we should consider storing them centrally. For node_modules, I'm not sure if there's a global local cache (that would be a good idea). I had assumed it was copied from the previous release but I now see that's not the case. If it's not cached we should do something about that to speed up deploys. But in any case, I reckon just reducing the number of old releases is simple and would be ok. How about the last 4 releases (that should cover almost a month of logs)? |
Yes, good idea. We may do more deploys when something goes wrong and then we lose logs but that's a different issue.
We could also copy the previous release, install and prune if we don't have another cache. |
Silly me I mustn't have been looking closely when I first wrote this. There are ten things in the ofn-admin@prod3:/home/openfoodnetwork/apps/openfoodnetwork/releases-old$ ls -1tr
2024-06-10-231508
2024-06-10-231508.sql.gz
2024-06-18-003347
2024-06-18-003347.sql.gz
2024-06-19-055150
2024-06-19-055150.sql.gz
2024-06-25-051021
2024-06-25-051021.sql.gz
2024-07-02-043842
2024-07-02-043842.sql.gz
2024-07-09-043115 # <-- current release The logic is here, and takes a bit of explanation..
This deletes the one oldest file/dir
This doesn't seem quite right, I think it means we delete the SQL or dir on alternating weeks. So it keeps about 4.5 old releases, not five. We should change that number to 9. But it will only make a small difference on disk usage... |
So I think the focus should be on
I think re-using For
|
Description
We store the last 5 deploys on a server in the
releases-old
folder, but this can take up lots of space. (note that the current release is also in this directory).The majority of the space used is from
node_modules
, currently 260mb (therefore 1.3gb used).Logs also take up a bit.
Expected Behavior
There shouldn't be too much space used up
Actual Behaviour
Jul 2024:
6.3 GiB
Severity
Possible Fix
Perhaps
node_modules
could be linked to a single shared folder (I think assets might be set up like this?).But I think we can simply just store less old releases. I don't think we ever really refer to them.
The text was updated successfully, but these errors were encountered: