I disabled the firewall and still nothing. I tested without the -stepSize=5 and it worked in just a few minutes, which got me thinking about the memory.
Previously, I had given up after an hour assuming it was stuck. This time, I let it run for a day. It turns out that after about 4 hours, the server, with -stepSize=5 came up... Here's my best guess: When I had it running before it was in a VMWare virtual machine. Now, I'm running Fedora in VirtualBox which, I know, does some funky memory optimizations. My guess is that there's just some HUGE performance hit for some specific operation used here in VirtualBox which bogs everything down. It's finally up-and-running, though. Thanks for all your help! Jeff > > Hi, Jeff! > > I was unable to reproduce the problem. > > I used the same version of the source > http://users.soe.ucsc.edu/~kent/src/blatSrc34.zip > and compiled it and ran it. > It took 4 minutes for gfServer to finish counting tiles for hg19.2bit > and say it was ready. > > --- > gfServer start localhost 18000 -stepSize=5 /gbdb/hg19/hg19.2bit > starting untranslated server... > Counting tiles in /gbdb/hg19/hg19.2bit > Done adding > Server ready for queries! > --- > > Here are some things you might think about: > > Is port 18000 available? > Maybe it is already occupied? > To see if an old copy of gfServer is still running > you can try > ps aux | grep gfServer | grep -v grep > Is that port blocked by a firewall? > > Does it work if you wait longer? > > Does it work if you try it without -stepSize=5, > since that would use just half the amount of ram. > > What does uname -a show? > > What does this show? > file `which gfServer` > > for me it outputs: > /somepath/gfServer: ELF 64-bit LSB executable, AMD x86-64, version 1 > (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for > GNU/Linux 2.6.9, stripped > > -Galt > > 8/19/2010 7:32 AM, [email protected]: >> Hi Galt. >> >> Sorry for the delay. Here's a little more information: >> I'm running on Fedora 11 64-bit. >> I compiled gfServer (et al.) from source downloaded from the website: >> http://users.soe.ucsc.edu/~kent/src/ . I'm using version 3.4. >> >> The error when compiling was in jkOwnLib/fuzzyFind.c. Here's the console >> output: >>> make >> ... >> ... >> ... >> K_WARN -Wall -Werror -I../inc -I../../inc -I../../../inc >> -I../../../../inc >> -I../../../../../inc -o fuzzyFind.o -c fuzzyFind.c >> cc1: warnings being treated as errors >> fuzzyFind.c: In function lumpHits: >> fuzzyFind.c:1049: error: proto.score may be used uninitialized in this >> function >> make[1]: *** [fuzzyFind.o] Error 1 >> make[1]: Leaving directory `/home/jeffreya/Desktop/blat/jkOwnLib' >> make: *** [all] Error 2 >> >> When I removed the -Werror switches (two in that file), everything >> compiled without an error. >> >> Thanks for taking a look at this. >> >> Jeff >> >> >>> Hi, Jeff! >>> >>> Where did you get the source code? >>> I'd like to know what exactly what version you are using. >>> >>> Also, what error message did you get before >>> removing the -Werror. >>> >>> We run gfServer on 64-bit CentOS 5.5. >>> >>> -Galt >>> >>> On 08/13/10 12:24, [email protected] wrote: >>>> I've been experimenting with gfServer on a few different platforms >>>> (Windows, Mandriva, etc.) and just ran into my first problem. >>>> >>>> I've been able to compile and execute the gfServer on both of the >>>> previous >>>> platforms, but I'm currently trying to run it on Fedora 11 x64 and am >>>> having some problems. I start the server with the same files I've used >>>> elsewhere (which have worked on other platforms), but it now just >>>> stops >>>> at >>>> "Counting tiles in ..." and never progresses. The index is usually >>>> built >>>> within 15 minutes on comparable platforms; it's sat for over an hour >>>> now >>>> without getting past "counting tiles." >>>> >>>> It consumes RAM the same way as it previously did (~2.2GB for hg19), >>>> and >>>> it consistently consumes one core of the CPU the whole time. >>>> >>>>> gfServer start localhost 18000 -stepSize=5 /<directory>/hg19.2bit >>>> >>>> The only deviation I took from the standard "make" install was the >>>> removal >>>> of -Werror switches in one make file to get rid of an error as >>>> recommended >>>> at http://www.mail-archive.com/[email protected]/msg01674.html >>>> . >>>> >>>> Any help is appreciated. >>>> >>>> Jeff >>>> >>>> >>>> >>>> _______________________________________________ >>>> Genome maillist - [email protected] >>>> https://lists.soe.ucsc.edu/mailman/listinfo/genome >>> >> >> > > _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
