db.go:
1 | package main |
main.go:
1 | package main |
db.go:
1 | package main |
main.go:
1 | package main |
inux下面所有的文件、目录、设备都有一个路径,这个路径永远以/开头,用/分隔,如果一个路径是另一个路径的前缀,则这两个路径有逻辑上的父子关系。但是并不是所有逻辑上的父子关系都必须要是同一个设备,决定不同路径对应到哪个设备的机制就叫做mount(挂载)。
通过mount,可以设置当前的路径与设备的对应关系。每个设备会设置一个挂载点,挂载点是一个空目录。一般来说必须有一个设备挂载在/这个根路径下面,叫做rootfs。其他挂载点可以是/tmp,/boot,/dev等等,通过在rootfs上面创建一个空目录然后用mount命令就可以将设备挂载到这个目录上。挂载之后,这个目录下的子路径,就会映射到被挂载的设备里面。当访问一个路径时,会选择一个能最大匹配当前路径前缀的挂载点。比如说,有/var的挂载点,也有/var/run的挂载点的情况下,访问/var/run/test.pid,就会匹配到/var/run挂载点设备下面的/test.pid。同一个设备可以有多个挂载点,同一个挂载点同时只能加载一个设备。访问非挂载点的路径的时候,按照前面所说,其实是访问最接近的一个挂载点,如果没有其他挂载点那么就是rootfs上的目录或者文件了。
实际上并不只有linux支持挂载点,Windows也是一样支持的。去控制面板/管理工具/计算机管理 里面,挑一个磁盘(比如D盘),然后给它分一个新的挂载点试试,比如C:\data
转载:https://www.zhihu.com/question/266907637/answer/315386532
1 | package main |
通过阅读源码/注释有什么用呢?
例子:如果把 int
类型在 json.Marshal()
时转为string。
1 | package main |
1 | package main |
首先通过监控工具查看到某个项目的机器内存在部署之后总是不断上涨,但是用户量并不多,很明显是内存泄漏的问题。
项目中引入了以下代码,自然可以通过 pprof 工具进行分析。
1 | package main |
解决问题尝试了很多种方案,最后方案如下:
curl localhost:8000/debug/pprof/heap > heap.base
等待一段时间,通过 htop 可以查看到内存又涨了很多,然后再采集内存情况
curl localhost:8000/debug/pprof/heap > heap.current
go tool pprof -http=:8080 -base heap.base heap.current
选择当前分配的对象(insue_objects):
得到如图所示:
图中可以看出 withdraw_record.GetByUserId.FindAndCount() 在这段时间创建了 624110 个对象,于是怀疑是这里出了问题,于是去查看代码:
1 | count, err = statement.Where("user_id = ? ", userId).FindAndCount(&records) |
发现 statement 这个数据库 session 没有关闭,怀疑是因为没有关闭造成的问题
既然怀疑是这里的问题,然后就写了个 for 循环,不断地请求嫌疑接口,通过htop 发现,内存果然蹭蹭蹭
网上涨,问题复现成功
修复就很简单了,加了一个 defer statement.Close()
代码修复后,部署到测试服上,再用 for 循环去测,发现内存不再上涨,到此应该算是问题解决
想 ssh 远程连接服务器,并批量执行命令,结果发现 echo $(pwd)
在本地执行,echo "bbb" >> b.txt
却在服务器端执行
通过给第一个 remotessh 加双引号即可解决。
1 | // Make sure a Hash implements the hash.Hash and hash.Hash64 interfaces. |