关于服务器 (所在有效时间 2025-06-22 > 2027-06-14)
代码仓库平台7x24小时运行。
可以满足日常大模型对话,生图,语音克隆,视频生成,模型生成等任务。
更新通知
[2026-05-09]
换域名了,这回不改了,毕竟我买的可是一个可以随便用泛域名的玩意,为了方便我改为使用gitea.xeric.cc访问了,访问过程有点曲折,但反正可以用了。
后面可能会再弄一些虚拟机网址。
[2026-05-07]
换域名了,旧域名Xeric.zicp.fun将于2026-06-14过期,花生壳续费有点贵。我单独买了公网服务器和域名,ssl证书,现在可以直接通过https://xeric.cc/访问,现在服务器的操作有点繁琐了,但是确实便宜很多,而且带宽也更大,不用挤着那2m带宽了。
将逐步添加二步验证等内容,终于可以敞开干了。
[2026-04-09]
有段时间没更新了,现在服务器的存储结构换回了本地管理的方式,放网络中无论如何都会出现死锁的情况,本地就很流畅了。
期间跟着热度买了2张v100 16gb玩了玩,说实话性能确实强,但架构老了,新的模型跑不动,还是很局限的。
还是买消费级的显卡吧,换了一张3090 24gb也足够日常使用了。
然后最近说是内存要降价了,又买了一些电脑硬件(两张e5电脑主板和cpu,一块固态),总价在500左右(感觉还是贵了,这点老垃圾也要好几百),搭配退役的v100做一个小ai服务器。
[2025-12-10] 刚刚数据库有点抽风,表现为大部分工单丢失。 重启了一下。
之前git命令慢的问题已经没有发生了,内网数据交换风暴也平息了,一切又回到了和谐的状态。
[2025-12-03]
不行了,开了git的提交图加速,但也只是将命令从3秒 减到了 1.5秒,里面总是有一个分支会产生巨慢的操作,但是又没法直接忽略它。
所以不要同步vscode项目,会有性能问题。
我已经将vscode项目删掉了,现在日志干净了。
[2025-12-02]
优化了一下仓库结构,现在确认了不是nfs的问题,其他文件传输协议都试了一遍,目前nfs是最合适的。
不过这点小毛病被我给玩成顽疾了,vscode仓库一直在报git命令缓慢, slow git.Command.Run: /usr/bin/git name-rev --exclude refs/tags/* --name-only --no-undefined e28a92fc1fbe9de11eca2f8ad19899334bff8525 (3.55156199s)
这倒也没啥,主要是服务器现在不定时会发生 500 错误的问题,就需要重启整个docker容器。
然后现在比较大的提交可能无法传上去,看起来像是redis缓存太大了,主从同步会导致超时导致的,下一版本优化一下。
[2025-11-19]
服务器又有一些页面返回了500,这回我发现原因好像是绿联nas每天会重置nfs权限,需要重新应用,刷新就好。
很奇怪,只有部分仓库,部分分支有这个500响应,而且只会影响部分拉取操作,提交操作都不会报错。
[2025-11-18]
之前的docker启动流程有问题,把网卡折腾废了,ping自己的ip,localhost都是超时,或一般错误,但ping其他ip又都可以。
AI给的解决方案一直都是在几个问题上转圈圈,找不到关键问题。学了几天docker和网卡的相关知识,还得是人工解决。
这个问题一开始的起因是负载响应变得缓慢,毕竟我开docker就是为了用负载均衡加速响应的,结果个个实例的响应都要3秒,都触发容器的slow警告了。
然后我就手动重启了一下容器,这一重启就是一堆错误,redis连不上,数据库连不上,文件卷没权限,容器没网络等等问题。
经过这4天的排查以及对docker的学习,发现实际上这一堆问题都是因为wsl转发导致的。
实际上这个gitea不支持docker的网络别名解析,打印出来的结果都是127.0.0.1;所以我想着那就直接加个转发到redis的规则不就行了。
确实也可以,加了转发就可以访问了,但我以为这个规则是加在虚拟网卡上的,删了就行,结果这个规则实际上是加到了网卡上的。
然后就是我重启了网卡,结果容器能ping到外网,但是ping不到自己,localhost,127.0.0.1,192.168.1.xxx都不行;
但与此同时内网其他设备都能访问,数据库都能ping到,远程文件目录也能ping到,但容器就是连不上,redis无法连接,数据库无法连接,文件卷挂不上去。挂上去了就没权限。
折腾了4天,脑子开窍了,才想起来这个规则只顾着添加了,没删除。在容器启动前检查一下就行了现在。
[2025-11-12]
报500的问题没有再发生了,看来是修好了。
我继续添加了两个runner,一个ubuntu,一个windows。
之前嫌启动流程太繁琐了,所以就没开,现在都装在一个docker中了,启动嘎嘎简单。
[2025-11-11]
服务权限不稳定的问题修复了。
希望问题的起因是和我想象的一样的。
[2025-11-10]
数据服务权限不太稳定,所以部分仓库偶尔会返回500。
比如内网其他设备写入一些文本就可能让仓库的权限部分丢失。
[2025-11-05]
开放了一些额外的服务页面。
[2025-11-03]
光迁移文件不够,我试着在服务器上弄了一个负载均衡,不过是在单个服务器上用docker实现的。
负载均衡后,开启页面的响应速度会减少到500ms。但其他涉及资源读取,比如git,图片,diff等文件操作都会慢一些,时间还是原来的3秒左右。
[2025-11-01]
抽了半天时间将数据库和所有文件迁移到了数据服务器上了,没想到200+个仓库就用了77G了,用的还是挺快的。
gitea程序还是运行在服务器A上,但是所有请求数据都走到数据服务器上了,不枉我牵了根光纤,两个服务器交换的速度还挺快的。
现在网页上查看带有图片的提交记录时响应速度变快了,数千文件变更记录也能快速返回;不过受限于外网速度,体积比较大的文件还是要等。
不过与其说变快了,倒不如说这些响应速度趋于平均了,因为我感觉普通页面跳转变慢了。
可能还是机械硬盘阵列的随机独写速度还是比不过固态的原因,最近双十一试试再配几块固态缓存试试。
下一步就是多开一些runner来压榨服务器的性能了(还有好好学一下action原理)。
然后明年(2026)计划添置AI服务器,按现在的行情,我是想考虑继续买2080Ti,还是3090Ti,别问我为啥不买5090Ti嗷。
2080是因为还支持nvlink,3090是因为半精架构应该会好一些,更高版本的价格比较贵,我也没有回本的渠道不合算。低版本的比如1080,titan就不考虑了,没有半精计算,显存砍半,也不合算。
[2025-9-7]
添加了数据库服务器,后续会逐步转移gitea内容到这个数据库中。
这个数据库功耗极低,代价是性能也不高,如果将gitea运行在这个服务器上,很多功能就无法实现了,所以主要的服务器不会改变。
但好在架构是最新的,也非常稳定。
[2025-8-2]
添加了工单机器人,只要是机器人账户权限允许,都会响应并回复。
如果希望自己的仓库得到帮助,可以将这个小机器人加入团队,并添加工单读写权限(不需要其他的权限)。
大部分情况它只能提供情绪价值,因为它只能读取工单的标题和对话内容,不过我感觉我调教的还不错,推荐一下。
注:目前机器人不能识别多个用户的发言,并且在面对问题时,总是会选择@管理员账户,当然你愿意调教的话也可以让它@别人。
机器人无法读取工单引用,图片引用,它的回复是基于上下文的。
[2025-7-13]
购置了一些硬件进行了更新。
主要是买了个新服务器,和新显卡。原来的服务器偶尔碰一下就会关机,或者突发高负载的时候也会莫名自动关机。
从我多年攒电脑的经历来看,看起来像是电源容量不够的样子,也像是温度过高的表现。
但我从来都是电源容量往高了买的,起码冗余1.5倍;电脑散热我也给足了。
懒得拆开修了,这个服务器主板布局不合理,容易和其他硬件冲突,拆显卡还容易碰掉附近的小电容,随便碰掉一个就要换主板,已经换过一次了,不敢再动了,重新买一台安心一点。
另外就是平时多个numa节点也没有什么场合可以很好利用,还徒增电费,还是用单cpu的电脑当服务器了。
[2025-7-10]
请暂时不要启用两步验证,这个内网穿透无法映射其他端口,所以服务器的ssh验证还无法使用,如果启用了两步验证,提交代码时将验证将总是失败。
[2025-7-7]
最近在上传ai模型时发现gitea的版本安错了,导致只能利用2gb内存,所以在一些大型文件上传时会因为内存溢出导致服务崩溃,现在修好了。
其他功能页面
以下是域名上关联的子页面服务,创建仓库的时候注意不要创建和这些重名的组织,或账号名称。
如果重名的话,这些页面会被优先转发到以下服务上,而不是gitea页面。
如果直接点击链接跳转,可能会遇到较长的加载时间,这可能是因为转发跳转错误的问题,手动拼接一遍地址可以避免这个问题。
Redis服务(http连接)
开放了基于http连接的redis服务,在当前域名后加 /redisweb 即可使用。
- /ping 来测试连接,返回
{"PING":[true,"PONG"]} - /set 设置键值对,返回
{"SET":[true,"OK"]} - /get 获取键值对
{"GET":"12345abcd"}
rabbitmq 管理页面
开放了一个服务器本地管理页面 /rabbitmq/managerment/
以及这些连接页,不过由于html与mqtt连接状态不一致,所以没法转发出来使用,但也不要占用。
/rabbitmq/mqtt//rabbitmq/mqtttls//rabbitmq/amqp/
在线 vscode
开放了一个在线的 vscode编辑器 /vscodeweb
禅道项目管理 zantao
开放了一个国产的禅道管理系统。
这个系统有点复杂,单独代理到一个子页面的工作量有点大,所以实际上会代理到一个新的随机域名上。
服务器构成
所有可用机器列表,功耗为实测工作持续耗电量,不代表其实际功率。
低功耗:仅测量机器本身待机运行状态下持续平均耗电量。
高功耗:测量标准与低功耗相同,但会启用常用软件,这个不是通过长时间高压烤机得来的功耗标准,仅作参考。
最高功耗:满荷功耗,全力运转
服务器A:(主要)
日常待机功耗 75w,高功耗200w(加显卡),容量1000w
目前很耐造,相比之下比较省电,所以主要担任仓库服务器,兼职unity打包。
- CPU:22核44线程2.2Ghz,睿频3.7Ghz,单颗TDP145w,NUMA节点数量 1
- 内存:64gb DDR4
- 硬盘:2T系统盘用于日常缓存。
- AI计算阵列:v100 16gb 数量2。
服务器B:
日常待机功耗 100w,高功耗300w(加显卡),容量1000w
有点小问题,偶尔会因为一些波动抽风死机,最近检查发现可能是因为有一颗cpu的供电线没接好导致的。(现在关了用作冗余)
- CPU:16核32线程2.3Ghz,睿频2.6Ghz, 单颗TDP145W,NUMA节点数量 2
- 内存:64gb DDR4
- 硬盘:2T系统盘用于日常缓存
服务器C:
新增一台ai服务器
- CPU: 4核4线程 3.2GHz
- 内存:16gb ddr4
- 显卡:V100 16gb 数量2
打包主机A:
日常功耗80w,高功耗300w(加显卡),容量850w
- CPU:6核12线程3.0Ghz,睿频4.2Ghz,单颗TDP75w,NUMA节点数量 1
- 内存:64gb,DDR4
- 硬盘:1T系统盘,6T仓库, 40T阵列。
- 显卡:RTX5060Ti 16G亮机卡 数量1。
打包主机B:
日常功耗100w,高功耗300w(加显卡),容量1200w
旧时代机皇。
- CPU:10核20线程3.70Ghz,睿频5.5Ghz,单颗TDP125w,NUMA节点数量 1
- 内存:64gb,DDR4
- 硬盘:1T系统盘,4T仓库x4
- 显卡:RTX3090Ti 24G亮机卡 数量1。
NAS(绿联):
日常功耗20w,高功耗60w
- CPU:4核4线程1.8Ghz,睿频3.4Ghz,NUMA节点数量 1
- 内存:16gb,DDR5
- 硬盘:32TB
低功耗服务主机:
日常功耗5w,高功耗45w(加显卡),容量65w
提供日常不间断对话集成,如微信机器人等服务微信聊天机器人。
- CPU:4核8线程2.4Ghz,睿频3.5Ghz;小核1.0Ghz,睿频1.6Ghz;NUMA节点数量 1
- 内存:16gb,LPDDR5
- 硬盘:1T系统盘
- 显卡:GTX1050Ti级别的