 |
 |
Hi Serge, The problem you're talking about seems to be fixed now. I think the cause was that the LSST stack isn't relocatable, so you can't build in in /sps/stack and then copy it to workers /qserv/smm/stack. Indeed you have to build the initial version in /qserv/smm/stack (which can be a symlink to /sps/stack). The docker solution will solve this issue. Cheers, Fabrice /qserv/stack/Linux64/mysql/5.1.65.lsst2/bin On 08/19/2015 06:18 AM, Serge Monkewitz wrote: > Hi Fabrice, > >> On Aug 16, 2015, at 10:58 PM, Fabrice Jammes <[log in to unmask]> wrote: >> >> Hi Serge, >> >> Thanks for this clear report. It is not clear why mmfsd use 2GB of RAM, as GPFS should only be used during Qserv installation, and not during Qserv execution. Does the czar try to access some resources stored in /sps because of some configuration issue? > According to Josh, mmfsd uses some preconfigured amount of memory as cache whether or not GPFS is actually used (looking at mmfsd usage on a few random workers seems to bear this out - they are all at about 2GiB). Also, while I know we shouldn’t be using GPFS, we unfortunately are - somehow /sps/... got embedded into John’s stack. See for example /qserv/smm/stack/Linux64/mysql/5.1.65.lsst2/bin/mysqld_safe on one of the workers - it references /sps all over the place. I don’t know how that happened, but I’m also not sure it’s worth worrying about right now. > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1