> Hi, Roberto, > > I was trying to set this up, and got some questions. Overall, this thing > is > absolutely amazing! > > 1. I'm using ubuntu 12.04, installed kernel 3.5.0 with > apt-get install linux-generic-lts-quantal > > I managed to compile uwsgi so it doesn't complain > about PR_SET_CHILD_SUBREAPER with this: > CFLAGS='-I /usr/src/linux-headers-3.5.0-51-generic/include' make > > But have a feeling that I was doing it wrong. Was I?
nope, it is a pretty hacky approach, but i see no other ways for such an "old" distro. Your problem is the your libc headers do not export such definitions so you have to rely on kernel headers. Once you run on kernel 3.5 it should work flawlessly. As an alternative approach you can add CFLAGS="-DPR_SET_CHILD_SUBREAPER=36" to uWSGI compilation > > 2. The base vassal seems to ignore the "home" setting. I managed to launch > it in a virtualenv by starting the emperor from a uwsgi installed into a > virtualenv there should be an "early-virtualenv" option soon or later, but for ow you can set the PYTHONHOME with the ienv option (it is like 'env' but immediate), remember to set it before early-* options > > 3. I have large uwsgi configs for the vassals. Which of these settings > should I move to the "base" vassal, and which of them are supposed to work > in the base vassal at all? > https://gist.github.com/ikatson/1a13fdb8a5606258e783. if you are using a django app, lazy-apps is not needed (django is lazy by default). The purpose of the base server is load the app and then wait for fork, so i would only place early-pyimport (one for every module required) > > 4. Both base and adopted vassals seem to ignore the environment variables. > How do I pass them? Can I supply addition environment variables to the > adopted vassals for configuration? ienv for the base (before early-*), env in vassals should work normally > > 5. How can I launch some code in the adopted vassal to be called ater > forking, before it accepts any requests, so that I can reconfigure it > accordingly? I hope to get the base values for configuration from > environment variables. If env vars are not available in this way, how can > I > overcome this? > shared-pyimport = file/module should be a good trick > 6. Can the same emperor start multiple base vassals? yes, if a vassal has no [emperor] section exposing a fork-base server, it will be treated as a base > > 7. These errors are in the emperor log, is it normal? > emperor_connect_to_fork_server()/uwsgi_connect(): Connection refused > [core/emperor.c line 1116] > uwsgi_emperor_spawn_vassal()/fork(): Connection refused [core/emperor.c > line 1253] they happen when a vassal spawn before its base, i think we should allow some form of "retry" > > 9. This is minor, but do you have any ideas why the memory consumption > still increases slightly with each adopted vassal? The base app consumes > 100MB of memory, when adding a new vassal through fork-server, there's a > 3MB increase per each process, without any requests. Is that the memory > consumed by uwsgi itself? it could be, you are using gevent, about 4k per cores are allocated (in addition to the memory structures). In addition to this for the way reference counting works, a good number of memory pages could be re-allocated during work. > > 10. This is very minor too, just FYI, in the process table the adopted > vassal worker's cmdline contains the name of the base vassal, but not of > the adopted one. > I.e. Lots of entries for "base.ini", but only one for "adopted.ini". > Especially noticeable with processes setting greater than 1 you can force the name of the processes directly in the vassals via the various "procname" options (grep --help for procname) > -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
