[OPEN-ILS-DEV] big wads of RAM

[John Fink]

Hi folks,

Yeah, the machine I'm on now is 32 bit Debian, which is okay, as there's
only 1gb of memory on it anyway.  I don't at the moment recall the size of
my bib load (although I know I talked about it on the list) -- but it was
Big.  All the bibs in our library, which is a pretty big library.

If/when I get a new machine, it'll have 64 bit Debian on it, so hopefully
that will include 64 bit postgres as well.

I have not messed with postgres configs but will dig into it -- thanks
Reuben!

jf

On Wed, Mar 19, 2008 at 4:38 PM, Reuben Pasquini <rdp0004 at auburn.edu> wrote:

> Hi JF,
>
> Just remember:
>
> *. Your system will not be able to address more
>     than 4GB unless you install a 64bit version of Linux
>
> *. Postgres will not be able to address more than
>      4GB unless you install a 64bit build of postgres.
>
> Have you configured postgres to take
> advantage of the memory you already have ?
> The default postgres config is very conservative.
>
>
> http://www.postgresql.org/docs/8.2/interactive/runtime-config-resource.html
>
>
> Also, postgres may bog down over time
> unless you regularly "vacuum"
> and "reindex" the database.
>       http://www.postgresql.org/docs/8.2/interactive/maintenance.html
> Newer version of postgres have an auto-vacuum
> capability.
>
>
> http://www.postgresql.org/docs/8.2/interactive/runtime-config-autovacuum.html
>
>
> Finally, you can get a sense of whether your memory is
> CPU or memory constrained by running 'vmstat' and 'top'
> (sort by %MEM/%CPU in top).
>
> top - 15:30:24 up 16 days,  3:16,  3 users,  load average: 0.00, 0.00,
> 0.00
> Tasks: 165 total,   1 running, 162 sleeping,   1 stopped,   1 zombie
> Cpu(s):  0.2%us,  0.1%sy,  0.0%ni, 99.6%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Mem:   2041944k total,  1993512k used,    48432k free,   300756k
> buffers
> Swap:  3229024k total,    35548k used,  3193476k free,   792724k
> cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>
>    1 root      15   0  2952 1856  532 S    0  0.1   0:03.44 init
>
>    2 root      10  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
>
>    3 root      RT  -5     0    0    0 S    0  0.0   0:00.22
> migration/0
>    4 root      34  19     0    0    0 S    0  0.0   0:00.01
> ksoftirqd/0
>    5 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/0
>
>    ...
>
> $ sudo vmstat 1
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
>  1  0  35548  53092 300768 786732    0    0     1     8    7   13  0  0
> 100  0
>  0  0  35548  53076 300768 786732    0    0     0   140   16  389  0  0
> 100  0
>  0  0  35548  53076 300768 786732    0    0     0     0   21  352  0  0
> 100  0
>  0  0  35548  53076 300768 786732    0    0     0     0    8  351  0  0
> 100  0
>  0  0  35548  53076 300768 786732    0    0     0     0   14  359  0  0
> 100  0
> ....
>
> Good luck!
> Reuben
>
>
> >>> "John Fink" <john.fink at gmail.com> 3/19/2008 11:37 AM >>>
> Hey folks,
>
> I'm in the midst of putting in a request for a bigger, beefier machine
> on
> which to run EG, seeing that the one I have now is encountering
> postgres
> problems with massive bib loads.  It seems like the most practical
> amount of
> RAM I can get with what I think my budget is will be 8gb.  Any
> postgres
> wizards care to comment whether or not this will be practical?
>
> jf
>
> --
> http://libgrunt.blogspot.com -- library culture and technology.
>



-- 
http://libgrunt.blogspot.com -- library culture and technology.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20080319/b61a6fd4/attachment-0001.html