On Thu, Oct 25, 2012 at 01:04:25PM -0400, Chris Cunnington wrote:
On 2012-10-25 12:50 PM, Levente Uzonyi wrote:
I doubt logging is a bottleneck, but using a separate log file is useful. It would be good to check the error.log to see if apache is low on resources (or not). Also "top -d 1" can give you hints about what's eating up CPU/memory, or what's waiting for the disk for too long.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15277 lewis 20 0 1028m 89m 1300 R 2.0 8.9 18:15.60 squeakvm 1 root 20 0 2032 652 556 S 0.0 0.1 0:15.83 init
lewis 15277 2.1 8.8 1053112 91572 pts/0 S 04:40 18:15 /usr/local/lib/squeak/4.10.5-2619/squeakvm -nodisplay /home/lewis/VMUnixBuild/Squeak4.3.image /home/lewis/VMUnixBuild/VMUnixBuild.st
That is consistently at the top of top -d 1. This VPS has 1G of RAM.
Oops, sorry about that. If it happens again feel free to "sudo killall squeakvm" for me.
FYI, I do now have a reasonably safe build script in place, despite the above glitch. There is a shell script ~lewis/VMUnixBuild/makevm that runs a Squeak script ~lewis/VMUnixBuild/VMUnixBuild.st. The shell script has a watchdog loop that is supposed to kill the Squeak process if it runs longer than 30 minutes (which does in fact happen sometimes).
If everything works properly, the full script runs for about 8 minutes. The end result is a tarball containing bleeding edge Unix and VMM-generated sources. These are currently located in ~lewis/VMUnixBuild/TARBALL, and logging output from the script is in ~lewis/VMUnixBuild/LOGS.
The script does a complete VM compile before making the tarball, which ensures that each tarball contains a set of sources that is consistent enough to build a VM if you were to download it to your own Linux box and do the configure/make for yourself.
I don't have a clue how Jenkins works yet, but presumably the next step would be to wire this into the Jenkins environment so the script could run daily, and provide the latest tarball as the build artifact.
Dave