DigitalOcean的Droplet产品线里，1核CPU加1GB内存是最低一档，每月6美元的价格让不少个人开发者心动。但“1核1G”这种配置在今天这个动辄8核起步的时代到底还有没有实用价值？为了回答这个问题，我创建了一台全新的基础型Droplet，数据中心选在旧金山，系统镜像使用Ubuntu 22.04 LTS，然后从硬件识别、CPU算力、内存吞吐、磁盘IO到网络延迟做了一轮完整测试。下面把过程和结果完整记录，给正在选型的朋友一个参考。
硬件识别与系统初始状态
启动实例后先用lscpu和free -h确认实际分配的资源。输出显示CPU型号被虚拟化为“DO-Regular”，主频2.0GHz，缓存大小未完全暴露，但通过/proc/cpuinfo可以看到这是一颗Intel Xeon Platinum 8259CL的虚拟核心。内存方面，系统识别到985MB总量，因为内核和基础服务占用了约15MB，可用内存在830MB左右。磁盘是一块25GB的SSD，挂载在根分区，文件系统为ext4。
值得注意的是，Droplet的1核vCPU并不是独占物理核心，而是与其他用户共享宿主机的CPU时间片。DigitalOcean在控制面板里明确标注了“Shared vCPU”字样，这意味着当宿主机上的其他实例突发高负载时，你的可用CPU时间可能会被挤占。实际测试中通过top观察，空闲时CPU steal时间基本为0，但在跑满负载的压测阶段，steal值偶尔会跳到3%到5%，属于可接受范围。内存虽然只有1GB，但默认没有开启swap分区，这会导致内存耗尽时直接触发OOM killer，后面会专门测试内存极限。
CPU单核性能与多任务能力
单核性能用sysbench cpu --cpu-max-prime=20000 run测试，事件总耗时约31.7秒，折算下来单核每秒能处理约630个事件。作为对比，一台本地笔记本上的i5-8250U单核跑同样参数大约需要24秒，也就是说这颗虚拟CPU的单核性能大约是真物理核心的75%到80%。对于编译小型项目、运行Python脚本或者处理HTTP请求来说，这个算力完全足够。
# 单核素数计算测试 sysbench cpu --cpu-max-prime=20000 --threads=1 run # 输出摘要 # total time: 31.7213s # events per second: 630.23
因为只有1个vCPU，多线程并行的意义不大，但为了观察调度行为，我还是跑了sysbench cpu --threads=4。结果四个线程的总吞吐量只比单线程提升了约8%，说明虚拟化层面做了严格的CPU配额限制，不会因为超线程而额外获得算力。这也意味着在单核实例上，任何依赖多核并发的应用（如gzip压缩、视频转码）性能都不会理想，必须靠单核硬扛。
内存带宽与OOM风险实测
内存带宽使用sysbench memory --memory-block-size=1M --memory-total-size=10G run测试，写速度约4.2GB/s，读速度约5.1GB/s。这个数字与同价位其他云厂商的入门实例基本持平，满足Web应用和数据库缓存的读写需求没有问题。不过由于总量只有1GB，系统在高负载下很容易碰到内存上限。
我专门做了一个OOM触发实验：用stress-ng --vm 1 --vm-bytes 900M --timeout 30s模拟一个进程申请900MB内存。结果在第22秒时，内核的OOM killer直接杀掉了这个stress进程，系统日志里出现Out of memory: Killed process记录。这正是因为没有swap分区导致的——内存一旦耗尽就直接杀进程，没有任何回旋余地。对于生产环境来说，建议手动创建一个1GB到2GB的swap文件作为缓冲，命令如下：
# 创建swap文件并启用 fallocate -l 1G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 写入/etc/fstab持久化 echo '/swapfile none swap sw 0 0' >> /etc/fstab
加完swap之后再次跑同样的压力测试，系统没有出现OOM，但响应速度明显变慢，因为大量数据开始交换到磁盘。这说明1GB内存的实例在遇到内存尖峰时，swap能救命但会拖累性能，最实际的方案还是从应用层面控制内存占用，比如调整PHP-FPM的pm.max_children数量、给MySQL设置合理的innodb_buffer_pool_size。
磁盘IO性能与吞吐稳定性
磁盘基准用fio做随机读写和顺序读写测试。随机4KB单队列深度32的写入IOPS约为8500，读取IOPS约为11500，顺序1MB块大小的读写吞吐分别是420MB/s和380MB/s。这个成绩在入门级云盘中算中等偏上，比AWS Lightsail同价位实例的磁盘表现要好一些，但和高端NVMe云盘相比差距明显。
# 随机4KB写入测试
fio --name=randwrite --ioengine=libaio --iodepth=32 --rw=randwrite \
--bs=4k --size=1G --numjobs=1 --runtime=60 --time_based \
--filename=/root/fio_test
# 关键结果：write IOPS=8523, lat=3.74ms
测试过程中注意到一个细节：磁盘性能在前30秒非常稳定，但当宿主机上其他实例同时进行IO操作时，延迟会从3ms左右突然飙升到15ms以上，出现明显的抖动。这属于共享存储的典型特征，如果你的应用对磁盘延迟敏感（比如实时日志写入、数据库事务），建议在DigitalOcean上选择更高规格的实例或者使用专门的块存储卷，独立卷的IOPS是单独结算的，不会被其他租户影响。
网络性能与跨区域延迟
网络吞吐使用iperf3在实例和另一台同区域Droplet之间打流，TCP单线程下载稳定在95Mbps到105Mbps之间，上传类似，基本符合DigitalOcean标注的1Gbps虚拟网卡在共享带宽下的实际表现。跨区域到纽约数据中心的延迟约为70ms，到欧洲法兰克福约140ms，到新加坡约190ms，这些数字比较常规，没有出现异常丢包。
我还测试了公网出方向的限速情况。从实例上用curl下载一个100MB的文件，平均速度稳定在11MB/s到12MB/s，换算下来就是90Mbps左右。这个带宽对于个人博客和API服务绰绰有余，但如果你打算用它做媒体文件下载站或者图床，流量一大就会碰到网络瓶颈。DigitalOcean的流量是按出站方向计算的，1核1G实例每月包含1TB免费流量，超额后每GB收费0.01美元，这个价格相对合理。
实际应用部署：Nginx + PHP + SQLite压测
为了验证真实负载能力，我在实例上部署了Nginx 1.18、PHP-FPM 8.1和SQLite，跑了一个简单的动态页面：每次请求会从SQLite读取一条随机记录并返回JSON。用wrk在本地另一台机器上以10线程、100并发连接压测这个页面，持续30秒。结果QPS平均在420左右，P99延迟约260ms，CPU使用率稳定在85%到90%，没有出现请求超时。
# wrk压测命令 wrk -t10 -c100 -d30s --latency http://YOUR_DROPLET_IP/index.php # 结果摘要 # Requests/sec: 421.18 # Latency: 235.67ms (p99 268.11ms)
把SQLite换成MySQL 8.0之后，同样的页面QPS掉到了310左右，因为MySQL的查询开销更大，而且1GB内存里要同时容纳Nginx、PHP-FPM和MySQL三个进程，留给数据库缓冲池的空间非常紧张。这说明1核1G的实例不适合跑关系型数据库，更推荐使用SQLite或者把数据库放到外部托管的RDS服务上。对于纯静态站点，Nginx单独服务HTML文件的QPS可以跑到1800以上，说明CPU在处理静态文件时还有余力。
稳定性观察与长期运行建议
压测结束后，我让实例持续运行了72小时，期间用脚本每分钟记录一次CPU负载、内存用量和磁盘IO等待。观察发现，在没有外部流量时CPU空闲率保持在98%以上，内存稳定在420MB左右，系统没有任何异常重启或内核报错。这说明基础型Droplet在长期空载下的稳定性是可靠的，适合放在那里当一台始终在线的轻量服务器角色。
但有一个隐藏风险需要注意：DigitalOcean会对长期闲置的实例做维护迁移，有时会触发重启。如果你部署了需要持久化状态的应用（比如有状态容器、内存缓存），务必配置开机自启和状态持久化。另外，1核1G实例不支持自动扩展，流量突增时只能靠横向扩展加实例，而Droplet的负载均衡器起步价是每月10美元，对个人用户来说成本偏高。更实际的做法是用Cloudflare做前置CDN，把静态资源缓存出去，减轻源站压力。
综合所有测试结果，DigitalOcean 1核1G Droplet是一台定位清晰的入门云主机。它能稳定承载日访问量在5000到10000 PV的小型网站、个人API、定时任务、反向代理或者开发测试环境，但面对数据库密集型应用、高并发实时服务或者大内存计算任务时明显力不从心。如果你刚开始接触云服务或者需要一个便宜的境外节点，这个配置值得入手；如果预算允许加4美元升级到2核2G，整体体验会有质的提升。
DigitalOceanDroplet云服务器评测修改时间：2026-09-26 11:41:08