It seems to work now with the ulimits for the server_pool users. If they become too strict, we (maybe more precisely MIguel Marco) will try the worker user approach. We will let know. Thanks for the help!
El domingo, 27 de noviembre de 2016, 21:23:33 (UTC+1), Nils Bruin escribió: > > On Sunday, November 27, 2016 at 3:04:48 AM UTC-8, Enrique Artal wrote: >> >> Thanks, As you say, it would be better something more direct, but your >> approach is a strong improvement for my needs. >> By the way, I changed in our experimental notebook 7.4 -> 7.3 and the >> limits work: they stop the process and the notebook is still running. >> > > for sage 7.5beta(?) setting ulimits does have effect: with > > sh$ ulimit -v 10000000 > sh$ sage -c 'L=[1] > for i in [1..1000]: > L = L+L > print i' > > I get a memory error after "28" has been printed (and without it, it > continues longer), and if I take the bound much lower sage will not even > start. > > So if you configure the "worker" user to have such a ulimit, I'd expect > memory problems to be significantly reduced. People who try to use more > memory should see their kernel die before it's causing problems for other > people. > > Given that there's no way of controling which notebook user gets mapped to > which worker uid, I don't think there's much mileage to be had from > configuring multiple worker uids (other than having them on multiple > machines to load-balance a little bit). > > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
