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

Reply via email to