It appears that cPanel has limitations on both real and virtual memory. Please see the output below: r...@albion [/home/xela]# ulimit -a core file size (blocks, -c) 1000000 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 45056 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 4096 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 14335 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited r...@albion [/home/xela]# su liquidsoap liquids...@albion [/home/xela]# ulimit -a core file size (blocks, -c) 200000 data seg size (kbytes, -d) 200000 scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 45056 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 200000 open files (-n) 100 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 20 virtual memory (kbytes, -v) 200000 file locks (-x) unlimited
I'm still researching the best method of raising these values for the liquidsoap user. I guess my problem #1 with the hiccuping is that I 'assumed' the liquidsoap-full had all the latest versions, which I was wrong in assuming. As for the Segmentation Faulting, I suspected it had to do with a memory limit, but I was not sure of this until I saw the output of the ulimit -a above, and tried running liquidsoap as the root user which works flawlessly. Just so it's out there, I do not intend to run liquidsoap as the root user for obvious reasons. :) I'll reply back to this thread once I have a good solution for raising those ulimit values for the restricted liquidsoap user. Many thanks for helping me research this and get it working properly!! Max > Le jeudi 4 mars 2010 17:57:40, David Baelde a écrit : >> After some investigations on IRC with Maxwell, here are some >> conclusions. >> >> The key is that Maxwell is running liquidsoap is a pretty constrained >> environment, with "only" 200M allowed for a process, and liquidsoap >> has a higher memory consumption than that (~500M). The bad::alloc >> exception was raised by Taglib because it had no more memory. We could >> catch it at the C++/OCaml interface but that would be a pain, and >> anyway there would be many other places where to do similar checks. A >> more feasible solution would be to check at startup if the memory >> limitation seems reasonable, and report a warning in the logs. (I'm >> not sure what's the C/OCaml equivalent of ulimit.) > > Is it real memory or just virtual memory ? > > I fail to see liquidsoap using 500Mo of real memory, Id rather suspect > that we > are talking about virtual memory here.. > > For instance, on my production, which is a huge instance of liquidsoap, I > have > 265m of virtual memory but only 146m of memory really used.. > > The thing is that the virtual memory is just the memory space that the > program > sees. In particular, it includes all loaded shared library. However, as > for > the "shared" in the name, this memory is not duplicated between programs > but > loaded at a unique place in the hardware. > > Hence, virtual memory may be significantly larger, in particular for > programs > like liquidsoap, than the memory actually used by the process on the > hardware... > > In this case, I would tend to think that the environment is badly > designed. > Virtual memory should not be limited but only the memory actually used... > > >> The hiccups where caused by ocaml-cry 0.1.1. The 0.1.2 version fixed >> them, and I realized that what was documented as an optimization in >> that version is really a bug fix. Everybody should upgrade to 0.1.2, >> and Romain will probably release a new liquidsoap-full including it. > > Will do very soon ! > > > Romain > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
