Generally what's going on is that Tomcat, the web application framework, has a large virtual machine running with a substantial amount of memory allocated to the caching of programs and data for performance.
Depending on your database configuration, there can also be a substantial amount of allocation to cache in Postgres too. The indexer is a periodic process that does not run constantly. You still must account for the amount of memory it consumes while running. Memory requirements for recent versions of the indexing routine are of constant order, meaning they do not vary appreciably with repository size. On Wed, 2007-04-18 at 18:09 -0700, Pan Family wrote: > Thank you all for giving your opinion! > > Technically, is it the web application or the indexer that requires > most of the memory? What data is kept in memory all the time > (even when nobody is searching)? Is the memory usage proportional > to the number of concurrent sessions? > > Thanks again, > > Pan > > > > > On 4/18/07, Cory Snavely <[EMAIL PROTECTED]> wrote: > Well, as I said at first, it all depends on your definition of > what a > memory hog is. Today's hog fits in tomorrow's pocket. We > better all > already be used to that. > > Also, I don't think for a *minute* that the original > developers of > DSpace made a casual choice about their development > environment--in > fact, I think they made a responsible choice given the > alternatives. > Let's give our colleagues credit that's due. Their choice > permits > scaling and fits well for an open-source project. Putting the > general > problem of memory bloat in their laps seems pretty angsty to > me. > > Lastly, dedicating a server to DSpace is a choice, not a > necessity. We > as implementors have complete freedom to separate out the > database and > storage tiers, and mechanisms exist for scaling Tomcat > horizontally as > well. In the other direction, I suspect people are running > DSpace on > VMware or xen virtual machines, too. > > Cory Snavely > University of Michigan Library IT Core Services > > On Wed, 2007-04-18 at 13:40 -0500, Brad Teale wrote: > > Pan, > > > > Dspace is a memory hog considering the functionality the > application > > provides. This is mainly due to the technological choices > made by the > > founders of the Dspace project, and not the functional > requirements the > > Dspace project fulfills. > > > > Application and memory bloat are pervasive in the IT > industry. Each > > individual organization should look at their requirements > whether they > > are hardware, software or both. Having to dedicate a > machine to an > > application, especially a relatively simple application like > Dspace, is > > wasteful for hardware resources and people resources. > > > > Web applications should _not_ need 2G of memory to "run > comfortably". > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
