为何用LUA_MASKCOUNT

[kingbird2011]

我用LUA_MASKRET但是因为TailCall不能及时回调，导致统计不了函数的总体运行时间，有啥好的解决办法吗

[cloudwu]

函数并不总是通过 ret 返回，还有 error 。

[kingbird2011]

云风大哥，问个问题 目前项目里有很多不连续int的key的表，我想拓展下datasheet让它支持。 看源码的过程中发现，datasheet在index的时候，访问过的会构造出table放到cache中。 假如我在某个服务遍历访问过，是不是表示其实它的内存消耗，和直接自己require也差不多了？

…

------------------ 原始邮件 ------------------ 发件人: "云风"<notifications@github.com>; 发送时间: 2019年4月20日(星期六) 中午11:14 收件人: "cloudwu/luaprofiler"<luaprofiler@noreply.github.com>; 抄送: "kingbird"<249009092@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 函数并不总是通过 ret 返回，还有 error 。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[kingbird2011]

云风大哥，问个问题 目前项目里有很多不连续int的key的表，我想拓展下datasheet让它支持。 看源码的过程中发现，datasheet在index的时候，访问过的会构造出table放到cache中。 假如我在某个服务遍历访问过，是不是表示其实它的内存消耗，和直接自己require也差不多了？ ----------------------------- 仔细考虑后，感觉因为不能预料index得到的table会被怎么处理，所以确实只能copy，我看过分别处理 int和string的key的方式后，觉得可以用[10001]这种字符串key来代表不连续的证书key，带来的副作用就是不能用[]包含整数的string做key了（应该基本没这个需求），你意下何如

…

------------------ 原始邮件 ------------------ 发件人: "云风"<notifications@github.com>; 发送时间: 2019年4月20日(星期六) 中午11:14 收件人: "cloudwu/luaprofiler"<luaprofiler@noreply.github.com>; 抄送: "kingbird"<249009092@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 函数并不总是通过 ret 返回，还有 error 。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[kingbird2011]

云风大哥，问个问题 目前项目里有很多不连续int的key的表，我想拓展下datasheet让它支持。 看源码的过程中发现，datasheet在index的时候，访问过的会构造出table放到cache中。 假如我在某个服务遍历访问过，是不是表示其实它的内存消耗，和直接自己require也差不多了？ ----------------------------- 仔细考虑后，感觉因为不能预料index得到的table会被怎么处理，所以确实只能copy，我看过分别处理 int和string的key的方式后，觉得可以用[10001]这种字符串key来代表不连续的证书key，（一开始打算全部用字符串处理得了，但是考虑到表内有很多小数组，没必要浪费），带来的副作用就是不能用[]包含整数的string做key了（应该基本没这个需求），你意下何如。 ------------------ 原始邮件 ------------------ 发件人: "云风"<notifications@github.com>; 发送时间: 2019年4月20日(星期六) 中午11:14 收件人: "cloudwu/luaprofiler"<luaprofiler@noreply.github.com>; 抄送: "kingbird"<249009092@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 函数并不总是通过 ret 返回，还有 error 。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[cloudwu]

请用 ssm 分支上的 sharetable 。

[kingbird2011]

thanks，搜到了你的博文，正在阅读~~ 云风大哥有没有联系方式加一个哇~ 之前在网易找组里策划伍峰要，他说你玩微博比较多，微信不怎么用~

…

------------------ 原始邮件 ------------------ 发件人: "云风"<notifications@github.com>; 发送时间: 2019年5月18日(星期六) 下午3:01 收件人: "cloudwu/luaprofiler"<luaprofiler@noreply.github.com>; 抄送: "kingbird"<249009092@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 请用 ssm 分支上的 sharetable 。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[kingbird2011]

你好：最近自己用skynet做的一个游戏的服务器。出现了一些诡异的性能问题，情况如下： 1：游戏大概有2500格地图，每个地图一个lua虚拟机 2：大概有500人在线，每个人一个lua虚拟机。 平时一般cpu20%， 但是会突然出现120%的高峰，持续时间不定。波形完美的矩形波，只不过波峰波谷时间都不确定。 然后，问题来了，仿佛过了某个临界点，他会突然变成持续的120%，一条很稳定的直线。。。 对service的各种消息都做了profile没看出特别耗时的，stat看服务，也就gate繁忙但是很稳。不会产生矩形波。 请问： 是否我这service太多？触发了某种底层的问题？我统计过mqlen，没有发现过载的服务，service3000多个，task总共大概11000个左右。 这个120%的尖峰与在线人数好像无关，就是会突然出现，但是人多了貌似更容易变成一条直线。人少的时候也变过。 波形图我放在附件了，服务器是比较新的，才更新了没多久。 bytheway，听从了你之前的建议，硬着头皮升了sharetable，的确省了很多表格占用的内存。

[kingbird2011]

你好：最近自己用skynet做的一个游戏的服务器。出现了一些诡异的性能问题，情况如下： 1：游戏大概有2500格地图，每个地图一个lua虚拟机 2：大概有500人在线，每个人一个lua虚拟机。 平时一般cpu20%， 但是会突然出现120%的高峰，持续时间不定。波形完美的矩形波，只不过波峰波谷时间都不确定。 然后，问题来了，仿佛过了某个临界点，他会突然变成持续的120%，一条很稳定的直线。。。 对service的各种消息都做了profile没看出特别耗时的，stat看服务，也就gate繁忙但是很稳。不会产生矩形波。 请问： 是否我这service太多？触发了某种底层的问题？我统计过mqlen，没有发现过载的服务，service3000多个，task总共大概11000个左右。 这个120%的尖峰与在线人数好像无关，就是会突然出现，但是人多了貌似更容易变成一条直线。人少的时候也变过。 有个细节就是每次重启后貌似不会立即变成直线，要过一些时间以后。 波形图我放在附件了，服务器是比较新的，才更新了没多久。 bytheway，听从了你之前的建议，硬着头皮升了sharetable，的确省了很多表格占用的内存。

[cloudwu]

很难判断，不过你可以看一下 stat 里 cpu 使用统计，看看有没有什么服务消耗 cpu 比较多。

另外，在多核情况下，正好增加 100% 应该是多了一个核跑满了。比如网络线程。

[kingbird2011]

最近服务器发生一个诡异问题，凡是玩家数据太大，加载的时候socket暂停过。 这个人在断线的时候，就再也收不到socket disconnect的消息了。 看了下最新的skynet，发现可能有一个socket相关的问题，就升级了最新的skynet 这个问题解决了！ 然后之前困扰的100%cpu的问题也没了！！！ 重点来了，过了几个小时我的服务器因为各种消息队列overload崩了。。。。。。。

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "kingbird" <249009092@qq.com&gt;; 发送时间:&nbsp;2021年1月24日(星期天) 凌晨2:55 收件人:&nbsp;"cloudwu/luaprofiler"<reply@reply.github.com&gt;; 主题:&nbsp;最近困扰很久的一个性能问题 你好：最近自己用skynet做的一个游戏的服务器。出现了一些诡异的性能问题，情况如下： 1：游戏大概有2500格地图，每个地图一个lua虚拟机 2：大概有500人在线，每个人一个lua虚拟机。 平时一般cpu20%， 但是会突然出现120%的高峰，持续时间不定。波形完美的矩形波，只不过波峰波谷时间都不确定。 然后，问题来了，仿佛过了某个临界点，他会突然变成持续的120%，一条很稳定的直线。。。 对service的各种消息都做了profile没看出特别耗时的，stat看服务，也就gate繁忙但是很稳。不会产生矩形波。 请问： 是否我这service太多？触发了某种底层的问题？我统计过mqlen，没有发现过载的服务，service3000多个，task总共大概11000个左右。 这个120%的尖峰与在线人数好像无关，就是会突然出现，但是人多了貌似更容易变成一条直线。人少的时候也变过。 有个细节就是每次重启后貌似不会立即变成直线，要过一些时间以后。 波形图我放在附件了，服务器是比较新的，才更新了没多久。 bytheway，听从了你之前的建议，硬着头皮升了sharetable，的确省了很多表格占用的内存。

[cloudwu]

消息队列 overload 说明某服务的处理能力小于输入的消息速度。需要找到根源，在整体设计上避免。

[cloudwu]

不过前两天的一个 bug 是同一个 fd 断开时不断重复发送断开消息。如果 overload 还是需要确定到底是什么消息。若是底层的 bug 还是需要继续跟进的。

[kingbird2011]

还有我说的其他几句。。。 我原来的版本是1.40 1：升级到最新修复了socket pause 过的fd 无法收到断开消息的问题 2：升级修复了服务器与人数无关的高cpu占用，今天回滚升级后，这个cpu又回到100%多了，怀疑与socket有关的某个进程跑满了。这个问题我之前和你讨论过。 至于消息overload 应该不是我的问题，以前从未出现，没有其他信息可以追溯，出事前只有这些信息： 1568175 02/28/21 08:09:30.76 [:00000016] May overload, message queue length = 1025 1568176 02/28/21 08:09:30.77 [:00000016] May overload, message queue length = 2138 1568177 02/28/21 08:09:30.77 [:00000016] May overload, message queue length = 4097 1568178 02/28/21 08:09:30.78 [:00000016] May overload, message queue length = 8193 1568179 02/28/21 08:09:30.80 [:00000016] May overload, message queue length = 16385 1568180 02/28/21 08:09:30.85 [:00000016] May overload, message queue length = 32769 1568181 02/28/21 08:09:30.94 [:00000016] May overload, message queue length = 65537 1568182 02/28/21 08:09:31.06 [:00006ea2] LAUNCH snlua map_room 1568183 02/28/21 08:09:31.11 [:00000016] May overload, message queue length = 131074 1568184 02/28/21 08:09:31.47 [:00000016] May overload, message queue length = 262145 1568185 02/28/21 08:09:32.17 [:00000016] May overload, message queue length = 524289 1568186 02/28/21 08:09:33.58 [:00000016] May overload, message queue length = 1048577 1568187 02/28/21 08:09:34.45 [:00006ea4] LAUNCH snlua map_room 1568188 02/28/21 08:09:34.74 [:00006ea5] LAUNCH snlua map_room 1568189 02/28/21 08:09:36.36 [:00000016] May overload, message queue length = 2097163 稍后我会对比下升级，看下代码，看能不能看出一些有用的

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "cloudwu/luaprofiler" <notifications@github.com&gt;; 发送时间:&nbsp;2021年2月28日(星期天) 下午5:25 收件人:&nbsp;"cloudwu/luaprofiler"<luaprofiler@noreply.github.com&gt;; 抄送:&nbsp;"kingbird"<249009092@qq.com&gt;;"Author"<author@noreply.github.com&gt;; 主题:&nbsp;Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 不过前两天的一个 bug 是同一个 fd 断开时不断重复发送断开消息。如果 overload 还是需要确定到底是什么消息。若是底层的 bug 还是需要继续跟进的。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[cloudwu]

可以确认一下消息队列是是不是 SOCKET_CLOSE 或 SOCKET_ERR 。
我今天做了一次新的提交：cloudwu/skynet@0d94967 主要改变是在 close_write 是时候 shutdown write 以及在 epoll 里注销写事件。

其余次要修改都是针对原本认为 epoll 不会发生的行为的（比如注销了事件以后依旧收到事件）。

[kingbird2011]

我试了下你最新的升级，以下是各个版本对比 1：1.4.0 客户端连接到agent，agent请求dbserver，dbserver从redis一次性读取大量数据（大概200KB），dbserver触发socket pause。 触发过这个pause的fd在客户端断开后，agent【收不到】close消息。 会出现高额cpu占用，与人数无关，某个核可能100%了，但是不影响流畅度。 2：不包含这个最新的升级的升级 从redis一次性读取大量数据（大概200KB），触发socket pause。 触发过这个pause的fd在客户端断开后，【正常】收到close消息。 数小时内未发现高额cpu占用 但是数小时后，gate被大量消息overload，当时线上服，直接回滚重启了，没有现场 3：包含这个更新的升级 从redis一次性读取大量数据（大概200KB），【不再触发】socket pause。 【收不到】close消息。 因为这个是隔离的环境没有大量连接，不清楚会不会触发高额cpu占用和overload

…

------------------ 原始邮件 ------------------ 发件人: "cloudwu/luaprofiler" <notifications@github.com&gt;; 发送时间:&nbsp;2021年3月1日(星期一) 中午11:22 收件人:&nbsp;"cloudwu/luaprofiler"<luaprofiler@noreply.github.com&gt;; 抄送:&nbsp;"kingbird"<249009092@qq.com&gt;;"Author"<author@noreply.github.com&gt;; 主题:&nbsp;Re: [cloudwu/luaprofiler] 为何用LUA_MASKCOUNT (#2) 可以确认一下消息队列是是不是 SOCKET_CLOSE 或 SOCKET_ERR 。 我今天做了一次新的提交：cloudwu/skynet@0d94967 主要改变是在 close_write 是时候 shutdown write 以及在 epoll 里注销写事件。 其余次要修改都是针对原本认为 epoll 不会发生的行为的（比如注销了事件以后依旧收到事件）。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.