Hi, Sean, When using multiple threads, it is possible that different thread would require different part of an index, which would increase the overall memory requirement. If you believe that there is sufficient memory, a quick thing to do is to set fileManager.maxBytes through a rc file.
There are a couple of tests in tests/Makefile.am that illustrates how running current queries on different data sizes might affect the execution of the FastBit code. These test targets are named check-sq0, check-sq1, and check-sq2. You might want give them a try if you are still interested. Thanks. John On 5/29/15 10:24 AM, Sean McNamara wrote: > Thanks! Here is the output after running /w pt-pmp: > http://pastebin.com/uj1R0i4Q > > Three things I have noticed: > 1. using strace I see that 75% of the time the application is spent > inside theses: futex, mmap, munmap > 2. using pt-pmp the top hit is: ibis::array_t::reserve > 3. using perf I see that we never utilize more than 3 cores (the box > has 20+ cores, and we’re running 10 threads in this instance) > > After looking at ibis::array_t::reserve, it looks > like ibis::fileManager::storage::storage is being called, which is > using a mutex. Since we have threads executing fastbit in parallel > I’m wondering if there is possibly some lock contention going on with > the file manager? > > I am not currently setting fileManager.maxBytes, could this be part of > the problem? > > Cheers, > > Sean > > > >> On May 8, 2015, at 2:57 PM, Justin Swanhart <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> You may be able use this tool to examine your application and see >> where it is waiting: >> http://www.percona.com/doc/percona-toolkit/2.2/pt-pmp.html >> http://www.percona.com/get/pt-pmp >> >> It uses gdb to gather stack traces and aggregates them together so >> that you can see where multiple threads are stuck at the same point >> of execution, such as a mutex or semaphore. It is kind of the >> opposite of 'perf', since it finds where things are waiting and >> doing nothing, rather than where things are consuming the most CPU. >> >> Full disclosure: I work for Percona. >> >> Regards, >> >> --Justin >> >> >> On Fri, May 8, 2015 at 10:28 AM, Sean McNamara >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Hey John- >> >> I had a fastbit question for you. We're running a process that >> uses N threads to query N partitions against fastbit in >> parallel. We're seeing some contention somewhere that appears >> to cause the threads to execute serially. Before I dig in >> further I though it would be worth asking you: is there some >> sort of mutex or synchronization that is happening inside >> fastbit that could cause it to only be able to execute a single >> query at a time within a given process? >> >> Thanks, >> >> Sean >> _______________________________________________ >> FastBit-users mailing list >> [email protected] <mailto:[email protected]> >> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >> >> >> _______________________________________________ >> FastBit-users mailing list >> [email protected] <mailto:[email protected]> >> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > > > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
