lua定位CPU100%问题

在开始这个话题前,说下我遇到的 skynet 进程 CPU100% 占用问题,查找 bug 的过程比较繁琐,后来想到做改进,这也是促成我写这篇文章的原因。

查到是一段 lua 代码有问题,这里截取其中出问题的代码:

-- 活动开始时间: 2033-01-01 00:00:00
local start_time = 1988121600

function start_activity()
    local now = os.time()
    local diff = now - start_time
    if diff < 0 then
        skynet.timeout((-diff)*100, start_activity)
        return
    end

    -- todo 省略活动内容
end

以上代码,通过 skynet.timeout 设置定时器,定时触发 start_activity , 看似没有问题,但是,当 skynet.timeout 第一个参数过大时,会有意想不到的收获。
继续阅读lua定位CPU100%问题

skynet 编译问题总结

原文 2015-09-23 23:48:54 发表于 CSDN,这里对以前写的文章做下收录。

skynet 下载编译过程对系统环境有很大依赖性,编译说明过于简单,没有提及到。所以,文章这里总结 skynet 比较常见的编译问题,希望有所帮助。

skynet 的编译过程:

git clone https://github.com/cloudwu/skynet.git
cd skynet
make linux

简单3步,对于很多高版本的系统来说,可能就这3步。但是,低版本系统可能无法编译,如下:
1. gcc 版本问题
2. 缺少 readline
3. 缺少 ncurses
4. 缺少 git (非必要项,则要手动下载skynet及3rd下的jemalloc)
5. 缺少 autoconf 等等
继续阅读skynet 编译问题总结

skynet 控制台使用技巧

原文 2016-01-07 01:14:27 发表于 CSDN,这里对以前写的文章做下收录。

skynet 自带了一个控制台服务,可以很方便获取和调试 skynet 运行数据,而且可以热更新代码,所以,弄明白 skynet 控制台管理可以让你更好地使用 skynet,甚至改进这个控制台服务,以满足不同业务需求。

这个服务默认不会启动,需要你手动启动它,如下:
skynet.newservice("debug_console", 8000)

设计原因,调试控制台只监听本地地址 127.0.0.1 ,如果需要远程使用,需要先登录到本机,然后再连接。

使用时,通过 telnet 或 nc 登录调试控制台,启动后显示:

$ nc 127.0.0.1 8000
Welcome to skynet console

表示连接成功。
继续阅读skynet 控制台使用技巧

skynet.call 潜在问题

最近朋友问我,说到他们项目不使用 skynet.call,他不是很理解,问我为啥。

于是,我看了 skynet.call 的代码。实现上,skynet.call 是服务 A 给服务 B 发 request 消息,等服务 B 处理完,再给服务 A 发 response 消息,最后交由服务 A 处理。(源代码可以参考 skynet服务的本质与缺陷

通常,skynet.call 这个过程是没有问题的,但在服务 B 繁忙无法响应时,就可能有问题。

没有超时机制

skynet.call 没有超时机制,执行的过程不能中断,得一直等到目标服务处理完才返回,所以业务可能出现长时间中断。如果想实现超时,可以利用另外一个协程来唤醒自己。
继续阅读skynet.call 潜在问题

skynet 高内存占用问题

前段时间,在服务器的监控后台发现,在线人数上去后 skynet 进程内存成倍升高,占系统 40% ~ 50 %,但人数回落到 1/3 后,内存使用并没有明显减少,仍有 40 % 左右。

服务器、skynet相关版本信息如下:
linux version 4.18.0
skynet v1.1.0
lua 5.3.4
jemalloc 5.0.1-0

我在本地压测时,却没有发现这个情况。在线人数上去,内存也是一样增加,但人数下来后,内存也逐渐释放了。项目代码是一样的,唯一不同的是,本地压测使用的系统是 CentOS 7 (Linux version 3.10.0), 我换了 CentOS 8 (Linux version 4.18.0) 压测后,发现跟线上的问题一样。
继续阅读skynet 高内存占用问题