On 04/20/2015 06:33 PM, Andrey Novoseltsev wrote: > Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It > has swap as well, but I don't think it was used much, the wall time was > just a bit bigger than user+system, about 8-9 hours.
I hope the 8-9 hours refer to the total time, not walltime - (user + sys)... ;-) Is it really a single-core without "hyperthreading"? Otherwise I'd set SAGE_NUM_THREADS=1 since the Sage library is (almost) always built in parallel with as many jobs/threads as the CPU has hardware threads (usually twice the number of cores on a CPU with HT). > With Sage-6.6 it gets stuck while processing rings directory: swap is > not full yet, but it seems that necessary stuff does not fit RAM anymore > - heavy disk usage, low CPU temperature, not much progress after more > than a day, top was showing "python setup.py" if I recall correctly > consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over > several attempts with "make distclean", with nothing running apart from > MATE session and a terminal window. The more interesting figures of 'top' are load average, actual user CPU usage (%us), kernel CPU usage (%sy), and I/O wait (%wa)... If I'm not mistaken, the "python setup.py" includes cythonizing, i.e., that's performed in the same process, and presumably makes up most of the actively used memory (of that process). > I realize that supporting builds on such computers may not be a high > priority, if at all, but perhaps it is a manifestation of some bug. > > Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite > common, especially with VMs. (In fact, all physical and virtual machines > that I use frequently happen to have exactly this number, ranging from > 2GB/1 core to 32GB/16 cores.) Yep. To mitigate the problem, you could try to not have the main filesystem (which usually also contains the Sage installation), swap space and /tmp (i.e., $TMPDIR) and/or $SAGE_BUILD_DIR on the same physical drive, e.g. by temporarily plugging a small (but fast) external drive and (temporarily) migrating some portitions there (i.e. $TMPDIR, $SAGE_BUILD_DIR, or even swap space onto a USB-3.0 SSD, say). In my experience, disk I/O is much more the bottleneck than CPU speed when building Sage, and if the same disk is in addition heavily charged by swapping (in your case apparently rather thrashing), the situation gets even worse. -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
