This commit introduces a new file, AUDIT-MEMORY.md, which contains a detailed audit of the application's memory and resource management. The audit covers several key areas, including: - Goroutine lifecycle management - In-memory data structures and potential leaks - Database resource usage and connection pooling - Process and file handle management for external miners - Network connection handling for the API server The report identifies a potential issue with the unbounded growth of the `miner_sessions` table and recommends adding a cleanup mechanism. Other areas were found to be robust and well-managed. Co-authored-by: Snider <631881+Snider@users.noreply.github.com>
4.5 KiB
Memory and Resource Management Audit
This audit examines the application's memory and resource management based on a review of the codebase, with a focus on pkg/mining/manager.go, pkg/mining/service.go, and pkg/database/database.go.
1. Goroutine Leak Analysis
The application uses several long-running goroutines for background tasks. Overall, goroutine lifecycle management is robust, but there are minor areas for improvement.
Findings:
- Stats Collection (
manager.go): ThestartStatsCollectiongoroutine runs in aforloop with atime.Ticker. It reliably terminates when thestopChanis closed duringManager.Stop(). - Database Cleanup (
manager.go): ThestartDBCleanupgoroutine also uses atime.Tickerand correctly listens for thestopChansignal, ensuring it exits cleanly. - WebSocket Event Hub (
service.go): TheEventHub.Runmethod is launched as a goroutine and manages client connections. It terminates when its internalquitchannel is closed, which is triggered by theEventHub.Stop()method.
Recommendations:
- No major issues found. The use of
stopChanandsync.WaitGroupinManagerprovides a solid foundation for graceful shutdowns.
2. Memory Leak Analysis
The primary areas of concern for memory leaks are in-memory data structures that could grow indefinitely.
Findings:
Manager.minersMap: Theminersmap in theManagerstruct stores active miner processes. Entries are added inStartMinerand removed inStopMinerandUninstallMiner. If a miner process were to crash or become unresponsive withoutStopMinerbeing called, its entry would persist in the map, causing a minor memory leak.- In-Memory Hashrate History: Each miner maintains an in-memory
HashrateHistory. TheReduceHashrateHistorymethod is called periodically to trim this data, preventing unbounded growth. This is a good practice. - Request Body Size Limit: The
service.gofile correctly implements a 1MB request body size limit, which helps prevent memory exhaustion from large API requests.
Recommendations:
- Implement a health check for miners. A periodic health check could detect unresponsive miner processes and trigger their removal from the
minersmap, preventing memory leaks from orphaned entries.
3. Database Resource Management
The application uses an SQLite database for persisting historical data.
Findings:
- Connection Pooling: The
database.gofile configures the connection pool withSetMaxOpenConns(1). This is appropriate for SQLite's single-writer model and prevents connection-related issues. hashrate_historyCleanup: TheCleanupfunction indatabase.gocorrectly removes old records from thehashrate_historytable based on the configured retention period.miner_sessionsTable: Theminer_sessionstable tracks miner uptime but has no corresponding cleanup mechanism. This table will grow indefinitely, leading to a gradual increase in database size and a potential performance degradation over time.
Recommendations:
- Add a cleanup mechanism for
miner_sessions. Extend theCleanupfunction to also remove old records from theminer_sessionstable based on the retention period.
4. File Handle and Process Management
The application manages external miner processes, which requires careful handling of file descriptors and process handles.
Findings:
- Process Lifecycle: The
Stopmethod on miner implementations (xmrig.go,ttminer.go) is responsible for terminating theexec.Cmdprocess. This appears to be handled correctly. - I/O Pipes: The miner's
stdout,stderr, andstdinpipes are created and managed. The code does not show any obvious leaks of these file handles.
Recommendations:
- No major issues found. The process management logic appears to be sound.
5. Network Connection Handling
The application's API server and WebSocket endpoint are critical areas for resource management.
Findings:
- HTTP Server Timeouts: The
service.gofile correctly configuresReadTimeout,WriteTimeout, andIdleTimeoutfor the HTTP server, which is a best practice for preventing slow client attacks and connection exhaustion. - WebSocket Connections: The
wsUpgraderhas aCheckOriginfunction that restricts connections tolocalhostorigins, providing a layer of security. TheEventHubmanages the lifecycle of WebSocket connections.
Recommendations:
- No major issues found. The network connection handling is well-configured.