企业官网建设流程全解析

1核1G的服务器到底能干什么？我把这台免费云服务器压到了极限

先说结论吧，1核1G不是玩具，但也别指望它干重活。我手里这台机器是之前活动白嫖的一台免费云服务器，配置就是标准的1核CPU、1G内存、40G系统盘，带宽好像也就5M。刚拿到手的时候我也觉得这玩意儿就是个电子垃圾，放个网站都怕卡死。但折腾了三个月，我把它从单纯的博客鸡，一点点压榨成了集网站、图床、反向代理、监控告警、离线下载、定时任务于一体的"瑞士军刀"，中间踩了不少坑，也摸清了1核1G的性能底细。

这篇文章就把我这三个月的实操记录整理出来，包括我到底在上面跑了什么、每个服务的性能表现如何、内存是怎么抠出来的、哪些事千万别让它干，以及遇到OOM（内存溢出）和负载飙高时的排查流程。如果你手上也有一台低配云服务器，或者正纠结要不要买1核1G的入门款，这篇文章应该能帮你省下不少试错时间。

1. 内容整体设计与思路拆解

1.1 1核1G到底意味着什么，先给新手泼盆冷水

很多刚接触云服务器的小白，看到"1核1G"觉得有总比没有好，实际上手才发现这台机器连跑个桌面环境都费劲。先说硬件层面的限制，1核CPU意味着同一时刻只能处理一个线程的运算，你开个编译任务，CPU就跑满，网站请求就得排队等着。1G内存更是紧巴巴，你装完Nginx加PHP再装个MySQL，内存基本就见底了，Swap分区一开，磁盘就开始充当内存，速度直接从SSD跌回机械硬盘的水平。

我用一个不太严谨但很直观的比喻：1核1G就像一间只有一个工位的小办公室，你让它同时干写方案、收快递、接待客户这几种活，不是不能干，但一次只能干一件，而且干一件的时候其他活都得堆在门口排队。所以设计方案的第一步，就是接受这个现实——你不可能什么都跑，必须做减法。

1.2 免费云服务器的真实性能边界，实测数据说话

我跑了几轮压测工具，数据给大家一个参考。CPU方面，单核的UnixBench跑分大概在700到1000之间，而主流4核机器的跑分通常能到4000以上，差距非常明显。内存方面，因为系统本身要占200到300MB，你实际能用的大概只有700MB左右。带宽如果是5M，那实际下行速度也就600KB每秒左右，传个大点的文件到服务器上，能等到你怀疑人生。

但这些数字不代表它不能干活。我做了一个对多数个人项目很实用的判断：凡是一次性任务、低频任务、轻量级网络服务，1核1G都能扛住；凡是需要并发、常驻内存大、计算密集型的活儿，趁早放别处。我们的目标不是让它跑得快，而是让它跑得稳、跑得久。

1.3 整体方案选型：从单点到多服务，一步步加码

我刚拿到机器的时候只部署了一个博客，后来因为需要给博客配图，就加了一个图床服务。再后来想监控网站是不是挂了，又加了一个定时任务加告警机器人。每个服务都是按需加进去的，加之前先算一笔内存账，加完之后观察两天，确认稳定了再继续往下走。

我最终跑起来的一整套服务清单大概是这样：

• 系统：基于Debian系的Linux发行版（具体版本就不细说了，选稳定版就好）

• 主站：Nginx + PHP + SQLite跑一个博客程序（能用SQLite就坚决不装MySQL）

• 图床：Nginx静态文件目录，配合自写的小程序做上传和缩略图

• 反向代理：给局域网里的几台设备做HTTPS代理，省去每台设备单独配证书的麻烦

• 监控：一个轻量级的探针脚本，每5分钟检查一次网站和API的状态，异常时通过Telegram机器人推送告警

• 离线下载：Aria2做HTTP和磁力下载，下载完直接存到服务器上，再通过Web界面取回本地

• 定时任务：数据库备份、日志切割、证书自动续期，全靠cron跑

全跑起来之后，内存稳定在850MB到950MB之间，CPU只有遇到爬虫扫站或者有人刷接口的时候才会短暂飙高。这个状态已经维持了一个多月，没再发生过OOM。

2. 核心细节解析与实操要点

2.1 系统层面的瘦身技巧：从源头省出200MB内存

拿到手第一件事，我先把不用的系统组件卸了一遍。Linux发行版默认装了一堆你可能永远用不着的东西，比如打印服务、蓝牙服务、桌面环境相关的依赖，这些加起来能占几百MB内存和好几G磁盘。

我的做法是先看一看当前系统的内存占用情况，然后手动停掉并禁用那些明显用不着的系统服务。比如一些发行版会默认启动一个多媒体相关的后台服务，这玩意儿在服务器上毫无用处，直接干掉。再比如云厂商预装的监控组件，如果不需要官方控制台的监控功能，也可以停掉，能省不少内存。

另外一个很容易被忽略的坑是日志。系统默认的日志服务会把所有内核和应用的日志都攒下来，时间一长磁盘就被塞满了。我把日志的保留策略改成了只保留3天，并且限制了单个日志文件的大小。这个操作虽然不起眼，但能避免很多后续的磁盘告警。

2.2 Swap到底要不要开？怎么开才不拖垮磁盘

关于1G内存的机器要不要开Swap，网上说法不一。我的看法是：开，但要控制好大小，并且调整交换策略。如果没有Swap，内存一满系统就会直接触发OOM Killer，把正在跑的进程随机干掉一个，这在你睡觉的时候发生就很抓狂。开了Swap之后，系统多了一层缓冲，内存满了会先把不常用的内存页挪到磁盘上，虽然慢，但至少不会瞬间崩掉。

我这边创建了一个2G的Swap文件，放在系统盘上。为什么不用专门的Swap分区？因为云服务器调整分区很麻烦，Swap文件则灵活很多，随时可以删掉重建。然后我把系统的交换倾向参数从默认的60调到了10左右，意思是系统尽量优先使用物理内存，只有万不得已才用Swap。这样既保留了兜底能力，又不至于因为频繁的磁盘读写把整台机器拖死。

注意：Swap文件的大小不是越大越好。1G内存的机器配2G Swap就差不多了，再大的话，内存溢出时系统会把大量进程换到磁盘上，恢复响应会非常慢，反而变成一种变相的死机。

2.3 轻量级数据库选型：SQLite真香，MySQL是灾难

很多人在1G内存的服务器上装MySQL，装完之后发现内存直接少了300到400MB，再加上PHP和Nginx，内存根本不够用。我一开始也是这个思路，后来测了一下发现MySQL的进程在空闲状态下就占了大几百MB内存，在1核1G的机器上实在不划算。

我的解决方案是，只要数据量不超过几万条、没有超高并发写入的场景，就优先用SQLite替代。SQLite是文件型数据库，不需要常驻后台进程，读写就是直接操作文件，几乎没有额外的内存开销。我博客的所有文章、评论、设置，全都存在一个几十MB的SQLite文件里，访问量不大的情况下性能完全够用。

如果你确实需要MySQL，也有一个折中方案：把MySQL的参数调成极简模式，把缓存池大小调到最小，禁用掉不需要的存储引擎和性能监控功能。这样MySQL的常驻内存能压到150MB左右，但代价是查询性能会有明显下降，而且一遇到稍复杂一点的查询，CPU会飙得很高。

2.4 Web服务端精简配置：Nginx和PHP-FPM的参数到底该怎么填

Nginx的默认配置对1核1G来说偏奢侈了。默认配置里Nginx会启动4个worker进程，每个worker默认可以处理1024个连接，这意味着光是Nginx的连接缓冲区就能吃掉不少内存。我这边把worker进程数改成了1个，每个worker的最大连接数改成128，这样Nginx自己占用的内存能控制在20MB以内。

PHP-FPM的配置更需要抠。一个PHP-FPM进程在空闲状态下大约占用30到50MB内存，如果是跑WordPress之类的大型程序，一个进程甚至能占到80到100MB。我在低配机器上会把PHP-FPM的进程管理模式改成动态模式，并把最大子进程数限制在5个左右。这样正常情况下有2到3个PHP进程在跑，内存占用稳定在150MB上下。

注意：改完PHP-FPM配置一定要重载，而且要看日志确认没有报错。我有一次把进程数改得太小，结果网站一有访问量就直接报502，排查了半天才反应过来是PHP-FPM没有足够的进程处理请求了。

3. 实操过程与核心环节实现

3.1 从零开始的部署流程：装系统、开Swap、装环境

整个部署过程我记录一下，给想抄作业的朋友一个参考流程。第一步是在云厂商控制台重装系统，我选的是最小化安装的Linux发行版，没有装任何桌面环境和额外的组件。系统装好后，先用SSH登录，然后立刻创建Swap文件并调整交换策略，避免后面装软件时装到一半内存不足。

第二步是更新系统软件源，把基本的编译工具和常用命令行工具装上。然后安装Nginx和PHP，这里我特意选了PHP的轻量扩展组合，只启用了程序真正需要的那几个扩展，什么图形处理、数据库扩展、缓存扩展，只装必要的，其他的统统不装。

第三步就是部署网站程序。我把博客程序的文件上传到服务器的Web目录，给目录设置好写权限，然后配置Nginx的站点规则。Nginx的配置文件我写得很精简，只用到了监听端口、站点根目录、PHP解析这几个核心指令，顺便加了简单的浏览器缓存头，减少服务器的重复请求压力。

3.2 把网站和API同时跑起来：反向代理与端口规划

跑了主站之后，我又加了一个反向代理服务。需求是这样的，我家里有几台设备提供了Web管理界面，但直接暴露到公网既不安全也不好记，我想通过这台云服务器做中转，统一用HTTPS访问。

实现方式不复杂，就是在Nginx里多配几个server块，每个server块监听不同的域名或路径，然后通过反向代理指令把请求转发到家里的设备内网地址上。这样做的好处是：只需要在云服务器上部署一个SSL证书，就能让所有走代理的服务都拥有加密传输。不过要提醒一下，反向代理只适合转发那些流量不大的服务，如果转发的是视频流或大文件下载，那5M带宽很快就会被打满。

端口规划上，我遵守了一个原则：公网只暴露80和443，其他所有服务端口都绑定到内网或只允许本机访问。比如上面提到的Aria2下载工具，它的Web管理界面我只允许本地通过SSH隧道访问，不直接对公网开放，这样能省去一堆被扫描爆破的麻烦。

3.3 压到极限的实测记录：同时跑博客、图床、监控和下载

部署完之后，我来了一次"压到极限"的实测。我在同一台1核1G机器上同时启动了博客、图床、监控告警、离线下载这四类服务，然后模拟了日常使用场景：一边有用户在看博客文章，一边有图片在上传，同时后台还在跑一个下载任务。

我先记录一下没有压力时的基准数据，内存占用大概在800MB左右，CPU基本在10%以下。接着我模拟了50个并发请求同时访问博客页面，这时候CPU立刻飙到90%以上，内存没有太大波动，但页面响应时间从原来的300毫秒左右拉长到了3到5秒。我又同时启动了一个下载任务，发现磁盘I/O明显升高，CPU也持续维持在满负荷状态，但好在没有触发OOM或者进程崩溃。

这次实测给我的感觉是：1核1G的机器能扛住"少量并发+多服务共存"的场景，但特别怕"高并发瞬时冲击"。应对方式也很直接，就是在Nginx层做访问频率限制，把单个IP的请求速率限制在每秒几次，这样即使被爬虫或恶意请求盯上，也不会一下子把CPU打满。

3.4 内存告急时的手动急救流程与进程排查方法

有一次我遇到内存突然飙升到接近极限值的情况，系统开始出现明显的卡顿。我立刻登录服务器，先用命令查看当前内存的占用情况，再用另一条命令列出了所有进程的内存占用排行榜。结果发现是PHP的一个进程变成了僵尸状态，占了好几倍正常进程的内存，而且父进程没有回收它。

处理办法很简单，找出这个异常进程的PID，然后把它结束掉，再重载PHP服务让它重新拉起正常的子进程。整个过程也就一两分钟，但如果不及时发现，系统可能几分钟后就会触发OOM，把所有服务都干掉。

这里分享一个排查心法：在1核1G的机器上，内存比CPU更珍贵。所以我几乎每周都会写个定时任务，把内存占用最高的前10个进程记录到日志里。这样即使某天服务崩了，我还能回头看到底是谁吃的内存。

4. 常见问题与排查技巧实录

4.1 网站打开很慢，CPU一直100%，到底是谁在捣鬼

低配服务器最常见的问题就是CPU被打满，网站打开像蜗牛。遇到这种情况，我一般按这个顺序排查：登录服务器后用命令查看当前负载，再用命令看是哪个进程在占用CPU。如果发现是PHP进程，那大概率是某个页面存在性能瓶颈，可能是数据库查询太慢，可能是某个插件在搞鬼，也可能是有人在持续请求漏洞路径。

如果是WordPress类的站点，我建议装一个查询缓存插件，或者换个更轻量的博客程序。我自己就是从WordPress换到了SQLite方案的轻量程序，内存占用直接从500MB降到了200MB，页面响应速度也快了很多。

还有一个很容易被忽视的因素是外部请求。你永远不知道有多少扫描器在公网上盯着你的服务器，天天尝试各种漏洞路径。我在Nginx的日志里发现过大量针对后台路径的404请求，全是一些自动化脚本在探测。解决办法是启用一个简单的规则，把那些明显是扫描行为的IP地址自动拉黑一段时间，这样既减轻CPU压力，也降低被攻击的风险。

4.2 磁盘空间莫名减少，日志文件占了大头

低配云服务器的磁盘通常也不大，40G看起来不少，实际上装几个软件、跑一段时间日志，就所剩不多了。我遇到过一次磁盘告警，排查后发现是Nginx的访问日志和错误日志，加上系统的内核日志，堆起来竟然有好几个G。

解决办法分两步：第一步是把日志轮转配置改一下，让日志按天切分，并且只保留最近7天；第二步是给日志文件加上大小上限，超过一定大小就直接丢弃最旧的部分。做了这两件事之后，磁盘占用一直稳定在20G以内，再也没告警过。

另一个磁盘空间消耗大户是包管理器的缓存。软件装完以后，下载的安装包还会留在缓存目录里，积少成多。我习惯每隔一段时间就清理一次缓存，这个习惯后来救过我一次——磁盘还剩几百MB的时候，清理出两个多G，避免了服务器直接无法写入的尴尬。

4.3 网站莫名其妙挂掉，查日志发现OOM Killer动了手

有一段时间我的博客老是在深夜挂掉，白天又恢复正常。我一开始很困惑，翻系统日志才发现，原来是内存耗尽，Linux的OOM Killer在凌晨自动把占用内存最高的进程给杀掉了。而那个时间点，恰好是定时备份任务运行的时候，备份占用了不少内存，直接把其他进程挤爆了。

解决办法是把备份任务的时间挪到了凌晨之外，并且给备份任务加了一个内存限制，让它不能无限占用内存。另外，我重新调整了系统服务的优先级，让关键服务（比如Nginx和PHP）拥有更高的内存保留优先级，这样即使内存压力大，系统也会优先保护核心服务，而不是把网站的进程杀了。

注意：OOM Killer的规则是可以配置的，但我不建议新手一上来就调这个，很容易把自己锁在门外。更好的做法是，先搞清楚是谁在消耗内存，从源头解决，而不是试图从系统底层打补丁。

4.4 1核1G不能干什么，这份避坑清单请收好

这三四个月用下来，我摸清了这台机器的能力边界，也总结了一份"不要做"清单，给各位提个醒：

• 不要在上面跑Docker全家桶。Docker本身占内存不算多，但每个容器跑起来都是独立的进程，几个容器叠一起，内存瞬间爆炸。

• 不要在上面编译大型软件。一次Go程序的编译就能把CPU打满几分钟，期间网站完全失去响应。要编译的话，用本地机器交叉编译，或者换CI工具来做。

• 不要在上面安装Windows桌面环境。显卡直通之类想都不用想，1核1G跑Windows Server都可能卡到没法操作。

• 不要拿它当主力数据库服务器。数据量一大、查询一复杂，CPU和内存双双告急，而且磁盘I/O也会成为瓶颈。

• 不要跑视频转码或图像批量处理。这类任务计算密集且内存消耗大，低配机器跑起来会卡到怀疑人生。

5. 工具选型与免费方案对比

5.1 免费云服务器从哪里来，靠谱程度怎么样

很多人问我免费云服务器是哪里搞的，实际上各大云厂商隔三差五都有新用户免费试用活动，通常是一个月到三个月不等，配置大多是1核1G或者2核2G。这类机器的特点是：配置不高，但胜在免费，适合用来学习和部署个人项目。

不过免费机器的限制也很多。大部分免费试用机型的带宽很小，流量包有上限，而且到期后如果你不手动释放，就会按原价继续扣费。我在快到期前提前把数据备份到了本地，然后重新用别的优惠开了新机器，数据迁移也就花了一个下午。

另外，也有朋友提到过Serverless这类免服务器部署平台，确实可以在某些场景下替代1核1G的服务器。但Serverless也有它的短板：冷启动慢、长连接支持不好、对文件系统的访问限制很多。在我看来，Serverless适合跑一次性任务或API，而1核1G的云服务器适合需要常驻运行、需要自己掌控系统的场景，两者不能完全替换。

5.2 几个值得装的轻量级工具推荐

在1核1G上用下来的工具里，有几个是我强烈推荐的，都是那种装上去几乎不占资源、但作用很大的类型。

第一个是Fail2ban。它会监控日志，发现某个IP多次尝试失败就会把它临时封禁。在公网环境里，这东西能过滤掉90%以上的密码爆破请求，让SSH和Web服务安全很多。

第二个是Tmux。因为SSH连接一断，正在运行的命令就会中断，这在下载大文件或者跑长任务时很头疼。Tmux可以在服务器端保持一个会话，就算你本地断线了，任务还是会继续跑，重连之后还能看到原来的界面。

第三个是Caddy或者Nginx。Caddy的优势是自动申请和续期HTTPS证书，配置也简单很多。不过Nginx功能更强、更灵活。我个人在低配机器上更偏好Caddy，因为省了一个维护证书的定时任务，而且内存占用跟Nginx基本持平。

第四个是rclone。我用来定期把服务器的数据备份到对象存储服务上，因为本地磁盘太小，不能存多份备份。rclone支持增量同步，每次只传改动的部分，不会占太多带宽和CPU。

5.3 关于升级配置的思考：什么时候该说再见了

当你发现服务器频繁出现OOM、CPU高居不下、网站响应时间明显变长，而且你已经把能优化的都优化了，那说明该升级配置了。1核1G适合的场景是个人博客、小型API、运维测试机、跑脚本任务，一旦你的需求超出了这个范围，强行硬扛只会让自己折腾得更累。

我个人对这个配置升级的判断标准是：当网站在没有任何突发流量的情况下日常负载就超过70%时，就该考虑换2核4G了。因为再往上加服务，稳定性会急剧下降，省那点服务器钱不值得。

6. 长期稳定运行的经验心得

6.1 自动化运维：让定时任务帮你盯着服务器

低配服务器最大的问题是没有专人盯着，挂了只能自己发现。我给自己配了一套很简单的监控体系：一个脚本每5分钟检查一次关键端口是否存活，如果发现异常就通过Telegram机器人发消息告警。这套体系跑了大半年，帮我提前发现了两次数据库进程异常退出、一次SSL证书续期失败，都是靠自动化脚本在第一时间通知到我的。

除了监控告警，定时任务也帮了不少忙。数据库每天自动备份保留7天，系统包每周自动更新，访问日志每周自动清理，这些都是写好的脚本在按时跑。设置定时任务的思路很简单：凡是重复性的操作，都应该交给脚本，而不是记在脑子里。

6.2 性能数据日常观察：我的三个月数据总结

最后聊聊我这三个月的性能数据观察。这台1核1G服务器的日常CPU使用率大概在5%到15%之间，内存使用率稳定在85%到95%之间，磁盘使用率目前是45%左右。高峰期一般是晚上8点到11点，这个时间段访问博客的人最多，CPU能到30%左右。而内存一直高居不下，主要是因为我跑的服务比较多，已经快到这台机器的物理极限了。

但即便内存长期高水位运行，这三个多月里它没有发生过一次真正的OOM崩溃，说明只要做好服务裁剪、合理设置Swap，1核1G完全可以长期稳定运行，应付个人级负载绰绰有余。

6.3 再给你一条建议：衡量"够用"的标准不是配置，而是你的需求

折腾了这么久，我对1核1G最大的感受是：它教会了我做减法。以前我用4核8G的服务器，遇到什么想装就装，根本不在乎资源浪费。换到1核1G之后，每装一个软件都要先想清楚这个服务是否真的必要、是否能用更轻量的方案替代、是否会影响已有的服务。

这种心态的变化，其实比服务器本身更有价值。如果你也是刚入门云服务器的新手，1核1G绝对是一个很好的启蒙机器。用它学Linux、学Web服务、学自动化运维，成本低、容错高，犯错了大不了重装系统，试错成本几乎为零。