Operations SIG 18 Nov 2024: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
* Created a [https://github.com/vilkris4/go-zenon/tree/feature/release_db_references branch] in which the database references are explicitly released. Commit message for context: | * Created a [https://github.com/vilkris4/go-zenon/tree/feature/release_db_references branch] in which the database references are explicitly released. Commit message for context: | ||
** <code>This commit introduces explicit releasing of database handles. The LevelDB package relies on the Go GC to cleanup unused snapshot references, but many other database packages require snapshots to be released explicitly. These changes serve as a starting point for assessing the usage of alternative databases.</code> | ** <code>This commit introduces explicit releasing of database handles. The LevelDB package relies on the Go GC to cleanup unused snapshot references, but many other database packages require snapshots to be released explicitly. These changes serve as a starting point for assessing the usage of alternative databases.</code> | ||
* Releasing the DB references manually provides no apparent improvement in performance - possibly a negative effect in performance. Would need more testing to determine the effect. Overall the task of manually managing the references is very tedious and as can be seen from the amount of changes done in the branch, it is not a trivial change and affects a vast portion of the codebase. | * Releasing the DB references manually provides no apparent improvement in performance - possibly a negative effect in performance. Would need more testing to determine the effect. | ||
* Overall the task of manually managing the references is very tedious and as can be seen from the amount of changes done in the branch, it is not a trivial change and affects a vast portion of the codebase. | |||
* Based on personal testing and anecdotal evidence from others the recommended approach for syncing a node from scratch on a VPS with non-dedicated resources should be to first sync the node on a local machine and then transfer the node's database to the server. | * Based on personal testing and anecdotal evidence from others the recommended approach for syncing a node from scratch on a VPS with non-dedicated resources should be to first sync the node on a local machine and then transfer the node's database to the server. | ||
* Syncing a node locally on my machine only takes around 13 hours, while on a VPS with shared resources it can take over a week. This would suggest that LevelDB is not the main culprit for the slow sync, raising into question how much time should be spent on investigating the replacement of LevelDB right now. | * Syncing a node locally on my machine only takes around 13 hours, while on a VPS with shared resources it can take over a week. This would suggest that LevelDB is not the main culprit for the slow sync, raising into question how much time should be spent on investigating the replacement of LevelDB right now. | ||
== Meeting Minutes Summary (ChatGPT) == | == Meeting Minutes Summary (ChatGPT) == | ||
Revision as of 10:52, 18 November 2024
Agenda
What: Meeting to Discuss Improving Node Operations as part of the HC1: OP SIG
When: 18 Nov 2024 @ 8 CET EST
Where: https://matrix.to/#/#sig-op:hc1.chat
Chair: 0x3639
Agenda:
- Discuss follow Up items from previous meeting
- Document action items
- Establish next meeting
If you want to attend please respond (or DM) with your full matrix username and I will invite you to the group. No FUD, anger or BS allowed.
Pre-meeting Notes
- Created a branch in which the database references are explicitly released. Commit message for context:
This commit introduces explicit releasing of database handles. The LevelDB package relies on the Go GC to cleanup unused snapshot references, but many other database packages require snapshots to be released explicitly. These changes serve as a starting point for assessing the usage of alternative databases.
- Releasing the DB references manually provides no apparent improvement in performance - possibly a negative effect in performance. Would need more testing to determine the effect.
- Overall the task of manually managing the references is very tedious and as can be seen from the amount of changes done in the branch, it is not a trivial change and affects a vast portion of the codebase.
- Based on personal testing and anecdotal evidence from others the recommended approach for syncing a node from scratch on a VPS with non-dedicated resources should be to first sync the node on a local machine and then transfer the node's database to the server.
- Syncing a node locally on my machine only takes around 13 hours, while on a VPS with shared resources it can take over a week. This would suggest that LevelDB is not the main culprit for the slow sync, raising into question how much time should be spent on investigating the replacement of LevelDB right now.