Debian环境下Node.js应用的常见性能瓶颈及分析
Node.js通过libuv线程池处理异步I/O操作（如文件读写、数据库查询、DNS解析）。在Debian系统中，默认线程池大小为4（可通过UV_THREADPOOL_SIZE环境变量调整），当面临大量并发请求或长时间I/O操作（如慢查询、大文件读取）时，线程池易被占满，导致新请求被阻塞，无法及时响应。这种情况下，系统会表现出高并发下响应延迟骤增、吞吐量下降。
尽管Node.js采用非阻塞I/O模型，但同步I/O API（如fs.readFileSync、child_process.spawnSync）或未优化的异步操作（如未使用Promise.all并行处理多个异步任务）会阻塞事件循环。例如，在Debian服务器上处理大文件上传时，若使用同步读取方式，会导致事件循环停滞，后续请求无法被处理。
Node.js是单线程的，CPU密集型任务（如复杂算法计算、大数据量排序、图像/视频处理）会独占主线程，导致事件循环无法处理其他请求。在Debian环境中，若应用需要处理高频的数学运算或数据转换，CPU使用率会飙升，进而引发请求延迟、超时报错。
未正确释放的内存（如未清除的定时器、全局变量缓存、闭包引用的对象）会导致内存泄漏，随着运行时间延长，内存占用持续增长。Debian系统中的Node.js应用在内存耗尽时，会触发垃圾回收（GC），GC过程会暂停应用执行（Stop-The-World），导致响应延迟甚至崩溃。通过process.memoryUsage()可观察到heapUsed持续增长且不被回收。
数据库查询是Node.js应用的常见I/O操作，慢查询（未优化索引、复杂JOIN语句、全表扫描）、连接池不足（如pg-pool或mysql2连接池大小设置过小）会导致数据库响应延迟，进而阻塞事件循环。在Debian系统中，数据库与应用通常部署在同一服务器或内网，网络延迟较低，但数据库自身性能问题仍会影响整体响应速度。
高并发场景下，TCP连接数限制（如net.core.somaxconn默认值较小）、端口耗尽（客户端端口范围有限）会导致连接建立失败或延迟。此外，未使用HTTP/2或多路复用技术会增加TCP连接开销，降低网络传输效率。Debian系统中的默认内核参数可能不适合高并发应用，需调整以提升网络性能。
Node.js默认是单进程模型，无法直接利用Debian服务器的多核CPU资源。若应用未使用Cluster模块（如cluster.fork()创建子进程）或PM2的集群模式（pm2 start -i max），会导致CPU核心闲置，无法提升整体吞吐量。
