What the data for this category looks like
Data sources for pulp and paper production ledgers include wood pulp and waste paper batches, DCS/QCS systems, on-paper machine measurement devices, laboratory testing systems, energy and water treatment systems. Daily generated documents include stock preparation sheets, beating records, paper machine operation logs, online quality curves, laboratory reports, sheet break and product change records. Data update frequencies cover three levels: real-time, per shift, per roll. Fields include material batch numbers, operation parameters, quality indicators, energy consumption values, and some documents include visual curves and structured tables. This category focuses on high-speed continuous web production. Data quality distribution across horizontal and vertical dimensions and sheet break events have significant production impacts. This differs from printing and packaging, which uses finished paper for graphic and structural processing.
What constraints these characteristics impose on deployment and upgrade
Multi-source cross-system data access requires adapting to multiple types of access configurations during deployment, to avoid connection timeouts or resource exhaustion. Real-time paper machine operation data requires sufficient cache and database connection pool capacity. During upgrades, non-core synchronization tasks must be paused to prevent production anomalies caused by data loss. Multiple document types include large-volume curves and structured tables. Storage configurations must support reading and writing different file formats. During upgrades, storage node compatibility must be verified. Incorrect configurations may cause production issues such as roll downgrading or sheet break downtime. Deployments must be strictly matched to business data characteristics.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
DB_MAX_LINK | 200–300 | Pulp and paper production ledgers include real-time, per-shift, per-roll high-frequency data. Multi-source access requires sufficient connection pools to handle concurrent requests |
MONGODB_URI | Private intranet network address | Production ledgers include sensitive data such as online quality and energy consumption. Intranet isolation is required to ensure data security |
REDIS_URL | Intranet Redis address for port 6379 | Real-time paper machine operation status and sheet break events must be cached to reduce high-frequency read/write pressure on the database |
STORAGE_S3_ENDPOINT | Local object storage node address | Large-volume files such as online quality curves and laboratory reports must be stored locally to ensure reading speed |
FILE_TOKEN_KEY | Random string calibrated through actual testing | Ensures signature security for file upload and download, preventing unauthorized access |
FE_DOMAIN | Enterprise intranet domain name | Limits front-end access scope, adapting to the intranet deployment scenario of pulp and paper enterprises |
Three common mistakes
- Symptom: An error
Failed to create post presigned urlis displayed when uploading stock preparation sheets or online quality curves. Cause: After upgrading to FastGPT v4.17.0, valid parameters forSTORAGE_S3_ENDPOINTorFILE_TOKEN_KEYwere not reconfigured. - Symptom: The version of the deployed code cannot be confirmed. Cause: The version identifier in the version file in the deployment directory was not checked, and an unverified code package was used directly.
- Symptom: Container startup fails on the arm architecture Galaxy Kylin Linux system. Cause: The FastGPT image adapted for the arm architecture was not used, or
PG_URLwas not configured to point to a compatible database instance.
How to confirm the configuration is correct
- Run the built-in database connection test tool to verify whether the connection pool configured by
DB_MAX_LINKcan normally handle multi-source data synchronization requests. - Upload a paper machine operation log file to confirm that the pre-signed URL can be generated normally and the download process is completed.
- Check Redis monitoring indicators to confirm that the read/write latency of real-time data caching meets the threshold requirements adjusted for the business.
- Check the version file in the deployment directory to confirm that it matches the target upgrade version.
The values provided are common starting points and should be measured against the reader's own samples.