Hi Seggy, Yes, I already have the 50+ GB data file on an 500GB EBS volume. And trust me, I have a snapshot. :-) I just want to avoid spinning up lots of X-Large instances unless we have something that would really benefity from trying concurrently.
Gets pricey. :-) Cheers, G On Tue, Oct 6, 2009 at 1:26 PM, Seggy Umboh <[email protected]> wrote: > Glenn, > Since you are running on EC2, may I also suggest you put the couchdb data > directory on a EBS volume and snapshot it if you have not already, that way > you can spin up EC2 instances to try each of the suggestions being given on > the list on separate copies of the data > > Good luck! > > > On Tue, Oct 6, 2009 at 1:13 PM, Paul Davis <[email protected]>wrote: > >> On Tue, Oct 6, 2009 at 3:42 PM, Glenn Rempe <[email protected]> wrote: >> > Is there some way we can instrument and log how much memory the VM >> > thinks it has somewhere in the critical path piece of erlang code? Or >> > is there another way I can track that externally? >> > >> > G >> > >> > On Tue, Oct 6, 2009 at 12:13 PM, Adam Kocoloski <[email protected]> >> wrote: >> >> On Oct 6, 2009, at 2:46 AM, Glenn Rempe wrote: >> >> >> >> TMI logging doesn't really exist, no one uses that level internally. I >> >> agree with Paul here, the lack of error messages indicates an instant VM >> >> death. The most common way to cause that is by running out of memory, >> but >> >> view indexing is not supposed to use a large amount of memory at all. >> >> >> >> Adam >> > >> >> Here's a quick and dirty script that should work ish I think probably. >> I only tested it minimally. As it, no syntax errors and it prints the >> first vm size as expected. >> >> Just run that in a terminal while the indexer runs. It should die at >> the same time the the Erlang process dies. >> > -- Glenn Rempe email : [email protected] voice : (415) 894-5366 or (415)-89G-LENN twitter : @grempe contact info : http://www.rempe.us/contact.html pgp : http://www.rempe.us/gnupg.txt
