New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arm64 的图形界面版容器支持 #128
Comments
看起来与 #123 (comment) 的问题相同。 |
图形版的我也没成功,日志回复在了 #9 (comment) 中 难顶,项目紧急,我还是向深信服屈服了,安装了 Mac 版 |
写了非 x64 的图形界面版支持,可以从最新的 docker image build -f Dockerfile.fake-hwaddr -t fake-hwaddr .
EC_VER=7.6.3 # 此变量填写 ec 版本,`7.6.3`或`7.6.7`
docker image build --build-arg EC_URL=$(cat ec_urls/${EC_VER}.txt) --tag hagb/docker-easyconnect -f Dockerfile . 之后启动容器的操作和原本 amd64 下的一样。 |
测试成功,太给力了,稳定性等还需进一步观察。 是否有完全干净卸载 Mac 版本 easy-connect 的文档呢? |
目前观察到的一个现象,docker desktop 的 stats 显示该容器使用的内存每秒都在上升,刚启动时占用了 400+ mb,启动了半个小时上升到了 600+ mb,这正常么? |
看起来不太正常… 能在容器中运行 |
这个命令能展示你想要的信息么?
|
哦对,是这个 top,我给打错了 |
|
top 那里看 RSS 列就好。 如果方便的话,能不能对容器内存进行限制
并继续观察? |
好的,已经执行如下命令
我再继续观察下。 另外,对于在 Mac 上完全移除 easy-connect 你有什么经验么? |
观察结果:容器内存从 400+ mb 逐步升至 500 mb,每次快到 510 mb 时就会回落至 490+ mb,经过几次左右的回落后,跌落至 380 mb 左右并且不再上升,并且服务不可用,不可用时的 top 如下:
|
感觉
Mac 上我没什么经验(我没有 Mac 设备和 MacOS,调试是在树梅派上完成的),搜了一下(关键词
|
我是重新启动了容器然后执行的这行命令。 容器的内存在生命周期内是这样变化的:刚开始创建的时候是 120 左右,我成功建立公司连接后飙升至 400 左右,然后开始缓慢上升,如果我不做内存限制的话就不会停止上升,做了的话就会出现 #128 (comment) 描述的场景。 感谢提供的参考链接,我已经按照文档进行了清除。 |
不好意思,我把 #128 (comment) 错看成是 或者在容器里安装完整版的 top:
然后按大写
服务变成不可用应该是超出限制时 docker 把相关进程给杀了。如果加上 另外我这里观察到涨到 700M 之后有自行回落的现象(但是我是在 32 位 x86 上跑,和 arm64 的 M1 还是不能等同) |
我加 解决方法:Docker container 动态修改内存限制 https://cloud.tencent.com/developer/article/1525481
我尝试一下设置成 1G 看看,或者直接不设置看看最高的上限是多少。 另外有个疑问这个内存上升是在做什么?刚刚你也觉得这个内存上升并不正常。 |
有可能是内存泄漏,我在小内存的树梅派上调试,把树梅派内存用光了(用之前 700M 剩余)。 |
跑了一个多小时,内存已经到了 1G 以上,代理还是可以正常访问,应该是内存泄漏了。
测试结果如何? @Hagb |
amd64 上原生运行,内存占用稳定在 122M 左右。 |
debug 然后看看能否修复?感觉还是挺致命的。 |
不懂这一块的了,这个 bug 是等官方修复?还是你来修复? 是否有其他方法可以绕过这个 bug? |
我也不懂这一块。 进一步试验发现不频繁地杀 可以写一个 workaround 来做这件事(自动测量 ECAgent 的内存占用,超过阈值就杀掉它)。
从 Docker 官方的描述来看,达到内存限制后所杀进程的相对随机的:https://docs.docker.com/config/containers/resource_constraints/#understand-the-risks-of-running-out-of-memory 。所以指不定被杀掉了哪个进程,只好按照前面的思路人为进行控制了。 能看看你连上 vpn 一开始的内存占用情况吗?( |
这是我测试公司内网连接成功后截取的:
这是我在建立连接的时候录制的:
这个方法听起来可行,但是感觉有点暴力,还有其它的修复方式么? 另外,这个连接建立起来的时候看了下总内存量是 380M 左右,也远远高于你在 #128 (comment) 提到的 amd64 的 120+M,刚启动容器不建立连接的时候才比较接近这个数值,是指令集转译后的性能损耗么? |
目前没想到。改 qemu 目前超出个人能力,改 ECAgent 又因为没有源码而难以进行。
有可能。我这里 x86 模拟 x86_64 建立连接后倒是能够到 250M 左右。下面一张图是连接后 x86 qemu-user 模拟 x64 (上)和 x64 原生(下)的内存情况。 |
在 502bcca 添加了上述的 workaround,对 |
日志中确实没有出现这个字样,但是服务挂掉了,无法访问公司网络,当前状态: 容器内存 1.1G,几秒之前是 1.4G,这是我在 1.1G 时运行的命令:
补充1:服务正常的时候观察了几眼,内存最高不超过 440M,也就是上升不到 20M,一直比较稳定,写了会代码准备提交的时候发现挂掉了 = = 补充2:突然内存又到了 1.4G,这是 1.4G 时的状态:
补充3:刚准备杀掉容器的时候又观察到新的现象,容器内存不知怎么掉到一个低点,大概 280+M,然后快速飙升至 1.4G,每秒钟上升 100M+ 的那种飙升 |
~ 看起来内存飙升可能是服务停止、
另外可以看看容器内 Update: danted 并不会因为 vpn 的停止而超量使用路由。这里 danted 使用那么多内存不知道是怎么回事,如果设置了内存大小限制并且达到了,有可能 easyconnect 服务因此被 oom killer 杀掉。 |
服务挂掉后 vnc 里的前端有没有显示什么? |
昨天晚上有点事情直接给容器删了下班了,今天再继续观察下。
这个貌似并没有,最后一句日志为
这个今天观察下。
容器并没有设置内存上限,应该不会触发 docker 的 oom killer,今天看看能否复现。
挂掉后没有再尝试连接前端,我猜测前端已经不能够通过 vnc 连接了,今天如果复现了的话我尝试下。 |
再次出现服务异常,当前内存 1.5G,docker log 无额外信息输出,vnc 连接正常并且是黑屏,和连接成功时一个状态。
看起来都是你预料之内的日志。
这个文件的日志一直在输出,我截取了一小段。 |
看起来似乎是 CSClient 没起来。 |
等我再复现一下哈哈 |
日志:
|
从日志上看有一些和线程有关的报错,确实可能和 PS: 不额外安装软件包的情况下容器里可以使用 |
好的,那除了 workaround,还有其他办法解决之前的内存溢出么? |
除了 workaround,就是直接解决 qemu 的 bug 了… |
对 libthread_reuse 的做了一些修复并更新了 |
好的,我有空测试一下,现在已经返回公司办公,easyconnect 的使用频率会大大降低。
那就等有机会再更新吧哈哈,我有空的时候也会去了解一下。 |
期待更新啊,到目前为止,M1 Mac上没有能完美运行的版本 |
重装? |
我按照这些文档卸载了 easy-connect,姑且当做是干净卸载了吧😐 |
@whitehole-Z 尝试将 build-scripts/set-mirror.sh 里的 |
现在应该可以使用 arm64 原生的 EasyConnect 了:#25 (comment) |
给力,国庆说不定有机会试用,到时候会反馈。 |
Hi 大佬,好久没有跟进这个 issue 了,对此深感抱歉。 我们公司现在需要通过两步验证登录 vpn,我现在有以下问题:
感谢大佬做出的贡献~ |
没有没有。而且我最近也挺忙了(不过有什么问题也可以及时反馈,我有空会看的)
是
如果 amd64 的话 master 就可以,如果非 amd64 的话用
构建完成后启动方式是一样的,master 分支的 README 就可以(vnc 版的) |
arm64 版本的镜像(dev 版)已经 push 到 docker hub 上。现在可以试一下使用 |
好的!我会在需要的时候进行测试。 |
https://gitlab.com/qemu-project/qemu/-/issues/866 In docker-easyconnect, it was first mentioned in #128.
使用命令
日志
尝试了另外几个版本也是相同的日志输出,请问如何解决?
系统 12.2.1 (21D62)
The text was updated successfully, but these errors were encountered: