芯飞云新手上路：先把这几个“坑”绕过去，再谈跑业务

芯飞云新手上路：先把这几个“坑”绕过去，再谈跑业务

刚拿到服务器，尤其是从控制台看到那串公网 IP 的时候，人多少是有点懵的。本文不聊选哪款配置，也不聊价格，就聊一件事：机器拿到手之后，怎么让它真正“能用”起来。很多新手卡住的地方其实不是技术本身，而是几个默认设置没动，或者参数没调，导致明明配置不差，跑起来却处处别扭。

下面按实际操作的顺序来，每一步都给到具体的命令或者配置片段，照着敲基本能绕过大多数新人要踩的坑。

一、连不上？先检查那两扇“门”

很多人第一反应是 ping 一下 IP，发现不通，就以为机器有问题。其实云服务器和本地虚拟机最大的区别在于：默认什么都不通。

芯飞云的安全组默认封锁所有端口。也就是说，你买完机器，22 端口（SSH）是关着的。在控制台找到“安全组”或者“防火墙”设置，加一条入站规则：协议 TCP，端口 22，源地址填 0.0.0.0/0（或者你自己的固定 IP，更安全）。保存之后，再去连。

Mac 用户直接打开终端：

ssh root@你的公网IP

Windows 用户推荐装个 FinalShell 或者 Xshell，新建 SSH 连接，填 IP、端口 22、用户名 root，密码在控制台重置或者初始密码在站内信里找。

连上之后第一件事不是急着装环境，而是把默认 SSH 端口改掉。22 端口是全网扫描的重点对象，你如果去看 /var/log/secure 或者 auth.log，会发现每天有大量尝试暴力破解的记录。

# 编辑 SSH 配置文件
vim /etc/ssh/sshd_config

# 找到 #Port 22 这一行，去掉注释，改成比如 22345
Port 22345

# 重启 SSH 服务
systemctl restart sshd

改完之后，下次连接记得端口填 22345。同时别忘了安全组里也要放行这个新端口，否则改完自己都连不上了。

顺手把防火墙也启用起来，只放行你确定要用的端口：

# Ubuntu 用 ufw

sudo ufw allow 22345/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# CentOS 用 firewalld

sudo firewall-cmd --permanent --add-port=22345/tcp
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

二、8 核 16G 的机器，默认参数是在“浪费”

如果你选的是 8 核 16G 这个档位，它的 CPU 和内存比例是 1:2，每颗核心对应 2G 内存。这个配比本身是合理的，但系统里很多软件默认不是按这个配比来的。默认参数不调，相当于用 8 核的力气干 2 核的活。

MySQL：缓冲池从 128M 拉到 4-6G

MySQL 的 innodb_buffer_pool_size 默认值小得可怜，大概只有 128M。这个缓冲池是用来缓存表数据和索引的，太小的话，查询会频繁读磁盘，性能自然上不去。

在 /etc/mysql/my.cnf 或者 /etc/my.cnf 里加上：

[mysqld]
innodb_buffer_pool_size = 6G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2

innodb_buffer_pool_instances 设为 8，和核心数对齐，可以减少锁竞争。innodb_flush_log_at_trx_commit = 2 是在数据安全性和写入性能之间取个平衡，适合测试环境或对数据一致性要求不是极端严格的场景。

改完重启 MySQL，然后用这个命令看缓冲池命中率：

SHOW ENGINE INNODB STATUS\G

找 Buffer pool hit rate 那一项，调优之后应该能到 99% 以上。

Nginx：连接数不是 512 就够的

Nginx 的 worker_connections 默认 512，如果你拿它做反向代理，一个客户端请求会占两个连接（客户端到 Nginx 一个，Nginx 到后端一个），实际并发能力只有 256 左右。8 核的机器配上这个默认值，属于严重的“有力使不出”。

打开 /etc/nginx/nginx.conf：

worker_processes auto;
worker_rlimit_nofile 65535;

events {
worker_connections 10240;
multi_accept on;
use epoll;
}

worker_processes auto 会自动设成 8，worker_connections 拉到 10240，理论并发上限就是 8 × 10240 = 81920。实际反向代理场景下支撑几万并发连接没什么问题。

同时记得把系统文件描述符限制也提上去，编辑 /etc/security/limits.conf：

text

• soft nofile 65535
• hard nofile 65535 JVM：堆内存别让它自己“伸缩” 跑 Java 应用的时候，如果直接用 java -jar 启动，JVM 的堆内存是动态扩展的。流量上来堆不够就扩，流量下去再缩，这个过程中 GC 的停顿会变得不可预测，高峰期接口超时往往就是这么来的。

把初始堆和最大堆设成一样的值：

java -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar

16G 总内存给 JVM 分 8G 是比较稳妥的，剩下的留给系统本身、MySQL 或者 Nginx 用。用 jstat -gcutil <pid> 1000 可以实时观察 GC 情况，调优之后 Full GC 的频率会明显下降。

三、Docker 容器化：资源隔离不做，一台机器上的服务互相拖累

现在很多人习惯把服务塞进 Docker 里跑，一台 8 核 16G 的机器上同时跑数据库、缓存、后端、Nginx 四个容器是常态。但如果你启动容器的时候不限制资源，其中一个容器内存泄漏，会直接把宿主机内存吃光，然后把其他容器甚至 Docker 守护进程一起拖死。

docker run -d
--name backend
--memory=4g
--memory-swap=4g
--cpus=2
--memory-reservation=3g
my-app:latest

--memory 是硬上限，超过就 OOM。--memory-swap 设成和 --memory 一样，意味着禁止用 swap，只用物理内存。--cpus=2 把容器限制在 2 个核的算力以内。--memory-reservation 是软限制，资源紧张的时候会优先回收超过这个值的部分。

写 docker-compose.yml 的话，对应的是 deploy.resources.limits 那一段。

四、排查问题的习惯：先看这三样

服务器出问题的时候，新手容易慌，但其实大部分情况看三个地方就能定位。

第一，看资源。 连上去敲 top 或者 htop，先看 load average 和内存占用。如果 CPU 不高但内存快满了，说明是内存瓶颈，可能需要调小某个服务的缓存配置，或者升级配置。

第二，看日志。 Nginx 的日志在 /var/log/nginx/，应用日志通常在项目目录的 logs/ 下面。网站 502 了，先去 Nginx 的 error.log 里翻最后几条，基本都有线索。

第三，看端口。 ss -tlnp 列出当前监听的所有端口。你期望 80 端口在听，结果里面没有，那要么是服务没启动，要么是配置文件里端口写错了。

写在最后

芯飞云这个平台本身把一些底层的事情简化了，比如控制台预置了主流系统镜像，也有 Nextcloud 这类一键部署包。但“能跑起来”和“跑得稳”之间，隔着几行参数的距离。上面这些配置改动，不涉及什么高深的技术，只是把默认值改成了和硬件匹配的值。做完这几步，再往上叠业务，会顺手很多。