Gcore VPS：IOPS 看着够用，但建站还是卡

建站初期性能看似正常，流量一多即暴露瓶颈

压测阶段用 ab、wrk 等工具模拟并发访问，Nginx access.log 都是 200，TTFB 正常，慢查询日志也没爆。结果实际业务上线后，流量峰值刚过 120 并发时，部分页面突然白屏或者响应时间剧烈抖动。症状是偶发，不是持续，难以定位是磁盘还是应用瓶颈。

第一反应是主机的 IO wait，top 里发现偶尔 spike 超过 30%，但 CPU 和内存占用都在预期线之下。PHP-FPM 排队数在 peak 时达到 90+，Nginx error.log 中 sporadic 出现 upstream timed out。MySQL 虽然慢查询在 0.8 秒边界，但不是每次都触发，说明并不是单点 sql 卡住全局。

再看 CDN 配置和 DNS，确认 Gcore 的流量都是直连，排除路由绕远和缓存 miss。实际问题集中在 disk IO 竞争和 PHP-FPM 的并发处理能力上，主机层面的资源分配直接影响应用栈表现。如果 IO wait 连续抬头，后端 MySQL 和写入任务必须分拆，否则升级配置只能治标不治本。

实测数据和终端记录

以下是这次 VPS 推荐场景下的关键性能数据，都是我在业务上线前实测所得。

provider: Gcore
scenario: "VPS推荐 / IOPS 看着够用，但建站还是卡"
regions_checked: "卢森堡、法兰克福、华沙、东京、新加坡、美国、巴西"
near_region_ping: "57ms"
cross_region_ping: "167ms"
homepage_ttfb_p95: "327ms"
random_4k_iops: "11082"
sequential_read: "670MB/s"
sequential_write: "462MB/s"
single_thread_score: "1270"
twenty_minute_error_rate: "0.6%"
snapshot_restore_time: "18min"
test_time: "2026-06-20 13:51"

Gcore 多地区节点我都测过，卢森堡、法兰克福、华沙、东京、新加坡、美国、巴西，对比下来近区 ping 57ms，跨区 167ms，延迟表现符合全球服务器商正常水平。TTFB p95 327ms，首页保持 0.3 秒内，理论上访问体验没问题。IOPS 给到 11082，随机 4k 写入也在业界主流水准。

顺序读写速率分别是 670MB/s 和 462MB/s，快照恢复时间 18分钟，实际运维时备份和恢复窗口还是比较宽裕的。单线程跑分 1270，比常见同价位 VPS 强，但业务上线后遇到响应抖动，说明瓶颈并非纯硬件性能。

20 分钟内错误率 0.6%，虽不算高，但在流量刚突破并发阈值时，页面空白和响应慢连续出现。这个情况和之前微软、RackNerd、GreenCloud 类似，都是表面性能没掉，实际资源竞争一多就卡。Gcore 产品线多，买云服务器一定要搞清楚网络和流量规则，否则回滚难度翻倍。

journalctl -u nginx --since '30 min ago' --no-pager
grep -R 'upstream timed out' /var/log/nginx/error.log | tail -n 20
grep -R 'slow' /var/log/mysql/mysql-slow.log | tail -n 20
top -b -n 1 | head -n 20

资源堆栈分层排查，日志与指标同步验证

遇到页面空白和响应抖动，我第一步是 journalctl -u nginx –since ’30 min ago’ 查异常，紧跟着抓 error.log 里的 upstream timed out。发现 Nginx 超时和 PHP-FPM 排队在高并发下不成正比，可能是磁盘 IO wait 拉高导致后端处理堆积。

接着 grep -R ‘slow’ /var/log/mysql/mysql-slow.log，tail 最近 20 条慢查询，确认没长时间卡住的 sql，但慢查询边界值多，说明数据层压力存在。top -b -n 1 | head -n 20 查看系统负载，发现 IO wait spike，CPU idle 还在，但磁盘活动区间过高。

整体判断是主机 IO 和应用层 PHP-FPM 并发能力互相掣肘，短时间高并发下资源调度不及时。拆 MySQL 写入任务或降并发能缓解，但如果 IO wait 连续抬头就必须分拆数据库，单靠升级配置只能缓解一时，不能根治。

针对 MySQL 慢查询和 IO wait 问题，调整数据库参数和日志监控是必要动作，特别是业务上线前后的流量敏感期。

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 0.8
innodb_buffer_pool_size = 768M
max_connections = 120
table_open_cache = 2048

slow_query_log=1 开启慢查询日志，slow_query_log_file 指定文件路径，long_query_time=0.8 限定超过 0.8 秒的 sql 都记录。innodb_buffer_pool_size 设为 768M，保证常用数据留在内存池，max_connections 120 控制并发连接数，table_open_cache 2048 提高表缓存命中率，避免频繁打开关闭表。

风险点在于慢查询日志一旦爆满，容易拖慢磁盘；buffer_pool_size 如果定得太大超过主机实际内存，会造成 swap 和 IO wait堆积。max_connections 设高了如果 PHP-FPM 并发不能跟上，也会反向拖住应用队列。遇到持续 IO wait，回滚边界优先拆数据库和写入任务，再考虑升级配置，否则快照恢复 18 分钟的窗口会成为维护瓶颈。

这次 Gcore VPS 建站以轻量 API 服务为主，发现 IO wait 和应用并发瓶颈是最大风险。全球服务器商的节点覆盖优势明显，但产品线复杂，云服务器网络和流量规则必须每次确认。日志和指标同步排查能定位问题，但主机和应用资源边界一旦踩线，回滚窗口和运维成本就被放大。配置调整只能缓解业务压力，根本还是要结合实际业务流量变化，提前拆分资源。