云服务器到手之后：从"能连上"到"能跑活"，中间隔着几步

很多人买完云服务器，第一件事是 SSH 上去敲个 ls，确认机器活着，然后就不知道下一步该干什么了。这很正常。云服务器本质上就是一台远端的 Linux 主机，控制台给你的是一个干净的系统，剩下的东西——环境、参数、安全、磁盘——都需要自己动手。

这篇不聊选型，也不比价格，就聊一台云服务器从开通到真正能承载业务，中间那几步容易卡住的地方。顺带拿芯飞云华北节点的一台 8C16G 实例做操作示例，配置是 8 核 16G、50G 系统盘、10M 带宽。选它当例子原因很简单：这台机器的规格在中小业务里比较典型，1:2 的 CPU 内存配比意味着 CPU 和内存不容易出现一边闲一边满的情况，聊参数调优的时候有参照意义。

第一步：安全组没放行，SSH 连不上是正常的

新买的机器，第一反应是拿 SSH 连。连不上，很多人第一反应是"机器坏了"。大概率不是。

芯飞云的安全组默认策略是拒绝所有外部访问，22 端口也不例外。这个设计从安全角度是合理的——机器开出来不会在几分钟内被扫描爆破——但对第一次用的人确实容易卡住。进控制台，找到安全组，加一条入方向规则：协议 TCP，端口 22，源 IP 填你自己的公网 IP（不要图省事填 0.0.0.0/0）。规则生效有几十秒的延迟，等一会儿再连。

连上之后，第一件事不是装软件，是把 SSH 的密码登录关掉。用密钥比用密码安全一个量级，而且配置一次就一劳永逸。本地已经有密钥的话，直接推上去：

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<你的实例IP>

然后编辑服务器上的 /etc/ssh/sshd_config：

PasswordAuthentication no
PermitRootLogin prohibit-password

重启 sshd 之前，另开一个终端窗口保持当前连接不要断，用新窗口测试密钥登录是否正常。确认能登了，再回去重启 sshd。这个习惯能救命——如果配置写错了，你至少还有一个活着的会话可以改回来。

第二步：你的 8 核，可能只用上了 1 核

系统装好了，环境也搭了，MySQL 和 Nginx 都跑起来了。然后呢？默认配置下，8 核 16G 的性能可能连一半都没发挥出来。

拿 Nginx 来说，默认 worker_processes 是 1。你买了 8 核，Nginx 只用一个核在处理连接。改成 auto：

worker_processes auto;
worker_connections 10240;

worker_connections 默认 512，对于一个稍微有点流量的站点来说太保守了。调到一万左右，配合 auto 的进程数，整机的并发处理能力才对得起那个 CPU 规格。

MySQL 的问题更典型。innodb_buffer_pool_size 默认值是 128M。在 16G 内存的机器上，这个值意味着 InnoDB 只用了不到 1% 的内存来做缓存，剩下的 15G 多闲着。对于一台主要跑数据库或混合负载的机器，这个参数设到物理内存的 50% 到 70% 是更合理的起点：

-- 在 my.cnf 的 [mysqld] 段落下添加
innodb_buffer_pool_size = 8G

别照搬这个数字，得看你机器上还跑了什么。如果同一台机器上还有 Java 应用要吃内存，缓冲池就得往下压。8C16G 这个档位的尴尬之处在于"什么都想跑一点"，那就得算着分，而不是每样都拿默认值糊上去。

Java 应用同理。不指定 -Xms 和 -Xmx 的话，JVM 会根据机器内存自动推算堆大小，在容器或共享环境里这个推算经常偏保守。固定住堆的上下限，GC 行为会可预测得多：

java -Xms4g -Xmx4g -jar your-app.jar

第三步：磁盘跑多快，测了才知道

云硬盘的性能标称值和实际跑出来的数字之间，通常有差距。这个差距不一定代表厂商虚标，更多时候是测试方法的问题：块大小、队列深度、读写模式不同，结果能差好几倍。

用 fio 测一下手里这台机器的盘，心里有个底。先装工具：

# Debian/Ubuntu
apt install fio -y
# CentOS/RHEL
yum install fio libaio -y

不要拿系统盘测。系统盘上跑 fio 有损坏文件系统的风险，测试产生的写入会直接冲击正在运行的系统文件。如果机器有数据盘，用数据盘测；只有系统盘的话，在根目录下建一个临时文件做测试对象，跑完删掉。

测 4K 随机读的 IOPS，这是数据库类负载最关心的指标：

fio --filename=/tmp/fio-test \
  --direct=1 \
  --rw=randread \
  --bs=4k \
  --iodepth=128 \
  --ioengine=libaio \
  --numjobs=1 \
  --size=1G \
  --runtime=60 \
  --group_reporting \
  --name=randread-test

跑完看输出里的 iops 那一行。普通云盘和 SSD 盘的差距在这个测试下会非常明显——普通盘几千 IOPS，SSD 盘能到万级以上。如果你打算在这台机器上跑 MySQL 或者 Redis，这个数字比 CPU 核数更值得关注。CPU 不够可以优化代码，磁盘 IOPS 不够，代码写得再好也得等着。

第四步：那 10M 带宽，经不起一个 docker pull

芯飞云 8C16G 的入门配置带的是 10M 带宽。10M 意味着理论下载峰值大约 1.25 MB/s。拉一个几百 MB 的 Docker 镜像，按这个速度得跑好几分钟。

这不是机器的问题，是带宽规格决定的。能做的优化有几件：

换国内镜像源。 Docker 默认从 Docker Hub 拉镜像，跨境链路的实际吞吐经常跑不满带宽标称值。在 /etc/docker/daemon.json 里配一个国内镜像加速地址：

{
  "registry-mirrors": ["https://your-mirror.example.com"]
}

重载配置：systemctl daemon-reload && systemctl restart docker。

大文件传输走内网或错峰。 如果有同地域的其他实例，走内网 IP 传数据，不占公网带宽，速度也快得多。没有内网条件的话，备份、镜像同步这类任务放到凌晨跑，至少不影响白天的正常业务响应。

关注出网流量。 按固定带宽计费的实例，出网带宽是封顶的；但如果你用的是按流量计费的规格，大流量任务（备份推送、日志外发、镜像拉取）在月底可能会给你一个意外。芯飞云的实例详情页能看到流量使用情况，养成偶尔看一眼的习惯。

最后：控制台给的是毛坯，住得舒不舒服看自己

云服务器和"开箱即用"的托管服务有一个本质区别：厂商负责的是硬件和虚拟化层，操作系统以上的一切都是你的。芯飞云这类控制台简洁的产品，好处是没有预设一堆你看不见的规则和限制，坏处是也没有人替你调参、加固、监控。

上面这几步——安全组收口、SSH 换密钥、Nginx 和 MySQL 的参数对得起规格、磁盘性能心里有数、带宽用在刀刃上——谈不上高深，但做没做过，一台机器跑起来的稳定性和响应速度是能感觉出来的。如果手里正好有一台刚开通还没怎么动的实例，不妨今天就挑其中一两项做了。或者去平台的试用入口看一下，花不了多少时间，但后面少踩的坑，远不止这点时间。