问题描述
使用docker起的label_studio服务，起来就占了8GB内存，无论是否有标注任务。
而且这个么大内存label_studio起来就有，不是随着时间起来的。本来发现问题的是label_stuido17.3, 我下载了18.02版本的docker，问题也是一样的,看github上的issues，没看到跟我一样的问题。
先说推论
之所以叫推论，是因为没有实锤，只是根据我做的各种测试来推理的。
我自己各种对比测试下来，怀疑是uwsgi中的http进程会根据系统内存大小计算出一个预申请的内存大小，然后申请内存。在大内存的host系统上申请的内存多，在内存不那么富裕的host系统上，docker起来后申请的内存就少。我也买找到控制这个内存占用的方法，毕竟我也没时间看源码，修改uwsgi.ini也没啥作用。
我使用同一个docker镜像，在我16GB的系统上起容器，发现http进程占用的内存很少：
在另一台128GB的服务器上，容器起来后就固定占8GB+的内存：
分析
label_stuido是一个python语言编写的深度学习标注平台。
主要是通过uwsgi+django的方式对外提供网页服务。
我用memory_profiler分析server.py中的main()函数，发现这个函数执行完只占了200多M的内存，所以应该不是工作线程占的大头。通过ps命令也能看到，是uwsgi的http进程占的。而uwsgi这个程序是一个c语言编写的程序，没办法用分析python的工具来分析。我本来想用valgrind来分析它的内存占用，在label_studio的容器中valgrind没安装成功，只得作罢。我把同样的容器用同样的启动方式在另一个服务器上起了一下，发现内存占用就不一样了。所以才有了上面的推论。
做过的其它测试
网上别人遇到的uwsgi的内存问题基本都是随着时间增长，请求越来越多，内存越来越大。而我遇到的问题是起来内存就大。
我也抱着试试看的态度，修改了uwsgi.ini这个配置文件中的很多参数，结果发现对我没啥用，起来内存占用还是那么多。
我修改过的配置有：
processes = 2
processes = 1
reload-on-rss = 2044->1024
buffer-size = 65535->25535
post-buffering = 4096->1024
max-requests = 3000 ->1000
worker-reload-mercy = 300->100
箭头左边是默认值，右边是我修改的值。除了修改processes内把起来的内存减少200M左右，其它的基本不起作用。
能否在启动docker的时候限制内存大小
既然uwsgi启动时预申请内存，能够限制docker的内存资源达到节省内存的目的吗？
我用docker-compose控制docker看到的内存大小，结果只要不够的话，uwsgi根本就起不来，我猜测它有办法获取host系统上实际的内存大小，然后计算预申请的内存大小，不够的话就死给你看。我测试下来这种思路行不通。
